Base32 编码解码

免费在线 Base32 编码解码 工具。100% 本地计算，数据不离开您的设备，隐私安全有保障。

输出

结果将显示在这里...

输入 → 编码

使用指南

关于 Base32

Base32（RFC 4648）使用 32 个 ASCII 字符（A–Z 和 2–7）对二进制数据进行编码。它专为需要仅含字母数字、大小写不敏感输出的场景设计，例如 DNS 标签、文件名和双因素认证密钥。

Base32 与 Base64 如何选择：Base32 输出更长（约 1.6 倍，而 Base64 约 1.33 倍），但在大小写不敏感的环境中更安全，且不含特殊字符。TOTP 密钥和 DNS 安全标识符使用 Base32；通用二进制编码使用 Base64。

使用步骤

Base32 是可逆的——同一工具既可编码也可解码：

•
1. 输入内容在输入框中粘贴或输入要编码的文本
•
2. 编码/解码点击「加密」进行编码，点击「解密」进行解码
•
3. 复制结果点击「复制」复制输出结果
隐私保护：所有处理均在您的浏览器中本地完成，不会向任何服务器发送数据。

输出格式

Base32 输出使用大写字母 A–Z 和数字 2–7，并用 = 填充至 8 字符的整数倍。示例："hello" → "NBSWY3DPEB3W64TMMQ======"。

•
字符集A–Z（26 个字母）+ 2–7（6 个数字）= 32 个符号
•
填充字符= 用于填充至 8 字符边界
•
大小写不敏感解码器同时接受大写和小写输入
•
体积开销输出约为输入的 1.6 倍（5 字节 → 8 字符）

Base32 与其他编码的对比

根据使用场景选择合适的编码方式：

•
Base32 vs Base64Base32 输出约长 25%，但仅含字母数字和 2–7（在 DNS、文件系统、大小写不敏感场景中更安全）
•
Base32 vs 十六进制Base32 比 十六进制更紧凑（5 字节 → 8 字符 vs 10 个十六进制字符），同时保持 URL/文件名安全
•
主要用途TOTP/HOTP 密钥（Google Authenticator）、DNS 标签、文件名、大小写不敏感标识符
对于大小写敏感环境下的通用二进制文本编码，建议使用 Base64 ——效率高出约 25%。

常见问题

Q: 为什么 Base32 输出末尾有 = 符号？

A: Base32 每个字符编码 5 位，以 5 字节（40 位）为一个处理块。若输入长度不是 5 的倍数，则会添加填充字符（=）以补齐最后一个块。在紧凑存储时可去除填充，解码前重新添加即可。

Q: Base32 在实际中用于哪些场景？

A: 最常见的实际应用是 TOTP/HOTP 密钥——Google Authenticator、Authy 及所有兼容 RFC 6238 的应用均将共享密钥编码为 Base32 字符串。此外，Base32 还用于 DNS（NSEC3 记录）、Tor .onion 地址（v3）、比特币 Bech32 地址，以及不区分大小写的文件系统安全标识符。

Q: 可以解码没有填充字符的 Base32 吗？

A: 可以——本工具接受带或不带尾部 = 填充的 Base32 输入，解码时会自动处理填充问题。

Q: Base32 和 Base32Hex 有什么区别？

A: 标准 Base32（RFC 4648 §6）使用 A–Z + 2–7；Base32Hex（RFC 4648 §7）使用 0–9 + A–V——其排序顺序与原始二进制数据一致，适合有序查找场景。本工具实现的是标准 Base32。

Q: Base32 是加密或安全机制吗？

A: 不是。Base32 仅是一种编码方案，完全可逆，不提供任何保密性或完整性保障。任何人看到 Base32 字符串都能立即解码。如需加密，请使用 AES-256-GCM 或 ChaCha20-Poly1305。

使用场景

推荐：TOTP/HOTP 双因素认证密钥

双因素认证应用（Google Authenticator、Authy、Microsoft Authenticator）将共享 HMAC 密钥编码为 Base32 字符串。扫描二维码配置 2FA 时，嵌入的数据即包含 Base32 编码的密钥。这是 Base32 最主要的现实应用场景。

推荐配置：
  • ✅ Base32 是 TOTP/HOTP 密钥的标准编码方式（RFC 6238、RFC 4226）
  • ✅ 生成兼容身份验证器的共享密钥时使用 Base32
  • ❌ 不要将 Base32 编码的密钥与加密或哈希值混淆——它是可逆的
推荐：DNS 安全与大小写不敏感标识符

Base32 输出仅包含字母数字字符（无 +、/、=），结合大小写不敏感特性，适用于 DNS 标签、大小写不敏感文件系统（Windows、macOS HFS+）的文件名以及电子邮件本地部分。

推荐配置：
  • ✅ Base32 用于 DNS 安全标识符（NSEC3 哈希使用 Base32Hex）
  • ✅ Base32 用于需要在大小写折叠中保持稳定的文件名
  • ✅ Base32 用于 Tor v3 .onion 主机名
  • ❌ 在大小写敏感场景下需要紧凑编码时，优先使用 Base64
可接受：人工抄写码

Base32 避免了部分字体中视觉上容易混淆的字符（0/O、1/l）。数字范围 2–7 专门排除了 0 和 1，使其适合用于印刷码、语音读取标识符或激活密钥。

推荐配置：
  • ✅ Base32 用于用户可能手动输入的激活码或许可证密钥
  • ⚠️ 若需更严格的可读性，考虑使用 Crockford Base32（额外排除 I、L、O、U）
  • ❌ Base32 不适合对体积敏感的大型二进制数据——输出约为输入的 1.6 倍
不推荐：通用二进制编码

对于存储或传输任意二进制数据（图片、加密密钥、证书），Base64 是更好的选择——紧凑 25% 且获得广泛支持。Base32 的主要优势（大小写不敏感）在数据不被显示时并无意义。

推荐配置：
  • ❌ Base32 不适合在 JSON、XML 或 HTTP 头中嵌入二进制文件——请使用 Base64
  • ❌ Base32 不适合 PEM 证书或 SSH 密钥材料——请使用 Base64
  • ✅ Base64 适用于所有通用二进制文本编码场景

最佳实践总结

  • 需要大小写不敏感、仅含字母数字的输出时使用 Base32——主要用于 TOTP 密钥和 DNS 安全标识符。
  • Base32 不是加密——输出对任何人都是完全可逆的。
  • 在大小写敏感的系统中需要紧凑二进制编码时，优先使用 Base64（效率高 25%）。
  • 标准字符集为 A–Z + 2–7（RFC 4648 §6），故意排除数字 0 和 1 以减少抄写错误。

讨论与反馈

0 条评论
我