关于 进制转换工具
进制与编码转换工具做的是两件相关但截然不同的事。数值进制模式把一个整数从 2 到 36 之间的某个进制改写成另一个进制，内部使用任意精度运算，因此 40 位的数值也能原封不动地转过来。RFC / 自定义模式则把文本按 RFC 4648 Base32、Base64，或者你自己提供的字典做编码和解码 —— Base58 和 Base62 正是通过后者实现的。
进制转换和字节编码长得很像，却根本不是一回事。进制转换拿到一个整数，只改写它的数位：值没变，变的只是记法。编码拿到的是一串字节 —— 文本、密钥、哈希 —— 把比特重新分组映射到某个字典上，好让它穿过一条会把原始字节搞坏的通道。前者是算术，后者是传输。把两者搞混，会产出语法上说得通、语义上毫无意义的结果，而这正是最难被发现的一类缺陷。
如何使用这个开发者工具
- 整数用「数值进制」模式，文本和字节数据用「RFC / 自定义」模式。
- 数值进制模式下，设置源进制和目标进制（各自取 2 到 36），然后输入值。数位不区分大小写，结果一律大写。
- 用「交换」按钮反向转换：它会互换两个进制，并把结果挪到输入框，于是往返校验只需要点一下。
- RFC 模式下选择方向和方式：RFC 4648 Base32、RFC 4648 Base64，或者你自己输入的自定义字典。字段提示会显示字典的字符数，那才是你实际使用的进制。
- 拿结果和你预期的字典比对一遍。被判为非法的值，几乎总是含有该进制没有定义的字符 —— 比如八进制里的 8，或者 Base58 里的小写 l。
实例：同样四个字符，两个毫不相干的结果
把值 2026 分别送进两种模式。两个输出看上去同样像模像样，描述的却是完全不同的东西。
数值进制 2026，源进制 10，目标进制 16
RFC / 自定义 2026，编码，RFC 4648 Base32数值进制 7EA
RFC / 自定义 GIYDENQ=7EA 是整数二千零二十六的十六进制写法：7 × 256 + 14 × 16 + 10 = 2026。GIYDENQ= 则根本不是一个数。它是 0x32 0x30 0x32 0x36 这四个 ASCII 字节 —— 也就是字符串「2026」—— 被重新按 5 比特一组切分、再补位到 8 个字符的结果。把它解码回来，你拿到的是那段文本，而不是那个数值。
各进制的数位字典
数值进制模式覆盖 2 到 36，使用 0-9 之后接 A-Z，这正是 JavaScript 自带的 toString 所用的字典。58、62 和 64 属于字节编码而不是某个数的位置记法，要通过 RFC 模式来用。
| 进制 | 数位 | 在本工具里的位置 |
|---|---|---|
| 2 二进制 | 0 1 | 数值进制模式 |
| 8 八进制 | 0-7 | 数值进制模式 |
| 10 十进制 | 0-9 | 数值进制模式 |
| 16 十六进制 | 0-9 A-F | 数值进制模式；输入不区分大小写，输出一律大写 |
| 32 数值进制 | 0-9 A-V | 数值进制模式。它不是 RFC 4648 Base32，两者永远对不上 |
| 32 RFC 4648 | A-Z 2-7，用 = 补位 | RFC 模式。去掉了 0、1、8、9，所以念出来不容易听错 |
| 36 | 0-9 A-Z | 数值进制模式，也是它的上限 |
| 58 比特币式 | 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz | RFC 模式下的自定义字典。去掉了 0、O、I、l |
| 62 | 0-9 A-Z a-z | RFC 模式；自定义字典输入框的预填内容 |
| 64 RFC 4648 | A-Z a-z 0-9 + /，用 = 补位 | RFC 模式 |
| 64 URL 安全变体 | A-Z a-z 0-9 - _，通常不补位 | 本工具不提供；请用 Base64 编解码工具 |
常见问题排查
负数或小数被拒绝。
成因 数值进制模式只读源字典里的数位，别的一概不认。负号、小数点、千位分隔符、空白以及 0x 前缀，都是没有数位值的字符。
解决办法 先转绝对值，符号自己补回去。遇到小数，请把整数部分和小数部分分开转换；同时记住绝大多数十进制小数没有有限的二进制展开，十进制的 0.1 在二进制里并不精确。
前导零不见了。
成因 工具转换的是「值」，不是「定宽字段」。007EA 和 7EA 是同一个整数，因此都转成十进制的 2026，也都转回 7EA。
解决办法 转换之后再按目标需要的宽度补零。如果前导零本身有意义 —— 补零的账号、定宽的寄存器转储 —— 那你处理的其实是标识符而不是数字，它应该始终是字符串。
Base58 字符串解不出来，或者解出了别的东西。
成因 大小写。数值进制模式会把输入转小写，RFC 4648 Base32 解码会把输入转大写，所以这两者不区分大小写。而 Base64 和所有自定义字典都区分大小写；Base58 尤其如此，它同时使用两种大小写，并刻意去掉了 0、O、I、l，就是为了让这些字形不会被认混。
解决办法 Base58 和 Base64 请按收到的样子原样粘贴，别让编辑器或聊天客户端替你「修正」大小写。如果字符串里出现了 0、O、I 或 l，那它就不是比特币式 Base58，你拿错字典了。
自定义字典的输出和别的 Base58 实现对不上。
成因 自定义字典模式把字节整体当作一个大整数，再按所选进制写出来。比特币式 Base58 也是这么做的，但它之后还会为每一个前导零字节补上一个字典首字符。本工具不补，因此字节 00 00 01 02 03 编码成 Ldp，解码回来只剩 01 02 03 —— 零字节没了。
解决办法 这个模式适合短标识符和没有前导零字节的个性化编码。涉及地址、密钥或任何 Base58Check 的场景，请使用实现了前导零规则和校验和的现成库。
适合用这个工具的场景
- 把寄存器转储、颜色码或堆栈跟踪里的十六进制值，读成一个普通的十进制数。
- 在推敲 chmod 或 ACL 时，把权限掩码在八进制和二进制之间来回换算。
- 处理远超 64 位的整数 —— 转换走的是任意精度运算，而不是浮点。
- 从一个已知的值生成 Base58 或 Base62 短标识符，并验证它能解回同样的字节。
应该换用别的工具的场景
- 日常的 Base64 工作，尤其是 URL 安全的令牌。Base64 编解码工具支持 - 与 _ 字典以及不带补位的输入，而这里的 RFC 4648 Base64 选项不支持。
- 把图片转成 Data URL。那是 Base64 图片编解码工具的活，它面向二进制文件并且能预览结果。
- 给数据做指纹、校验或保护。编码在设计上就是可逆的；完整性请用哈希与校验和工具，机密性请用真正的加密。
隐私与数据处理
每一次转换都在当前浏览器标签页内用 BigInt 运算和浏览器自带的 UTF-8 编码器完成，不传输、不存储。同时请对「编码是什么」保持清醒：Base32、Base64 和 Base58 对任何看到输出的人来说都是一步可逆的。它们保护数据免受通道的损坏，从不保护数据免受阅读者。
相关开发者工具
常见问题
Base64 算一种进制吗？
按数值进制模式的含义来说不算。16 进制改写的是一个整数的数位，而 Base64 是把字节流每 6 比特一组重新分组映射到 64 个字符上，再补位。「进制」这个词在这里承担了两种不同的职责，这也正是把两种模式分开的原因。
数值进制为什么停在 36？
因为 10 个数字加 26 个拉丁字母正好 36 个符号，再往上就没有公认的约定了 —— Base58、Base62、Base64 各自选了不同的字典和顺序。超过 36 就必须把字典明确写出来，而这正是自定义字典输入框存在的意义。
能转多大的数？
多大都行。转换使用 BigInt，200 位的值也能精确转换。基于浮点的工具在超过 2^53 - 1 之后就会丢精度，会把 19 位的标识符悄悄四舍五入，本工具不会。
为什么我的 32 进制结果和 RFC 4648 的不一样？
它们是两套只是共用了一个数字的系统。数值 32 进制用 0-9 接 A-V，表示的是一个整数；RFC 4648 Base32 用 A-Z 接 2-7，表示的是字节，还要用 = 补位。两者都没错，但永远不会产出相同的字符串。
自定义字典有什么约束？
两条：至少两个字符，且不能重复 —— 字符重复会让解码产生歧义。顺序和内容同样重要，第一个字符就是数位「零」，所以字母相同、顺序不同的字典，输出完全不同。
能用它来隐藏某个值吗？
不能，这一点值得说得直白些。Base32、Base64 和 Base58 都是公开、有文档、任何人一步就能还原的。值要保密就加密，要能发现被篡改就签名或做哈希。