Base64 与 Hex、Base32、Base58、Base85 对比

对比表

这些编码都能把任意字节无损地转成可打印文本，再转回来。区别在于用多少个字符、用哪些字符，以及输出会膨胀多少。

“输出体积”指输入较大时，编码后长度占输入长度的比例。Base64 每 3 个字节需要 4 个字符，Base32 每 5 个字节需要 8 个，Base85 每 4 个字节需要 5 个，Base45 每 2 个字节需要 3 个。Base58 没有固定的分组大小，所以比例是 log(256) / log(58)，约为 1.366。想知道某个具体输入的确切数字，体积计算器会一次性列出全部结果。

同一输入在各编码下的结果

下面是 12 字节的 ASCII 字符串 Hello world! 的九种编码。12 是 3 和 4 的倍数，所以 Base64 和 Base85 各变体都不需要填充。

这里 Base64URL 和 Base64 完全相同，因为输出中没有 + 或 /。区别只在某些字节上才会显现：fb ef be 在 Base64 中是 ++++，在 Base64URL 中是 ----。

Python 标准库覆盖了表中的大部分编码，其中 z85encode 是 Python 3.13 新增的：

import base64

data = b"Hello world!"
print(data.hex())                           # 48656c6c6f20776f726c6421
print(base64.b32encode(data).decode())      # JBSWY3DPEB3W64TMMQQQ====
print(base64.b64encode(data).decode())      # SGVsbG8gd29ybGQh
print(base64.a85encode(data).decode())      # 87cURD]j7BEbo80
print(base64.b85encode(data).decode())      # NM&qnZy<MXa%^NF
print(base64.z85encode(data).decode())      # nm=QNzY<mxA+]nf

Base58 不在标准库里，但几行代码就能写出来，因为它只是对一个大整数做普通的进制转换：

B58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"

def b58encode(data: bytes) -> str:
    n = int.from_bytes(data, "big")
    out = ""
    while n:
        n, r = divmod(n, 58)
        out = B58[r] + out
    zeros = len(data) - len(data.lstrip(b"\0"))
    return "1" * zeros + out

print(b58encode(b"Hello world!"))   # 2NEpo7TZRhna7vSvL
print(b58encode(b"\0\0\x01"))       # 112

每个开头的零字节都会变成字面上的 1，因为大整数无法记住前导零。这就是为什么所有版本字节为零的传统比特币地址都以 1 开头。

各编码的使用场景

Hex

Hex 每个字节用两个字符，是这里体积最大、也最容易阅读的选项。每个字符恰好对应 4 个比特，所以偏移量为 n 的字节总是位于第 2n 和 2n+1 个字符。正因如此，哈希、校验和与调试转储几乎都用 hex。解码器 DEADBEEF 和 deadbeef 都接受。可以用 Base64 转 hex 和 hex 转 Base64 进行转换。

Base32

Base32 只用大写字母和数字 2 到 7。它能在不区分大小写的系统中保持不变（DNS 名称、某些文件系统、在手机上手动输入验证码的人），还避开了容易和 O、I、B 混淆的 0、1、8。身份验证器应用用 Base32 存储 TOTP 密钥，Tor v3 洋葱地址是 56 个小写 Base32 字符。RFC 4648 还定义了 base32hex（0-9 A-V），它能保持原始字节的排序顺序。试试 Base32 编码器。

Base58

Base58 源自比特币。它去掉了容易混淆的 0、O、I、l，以及会破坏双击选中和 URL 的 +、/。比特币地址在此基础上加了一个版本字节和 4 字节校验和，这种格式叫做 Base58Check。IPFS CIDv0 哈希也是 Base58，由于它们以 multihash 字节 12 20 开头，所以总是以 Qm 开头。因为整个输入被当成一个数字处理，转换时间随长度呈平方增长，所以 Base58 用于密钥和哈希这类较短的值。试试 Base58 编码器。

Ascii85、Z85 和 git 的 Base85

Base85 家族把 4 个字节装进 5 个字符，是得到广泛支持的编码中最紧凑的。问题出在字母表上：85 个可打印字符意味着，视变体不同，会包含引号、反斜杠、<、> 或 &。

• Ascii85（Adobe）使用 ! 到 u，输出用 <~ 和 ~> 包起来，四个零字节写成一个 z。PostScript 和 PDF（ASCII85Decode 过滤器）都在用它。
• Z85（ZeroMQ）挑选的字符在 C 和 JSON 字符串字面量中都是安全的，不含引号和反斜杠。它要求输入长度是 4 的倍数。一个 32 字节的 CURVE 密钥是 40 个字符。
• RFC 1924 Base85 原本是一个关于 IPv6 地址的愚人节提案。它的字母表在 git 二进制补丁和 Python 的 b85encode 中延续了下来。

Base85 工具支持全部三种，Z85 另有专门的页面。

Base45

Base45 是为二维码而生的。二维码的字母数字模式恰好能存储 45 个字符（数字、大写字母、空格和 $%*+-./:），每个字符占 5.5 比特，而字节模式下每个字符占 8 比特。Base45 把 2 个字节转成 3 个这样的字符，在二维码中的开销约为 3%。Base64 文本只能使用字节模式，开销为 33%。欧盟数字新冠证书正是出于这个原因使用了 Base45。试试 Base45 编码器。

如何选择

选接收方期望的编码。JWT 库要 Base64URL，身份验证器应用要 Base32，比特币钱包要 Base58Check。如果两端都由你控制，可以参考下面的经验法则：

• JSON、XML、电子邮件或 HTTP 正文中的字节：Base64。每种语言都有快速的内置实现，33% 的开销可以接受。
• 放在 URL、Cookie 或文件名中：不带填充的 Base64URL。
• 需要人来阅读、输入或比对：短哈希用 hex；可能丢失大小写时用 Base32；希望看起来紧凑且没有易混淆字符时用 Base58。
• 每个字节都很宝贵，且解码器由你控制：Z85 或 Ascii85。
• 二维码：Base45。

取舍始终是同一个：字母表越大，输出越短，需要在某处转义的字符也越多。关于 Base64 为什么会膨胀三分之一，见 Base64 体积开销。关于 URL 安全的变体，见 Base64 与 Base64URL。

常见问题