Base32 编码解码
将文本或十六进制字节编码为 Base32(RFC 4648),或将 Base32 解码为文本。支持标准字母表和 Base32hex 字母表,可选择是否添加 = 填充。
Base32:按 RFC 4648 §6 的定义。
Base32 只用 32 个字符——大写字母 A–Z 和数字 2–7——来表示二进制数据,因此结果在不区分大小写的系统、文件名中,甚至口头念出来时都不会出错。验证器 App(TOTP 两步验证码)背后的密钥就是这种格式,它定义在 RFC 4648 中。这个工具可以把 UTF-8 文本或原始十六进制字节编码为 Base32,也可以把 Base32 解码为文本和字节。
使用方法
- 选择编码或解码。
- 粘贴文本;如果编码的是原始字节,请把“输入格式”切换为十六进制。
- 除非你的系统要求 Base32hex(例如 DNSSEC 的 NSEC3 记录中使用),否则保持标准字母表。
- 如果接收方不希望末尾带 = 符号,请取消填充(大多数 TOTP 应用两种都接受)。
计算公式
每 5 个字节(40 位)拆成 8 个 5 位的分组,每个分组(0–31)选出字母表中的一个字符。
最后不足一组的部分用 0 位补齐;开启填充后,用 = 符号把长度补到 8 的倍数。输出大小是输入的 8/5,即增加 60%,而 Base64 约增加 33%。
示例
对文本 "foobar"(6 个字节)编码,得到的是 RFC 4648 的官方测试向量 MZXW6YTBOI======。前 5 个字节生成 MZXW6YTB,第六个字节 "r" 生成 OI,再补上六个 = 号,凑满 16 个字符。使用 Base32hex 字母表时,同样的输入会变成 CPNMUOJ1E8======。
常见问题
为什么两步验证的密钥看起来像 JBSWY3DPEHPK3PXP?
验证器 App 把共享密钥保存为 Base32,这样人工输入时不会混淆相似的字母和数字。在这里解码,就能以十六进制看到原始的密钥字节。
为什么标准 Base32 里没有 0、1、8 和 9?
RFC 4648 去掉了 0、1 和 8,因为它们长得像 O、I/L 和 B。数字只用 2–7,加上 26 个字母,正好 32 个符号。
Base32 是加密吗?
不是。它是一种没有密钥、可逆的编码,任何人都能解码。要保护数据,请使用真正的加密。
解码时在意小写或空格吗?
不在意。解码器会忽略空格和换行,接受小写字母,并且无论有没有 = 填充都能工作。
资料来源
最后更新:
包含这些输入的页面地址: https://kakao.mobile/zh/tools/base32-encoder/
引用此工具
kakaoCalc. (2026, November 8). Base32 编码解码. https://kakao.mobile/zh/tools/base32-encoder/
“Base32 编码解码.” kakaoCalc, 8 Nov. 2026, kakao.mobile/zh/tools/base32-encoder/.