Base32 编码 / 解码器

什么是 RFC 4648 Base32

Base32 是一种二进制到文本的编码，使用 A-Z 和数字 2-7 表示任意字节。每个输出字符承载 5 位，因此字母表正好需要 32 个符号。它比 Base64 更长，但不含标点，通常更适合人工抄写、大小写不敏感的标识符和只接受字母数字的系统。

本页把普通文本先转换为 UTF-8 字节，再进行 Base32 编码。这个步骤决定了重音字符、中文、日文和 emoji 是否能与其他工具正确互通。解码时先恢复字节，再使用严格 UTF-8 解码；如果原始内容其实是密钥、压缩数据或随机字节，而不是文本，就会明确报错。

填充开关只控制末尾等号。RFC 4648 可把输出补到 8 的倍数，但很多协议在长度已知时省略填充。解码器同时接受两种形式，同时检查末尾未参与完整字节的位必须为零，避免多个不同字符串表示同一组字节。

如何使用 Base32 转换器

1. 输入普通文本时选择编码；已有 Base32 字符串时选择解码。
2. 编码时确认目标协议是否要求等号填充。明确要求固定 8 字符分组时应保留填充。
3. 输入或粘贴内容，页面会本地实时转换；字母表、长度、填充或 UTF-8 不合法时不会猜测。
4. 用官方向量或 Unicode 示例对比其他库、命令行工具和 API。
5. 复制结果或切换方向做往返验证，但仍需单独确认目标协议的填充规则。

Base32 示例与官方向量

以下示例同时覆盖 RFC 4648 测试向量、Unicode、大小写和填充策略。可使用上方示例按钮按对应方向与选项复现。

可接受输入、填充与规范形式

编码接受有效 Unicode 文本并使用 UTF-8。解码只接受 A-Z、2-7、可选小写字母，以及末尾连续的等号。空格和换行不会被自动删除，因为严格模式更容易发现密钥或标识符在复制时被破坏。

无填充数据字符的长度模 8 只能是 0、2、4、5 或 7；其他余数无法组成完整字节。有填充时，等号数量必须与最后一个量子精确对应。

• 规范编码输出使用大写 A-Z 与数字 2-7。
• 填充只能出现在末尾，填充后的总长度必须能被 8 整除。
• 数字 0、1、8、9 不属于 RFC 4648 Base32 字母表。
• 末尾未使用位非零时会拒绝，而不是静默丢弃。
• 有效 Base32 也可能代表非 UTF-8 二进制数据。

Base32 如何处理字节

编码器从左到右读取 UTF-8 字节，把位加入小缓冲区。每当至少有 5 位，就取出一个 0-31 的值作为字母表索引。最后不足 5 位的部分向高位对齐并用零补齐；启用填充时再补等号到 8 字符边界。

解码器把每个符号映射回 5 位，并在累计到 8 位时输出一个字节。恢复的字节不是按 ASCII 强行解释，而是交给严格 UTF-8 解码器，因此 你好 这样的文本可以按六个字节正确往返。

位运算前会验证字母表、允许的长度余数和准确填充数；结束后再检查残余位为零。该策略遵循 RFC 4648 的严格倾向，更适合协议测试，而不是自动清理可疑输入。

Base32 适合哪些场景

Base32 适用于需要文本形式、又不希望出现标点或大小写敏感问题的字节数据。它不是加密，也不提供完整性，真实协议通常还会加入校验和、MAC 或其他结构。

常见 Base32 错误与边界

最常见问题是混用字母表、复制不完整，或套用了另一个系统的填充规则。字符串看起来像 Base32，也可能具有不可能的字符数量；工具会直接报告，而不是自动补删数据字符。

Base32 表示的是字节，不一定是文本。若内容是哈希、密钥或文件，恢复的字节可能不是 UTF-8。本页面面向文本，因此会报 UTF-8 错误；代码中应保留 Uint8Array。

• 把 0 或 1 当作 O 或 I 会触发非法字符错误。
• 单个数据字符无法表示完整字节。
• 位于中间的填充符始终非法。
• 修改最后一个符号可能造成未使用位非零。
• Base32 可被任何人解码，不提供保密性。

Base32 与相关编码的区别

应按传输约束选择编码。Base32 用更长文本换取更小、更易抄写的字母表；Base64 更紧凑，Base58 则去除易混淆字符并采用大整数进制转换。

并非所有名为 Base32 的格式都使用同一字母表。Crockford Base32、base32hex 和 z-base-32 都有不同规则，本页只实现 RFC 4648 标准字母表。