Base32 编码与解码

功能

• 双向转换：文本 ⇄ Base32
• 两种字母表：标准 Base32（A–Z、2–7）与 base32hex（0–9、A–V）
• 可补 = 填充，也可输出不带填充的紧凑形式（解码两者都认）
• 中文与 emoji 按 UTF-8 字节编码，与各语言的标准实现一致
• 解码容忍小写、空格、换行与缺失的填充
• 字母表之外的字符会指出具体是哪一个，不会静默丢弃

使用方法

1. 选择方向：编码或解码
2. 选择字母表：标准 Base32 或 base32hex
3. 把内容粘贴进输入框，结果实时出现
4. 点「复制」取走结果

常见问题

Base32 和 Base64 有什么区别？

编码的是同一份字节流，区别只在「用多少个字符表示 5 位还是 6 位」以及字母表怎么选。Base64 用 64 个字符、每 3 字节编成 4 个字符；Base32 用 32 个字符、每 5 字节编成 8 个字符。Base32 的结果长 60%，换来的是字母表小、不含易混字符、且不区分大小写。要放进 URL 或数据库时选 Base64；要人手抄、口头念、或者写进设备标签时选 Base32。

为什么 Base32 的结果比原文长这么多？

因为每个 Base32 字符只承载 5 位信息，而一个字节是 8 位。8 ÷ 5 = 1.6，所以结果必然是原文的 1.6 倍（再加上填充）。Base64 是 8 ÷ 6 ≈ 1.33 倍。这不是实现问题，是「字母表越小、长度越长」的必然代价。

base32hex 和标准 Base32 该用哪个？

绝大多数场合用标准 Base32 —— 它是默认、也是各家实现默认认的那张表。base32hex 的价值在「排序」：它的字母表按 0–9、A–V 排列，于是按字典序比较两个编码串，结果与按字节序比较原文完全一致。需要把编码结果当数据库主键、或者要在 DNS 里做有序二分查找（NSEC3）时才需要它。两者互不兼容，同一份数据编出来是两串完全不同的字符。

解码时提示某个字符不在字母表里？

多半是拿错了字母表。标准 Base32 不含 0、1、8、9，所以一段带 0 的串在标准表下必然报错 —— 换成 base32hex 就能解。反过来，含 W、X、Y、Z 的串只能是标准 Base32（hex 表到 V 就结束了）。另一种可能是原文被截断了，末尾半个字符组落进了别的可见字符。

解码出来报「不是合法的 UTF-8 文本」？

说明这段 Base32 装的是二进制，不是文字 —— 图片、密钥、压缩包都会这样。Base32 本身只负责承载字节，不知道里面是什么。本工具的输出是文本框，没法展示二进制，所以宁可明确报错，也不把它替换成一串「问号方块」让你以为解出来了。