Base32 编解码
按 RFC 4648 把文本编码成 Base32，或把 Base32 解码回文本；支持标准 32 字符表、可选 = 填充、小写输入、忽略空白与中文内容。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
这个工具能做什么
- 在只能传大写字母和数字的场景里携带数据：TOTP 二次验证密钥、`otpauth://` 链接、部分 DNS/域名校验记录都用 Base32。
- 核对别人给的 Base32 密钥：解码回文本确认里面到底是什么，避免把 0/O、1/I 这类易混字符抄错。
- 排查「密钥无效」问题：对比带填充与不带填充两种写法，很多服务端只接受其中一种。
- 把 Base32 当纯文本编码做人工转录时，勾上小写或去掉填充让结果更好读。
示例
输入
foobar
输出
MZXW6YTBOI======
这是 RFC 4648 文档里的标准测试向量；Base32 每 5 个字节编成 8 个字符，长度不足时用 = 补齐到 8 的倍数，所以 6 字节的 foobar 后面有 6 个等号。
常见问题
Base32 和 Base64 该用哪个？
Base32 只用 26 个字母加 2–7 共 32 个字符，编码后比原文长约 60%，但大小写不敏感、没有 `+` `/` `=` 之外的特殊字符，人工抄写和电话口述不容易出错；Base64 只长三分之一，但含大小写与 `+` `/`。需要人读人抄就选 Base32，追求体积就选 Base64。
为什么解码时 0 和 1 会报错？
RFC 4648 的标准字符表是 A–Z 加 2–7，数字 0、1 和 8、9 都不在表内，出现即报「不是合法的 Base32 字符串」。这通常是从 Base64 或纯数字串里抄错了内容，也可能对方用的是 Crockford Base32 之类的自定义字母表。
= 填充可以省略吗？
解码时可以。工具会忽略空白、统一转成大写，并且接受省略填充的输入；只有当你写了 = 但个数与数据长度不匹配时才会报「填充位数不正确」。编码时是否带 = 由「带 = 填充」开关决定。
中文能编码吗？
可以。文本会先按 UTF-8 编码成字节再转 Base32，`中文` 得到 `4S4K3ZUWQ4======`。解码时如果字节序列不是合法 UTF-8（比如原文是二进制文件），会明确报「解码结果不是合法的 UTF-8 文本」，而不是给你一串乱码。
内容会上传到服务器吗？
不会。编解码全部在浏览器里用 JavaScript 完成，页面不发任何网络请求，密钥类内容也不会被记录，断网可用。
关键词：base32base 32rfc 4648encodedecode编码解码base32 转换padding填充