Base32 与 Base58 编码完全指南:字母表、和 Base64 的区别、比特币地址与 TOTP 密钥
讲清 Base32 和 Base58 各自的字母表与适用场景,为什么 Base58 去掉 0OIl 用于比特币地址,Base32 RFC 4648 为什么是 TOTP 密钥的标准,以及它们和 Base64 的真实差异。
Base32 与 Base58 编码完全指南:字母表、和 Base64 的区别、比特币地址与 TOTP 密钥
大家熟悉 Base64,但 Base32 和 Base58 用得少,真用到时往往一头雾水。我自己第一次解一个 Solana 公钥时,顺手用了 Base64,结果解出一堆错字节,排查了半天才发现是字母表选错了。这篇把这三种编码的字母表、膨胀率和真实使用场景讲清楚,顺便说明它们到底差在哪。
编码到底在做什么
二进制数据要在文本通道里传输,比如塞进 URL、写进二维码、念给同事听,就得用一套可见字符把字节重新表达出来。Base64、Base32、Base58 都是干这件事,区别在于用多大的字母表、怎么打包字节。
字母表越小,生成的字符串越长,但能避开容易混淆或需要转义的字符。这就是为什么明明 Base64 更短,链上地址和 TOTP 密钥却偏偏不用它。
Base32:RFC 4648 与三种变体
Base32 用 32 个字符,每 5 个比特打包成 1 个字符,膨胀率固定是每输入 1 字节出 1.60 个字符。它有三种常见变体,字母表不同:
- RFC 4648 标准:字母表是
A-Z加2-7,带=填充。这是 TOTP / 双因子认证密钥的事实标准。 - Crockford:故意去掉
I L O U这 4 个手写印刷易混的字母,解码时大小写不敏感,还允许写连字符方便念出来。适合优惠券、账户 ID 这类人手输入的代码。 - base32hex:字母表是
0-9 A-V,编码后按字符串排序能保持原始字节序,数据库做范围查询、生成 ULID 时靠的就是这个性质。
Base32 最大的好处是大小写不敏感、不含任何标点。Google Authenticator、Authy 这些 App 全部认 RFC 4648 标准,你换成 Crockford 它直接拒绝,因为字母表完全不同。这是新手最常踩的坑:以为 Crockford 能和标准互通。
Base58:为什么去掉 0OIl
Base58 用 58 个字符,膨胀率约每字节 1.37 个字符,和 Base64 差不多紧凑,但只用纯字母数字,没有 + / = 这些需要 URL 转义的符号。
它最有名的设计是去掉了 4 个容易看错的字符。比特币在 2009 年定的字母表去掉了 0(数字零)、O(大写 o)、I(大写 i)、l(小写 L)。原因很直接:地址要靠人抄写、对照、读出来,这 4 个字符在不少字体里几乎一模一样,一旦看错地址就转错钱,而链上转错是找不回来的。
要注意的是 Base58 有两套不兼容的字母表。瑞波(XRP)几年后上线时故意把字母顺序打乱,这样比特币地址粘进瑞波钱包会在解码层直接报错,而不是默默解成另一个看起来合法的错地址。所以解一个地址前,你必须先知道它是哪条链来的。顺带一提,Solana 公钥用的是比特币的字母表,不是瑞波的。
和 Base64 的真实区别
很多人以为 Base58 就是 "Base64 减几个字符",这是错的。Base64 是定长 6 比特打包,每 3 字节固定出 4 个字符;Base58 是 BigInt 大整数长除法,长度会随内容轻微浮动,因为 58 不是 2 的幂。
更关键的是前导零处理。用裸 base58 编一个开头是 0 字节的数,这些前导零会直接消失,因为大整数除以 58 不管前面有几个零。标准做法是先数前导零字节,再在结果前手动补对应数量的字母表第 0 个字符(比特币是 1)。这就是为什么比特币地址常常以 1 开头,Base64 完全没有这套机制。
一个真实编码示例
拿 Base32 / Base58 编解码器(/zh/t/base32-base58-encoder/)试一下前导零的处理:在 Hex 模式输入 0000ff,选 Base58 Bitcoin 编码,输出是 11LUv。前面那两个 1 就是两个前导零字节正确往返的结果,不是凑出来的。这一步是判断一个 base58 实现对不对的最快办法。
再看膨胀率对比。同样 32 字节的数据,hex 是 64 字符,Base32 大约 52 字符,Base58 Bitcoin 大约 44 字符,Base64 大约 43 字符。给二维码选编码时,如果通道只接受大写字母和数字,Base32 完美匹配 QR alphanumeric 模式;如果能接受任意字节,Base58 字符更少更划算。
TOTP 密钥为什么是 Base32
设置双因子认证时,密钥要写进 otpauth:// URI,被 Authy、Google Authenticator 导入。这些场景全部用 Base32 RFC 4648,原因还是 Base32 大小写不敏感、不含标点,密钥真的可能要从便利贴上抄、要在电话里念。流程很简单:生成 10 到 20 字节随机数,用 Hex 模式粘进来,选 Base32 RFC 4648,出来类似 JBSWY3DPEHPK3PXP 这样的字符串就是标准密钥。
如果只是内部恢复码,可以再用 Crockford 编一遍对比,它去掉了 I L O U,念起来更不容易错,但别擅自塞进真正的 TOTP URI,除非接收方明确支持。需要把字节先转成 hex,可以用 Base64 编码解码器(/zh/t/base64-encoder/)之类的工具先过一道,再喂给编码器。
小结
三种编码各有各的位置:Base32 RFC 4648 是 TOTP 密钥的标准,Base32 Crockford 服务人手输入,Base58 去掉 0OIl 服务链上地址,而它们和 Base64 的差别不只是字符多少,还有打包方式和前导零处理。选对字母表,比解码本身更重要。
Made by Toolora · Updated 2026-06-13