Base32 编解码

填充规则

Base32 每 5 位对应一个字符，而一个字节是 8 位，所以编码结果是字节数的 1.6 倍向上取整。RFC 4648 要求把结果补齐到 8 个字符的倍数，不足的部分用 = 填。1 个字节编出 2 个字符，补 6 个 =；2 个字节 4 个字符补 4 个；3 个字节 5 个字符补 3 个；4 个字节 7 个字符补 1 个；5 个字节正好 8 个字符，不用补。

结尾的 = 只是为了让长度对齐，本身不含信息，解码时可以完全忽略。本工具解码时会主动去掉空白和结尾的 =，所以带填充和不带填充的写法都能识别；编码时勾选「去掉结尾的填充」就得到无填充版本。

为什么 TOTP 密钥不带填充

两步验证（TOTP）的密钥是随机的二进制串，通常用 Base32 写进二维码里的 otpauth:// 链接或手动录入框。密钥本身没有长度对齐的需求，而 = 在 URL、表单和复制粘贴时容易被忽略或转义，所以 RFC 4648 允许在双方约定好时省略填充，Google Authenticator、1Password 这类应用生成的密钥基本都是无填充写法。本工具用无填充写法录入 TOTP 密钥时同样能正确解码。

和 Base64 相比，Base32 的字符集只有大写字母 A–Z 加数字 2–7，不含容易混淆的 0 和 1，也不区分大小写，适合人工抄写、语音报读，以及在会统一转成大写的系统里传输。代价是同样的数据体积膨胀到约 1.6 倍，比 Base64 的 1.33 倍更大。如果要塞进二维码或做短链，通常会用更短的 Base58 或 Base64URL。

文本按 UTF-8 编码后再转 Base32，所以一个汉字会先变成 3 个字节再参与编码。反过来解码时，如果解出的字节不是合法的 UTF-8（例如直接解一段随机二进制密钥），工具会提示「解出来的字节不是 UTF-8 文本」，而不是给出一串乱码。全部计算都在浏览器本地完成，不经过服务器。