base32/

Base32 把每 5 个字节写成 8 个字符，字符表只有 32 个（标准写法是 A-Z 和 2-7），所以长度比原文多约 60%，Base64 只多约三分之一。好处是不分大小写，也没有数字 0、1、8、9，不容易和字母 O、I、B 看混，适合手抄、口述和大小写不敏感的场合，比如 2FA 密钥和文件名。

平时遇到的 Base32，包括 2FA 密钥和大多数编码库的默认输出，都是标准变体（RFC 4648 第 6 节，字母表 A-Z、2-7）。Base32Hex（第 7 节，字母表 0-9、A-V）的特点是编码后的排序和原始字节的排序一致，用在 DNSSEC 的 NSEC3 这类需要排序的地方。两种互相解不出来：选错了常常报「不是 Base32 字符」，也可能解出一堆乱码。

是。TOTP 的 secret（二维码里 otpauth:// 链接的 secret 参数，或者手动输入的密钥）一般是标准 Base32，通常大写、不带 =，有的按 4 个字符一组加空格显示，这里解码时都能识别。解出来是随机字节而不是文字，要勾选「结果显示为 hex」才看得到，比如 JBSWY3DPEHPK3PXP 是 48 65 6c 6c 6f 21 de ad be ef。要生成动态验证码，请用本站的 2FA 工具。

「长度不合法」是说去掉 = 之后，字符数除以 8 的余数是 1、3 或 6，合法的 Base32 只会是 0、2、4、5、7，多半是复制时少了字符。「不是 Base32 字符」会指出是第几个字符：标准变体里没有 0、1、8、9，也没有标点和全角字符；如果内容里有 0-9 和 A-V，可能是 Base32Hex，换一下变体。「= 只能出现在末尾」说明 = 后面还有内容，可能是几段拼在了一起，需要分开解码。空格、换行、小写字母和缺少的 = 都不会报错。

= 用来把长度补到 8 的倍数，不属于数据。解码时有没有都行；编码时「补齐 =」默认勾选，不需要就取消勾选。能不能省略要看接收方：Google Authenticator 的 otpauth 链接格式说明 secret 不需要补齐，一般省略；Python 的 base64.b32decode 则要求必须补齐，少了会报 Incorrect padding。

说明解出的字节不是 UTF-8 文字。2FA 密钥、哈希值、加密数据本来就是二进制，勾选「结果显示为 hex」可以看到原始字节。本工具只按 UTF-8 显示文字，原文用 GBK 等编码时，先勾选 hex，再到本站的文本 / 十六进制工具里选 GBK 转成文字。

先看三点：输入末尾是不是多了换行或空格，本工具按 UTF-8 原样编码，不去掉首尾空白；变体是否一致，Python 里标准写法是 base64.b32encode，Base32Hex 是 base64.b32hexencode（3.10 起提供）；有没有补齐 =。Crockford、z-base-32 这类用别的字母表的变体不在支持范围内，结果不会一样。

不会。编码和解码都在浏览器里完成，不发任何请求，也不保存，2FA 密钥不会离开你的浏览器。