2 – 36 进制结果
为什么不用 parseInt
JavaScript 的 Number 只能精确表示到 2⁵³−1（9007199254740991）。超过这个范围，parseInt 会把末尾几位悄悄改掉 —— 转订单号、哈希片段、雪花 ID 时，这种错误不会报错，只会给你一个看起来合理但错的数字。
所以本页全程用 BigInt 做逐位累加和长除法，整数部分不碰浮点数。把 64 位甚至更长的整数粘进来，每一位都和原文一致。
一次给出全部 35 种进制
选定源进制后，2 到 36 进制的结果一次性全部列出，2、8、10、16 排在前面，其余升序排列，每格右侧一个复制按钮。
源进制支持 2–36，默认按十进制解析。0 到 9 之后用 a 到 z 表示（不分大小写），所以 z 在 36 进制里代表 35。
小数是怎么处理的，以及为什么不四舍五入
小数部分按「乘基取整」逐位算：每次把小数部分乘以目标进制，取整数位作为下一位，剩下的继续。能整除就自然结束，除不尽就一直算到上限。
上限是 20 位，到顶后直接截断，不进位 —— 这是刻意的：四舍五入会让最后一位变成「看起来精确但实际不等」的值，而截断至少明确告诉你后面还有。像十进制的 0.1 转成二进制就是无限循环，这类情况看到 20 位被截断属于正常现象。
前缀只对得上才剥
输入里的空格、逗号、下划线会被自动忽略，所以 1_000、0xFF,FF 这类带分隔的写法可以直接粘。负号和一个小数点也支持。
0x、0b、0o 这些前缀只有在与所选源进制一致时才会被剥掉：源进制选 16 时 0xFF 有效；源进制选 10 时 0x 会被当成非法字符报错，而不是被静默忽略 —— 否则 0b101 在十进制下就会被误读。
本地计算，长数字随便粘
换算走 BigInt，全在浏览器里完成，没有网络请求。数据库主键、含业务含义的编号、待排查的 ID 都能直接粘进来，不存在外传风险。
出错时会给出明确原因（比如「最大为 X」，指明哪个字符超出了进制范围），同时保留上一次的有效结果，方便对照修改。
到 36 进制为止
上限是 36（10 个数字加 26 个字母），这也是 JS 里 toString(radix) 的原生限制。Base58、Base62 这类更大字符集或自定义字符表的编码不属于本页能力，请找专用工具。
另外本页只做数值换算，不做字节流的编码解码 —— 十六进制字符串与文本的互转请用编码类工具。
常见问题
很长的数字会算错吗？
不会。全程用 BigInt 逐位运算，不经过浮点数，超过 2⁵³−1 也不会丢精度 —— 这正是本页和 parseInt 方案的根本区别。
小数位数为什么被截断了？
上限 20 位且刻意不四舍五入。除不尽的情况（如十进制 0.1 转二进制）本来就是无限循环，截断比给一个假的进位值更诚实。
0xFF 在十进制下为什么报错？
前缀只在与源进制一致时才剥除。选十进制时 0x 属于非法字符，直接报错可以避免 0b101 这类输入被误读。
支持 Base58 或 Base62 吗？
不支持。上限是 36 进制，更大字符集或自定义字符表需要专用工具。