在浏览器里做进位转换，采用任意精度运算，所以 64 比特的数值是精确的，不会被悄悄四舍五入。

大多数转换器在 2^53 以上都是错的，而且不声不响

这就是这一页存在的理由，值得了解，因为那个错误是看不出来的。

JavaScript 的数字是 64 比特浮点数，能精确表示的整数只到 9,007,199,254,740,991——也就是 2^53 − 1。超过之后，parseInt 和 toString(radix) 还是会回给你一个答案，只是低位数字是错的。

0xFFFFFFFFFFFFFFFF 应该是 18446744073709551615。用一般数字做的转换器会回 18446744073709552000。

而那正是开发者手上会有的输入：64 比特杂凑值、Twitter 或 Discord 的 snowflake ID、暂存器内容、文件位移量。这里全部使用 BigInt，所以不管多大都是精确的。

前缀与分隔符号都吃

手上是什么就贴什么。0xDEAD_BEEF、0b1010 1010、0o755 和 1,234,567 都可以——前缀会在符合你选的基数时被去掉，底线、空白和逗号一律忽略。

不属于该基数的数字会被指名拒绝，而不是跳过。把 1g 里的 g 默默丢掉然后回报 1，正是一个转换器对打错的字给出自信错误答案的方式。

「0xFF 当成有号字节是多少？」是一个真实的问题，而只会处理数值大小的转换器答不出来。

同样的比特，在不同宽度、以及有号与无号之下，代表不同的数。0xFF 无号是 255，当成 8 比特有号数则是 −1；0xFFFF 是 65535 还是 −1，取决于你是不是以 16 比特在读它。

每一种宽度只有在数值放得进去时才会显示。如果一个数字装不进一个字节，就不会给你 8 比特的读法，因为根本没有。

2 到 36 的任何基数都可以，用 0-9 接着 a-z。基数 36 是人类还打得出来的最密集形式，这也是短 ID 和短网址服务常用它的原因。

在这个页面里转换。