Base32
Base32是一种二进制到文本的编码方式，它把任意二进制数据转换成由32个可打印ASCII字符组成的字符串，目的是让数据能够在只允许传输或存储文本的环境中通过。该编码每个字符代表5个比特，编码后大小写不敏感，因此适合需要人工转录或念读的场景；它由RFC 4648等文档规范化，与Base64同属Base系列编码。
定义
Base32是一种把任意八位字节序列表示为文本的编码方案，采用US-ASCII字符集中33个字符的子集，每个可打印字符承载5个比特的信息，其中第33个字符“=”用于表示填充等特殊处理。
按照RFC 4648的说明，Base32的设计目标是在需要大小写不敏感、但不需要人类可读的场合下表示八位字节序列，它与Base64同属Base系列，区别在于Base32的字母表更小、单个字符携带的信息更少。
Base32不是加密手段，只是编码；编码后的文本可以还原为原始数据，但不提供任何保密性。
原理
Base32以40比特为一组处理输入。编码时先把5个8比特字节拼接成40比特，再按从左到右的顺序切成8个5比特的小组，每个小组的取值在0到31之间，作为索引查字母表得到对应字符，因此5字节输入对应8个输出字符。
标准字母表按照“A”到“Z”再接数字“2”到“7”的顺序排列，即索引0对应A、索引25对应Z、索引26对应2、索引31对应7。
当输入比特数不足40时，在右侧补零凑成整数个5比特组，同时用“=”补足输出的长度。RFC 4648规定了几种情形：末尾剩8比特时输出2个字符加6个“=”，剩16比特时输出4个字符加4个“=”，剩24比特时输出5个字符加3个“=”，剩32比特时输出7个字符加1个“=”，恰好40比特时输出8个字符且不加填充。
以字符串“foo”为例，RFC 4648给出的标准编码结果是“MZXW6===”，而使用扩展十六进制字母表时结果为“CPNMU===”。[1]
编码效率方面，Base32把5个字节变成8个字符，若按ASCII存储体积会膨胀约六成，这一比例高于Base64的约三成。[2]
发展历程
在Base32被正式文档化之前，不同应用各自实现Base编码，字母表和处理方式存在差异。RFC 3548于2003年7月发布，标题为《The Base16, Base32, and Base64 Data Encodings》，由Simon Josefsson编辑，状态为信息性文档，它统一了常用Base编码的字母表和实现注意事项。[3]
RFC 3548后来被RFC 4648取代。RFC 4648新增了“base32扩展十六进制字母表”，其作用是在编码后仍然保持数据的排序顺序。[1]
除标准字母表外，还出现了若干面向不同需求的变体。Zooko Wilcox-O'Hearn设计的z-base-32以便于人工使用和更紧凑为目标，其字母表排除了0、l、v、2等易混淆字符，并按字符出现频率重新排序，曾被用于Mnet项目、ZRTP协议和Tahoe-LAFS项目。
Douglas Crockford提出的Crockford Base32排除了字母I、L、O以避开与数字的混淆，同时排除U以降低产生不当词句的可能，并引入模37校验位用于检错。[4]
GNU Coreutils的命令行工具basenc在自身实现中同时支持标准的base32与base32hex两种编码形式。[5]
应用
Base编码的典型用途是在只支持US-ASCII的环境中存储或传输数据，这类限制可能源于历史遗留，也可能只是为了让数据能够用文本编辑器处理。
由于Base32的字母表不区分大小写且不含“+”“/”这类在文件名与网址中可能引起问题的符号，它常被用于生成标识符、把二进制值嵌入网址或文件名，以及在需要手工转录、念读的场合传递数据。
在软件层面，Base32被多种语言的标准库和第三方库实现。GNU Coreutils提供的basenc工具可以按RFC 4648的约定对数据做base32与base32hex的编解码，命令行的base32命令与其base32模式等价。[5]
在应用层协议中，z-base-32被用于ZRTP协议与Tahoe-LAFS项目，其设计目的是让30字节的密码学数值编码成便于人工操作的短字符串。
局限
Base32只做编码，不提供计算意义上的保密性。RFC 3548明确指出，Base编码只是让原本容易识别的信息在视觉上被掩盖，会让人误以为受到保护，历史上曾因此出现过在公开交流中泄露口令的情况。
相比Base64，Base32的空间开销更大。Base32把5字节膨胀为8字符，而Base64把3字节膨胀为4字符，前者产生的文本明显更长。[2]
标准Base32的字母表按“A”到“Z”再接“2”到“7”排列，编码结果的大小顺序与原始二进制数据的大小顺序不一致，因此标准字母表不能用于需要保持排序的场景，这也是RFC 4648补充base32扩展十六进制字母表的原因。[1]
大小写不敏感带来另一类问题。RFC 4648指出，当base16与base32字母表被按大小写不敏感方式处理时，改变大小写本身可以被用作隐藏信息的通道；如果解码器忽略字母表之外的字符，也会形成类似的隐蔽信道，因此实现应当拒绝含有字母表外字符的输入。
字母表的选择无法同时满足所有需求。RFC 3548指出并不存在一个普遍接受的、能满足全部要求的字母表，标准Base32字母表中不含数字0和1，解码器可以按上下文把0解释为O、把1解释为I或L，但这并不是默认行为。
参见
参考资料
- rfc4648 [引用日期2026-10-14]
- Base32 [引用日期2026-10-14]
- rfc-editor.org 上的网页 [引用日期2026-10-14]
- Base32 [引用日期2026-10-14]
- basenc-invocation [引用日期2026-10-14]