安全实用 本地计算 开箱即用 内置示例 不留痕迹

Base32 在线编码解码

把文本转成只用 A~Z 与 2~7 的 Base32 串，或把 Base32 串还原成文本。Google Authenticator 的两步验证密钥、部分软件的激活码都是这个格式，所以这里刻意做了「宽松解码」：小写、空格、连字符与 = 填充都可以带。转换在浏览器本地完成，密钥不出本机。

Base32 把数据转成只用 A~Z 与 2~7 这 32 个字符的串：全大写、不含 0、1、8、9，手抄、口头传达都不容易错。两步验证密钥、部分软件的激活码就是这个格式。本工具按 RFC 4648 双向互转，编码结果附每 8 字符分组写法，对账抄写时不易错位。

它比 Base64 长约 60%，换来的是可手抄——这是给人用还是给机器用的取舍。解码方向做了宽容处理：小写、空格、连字符与 = 填充都能带；但字母表之外的字符（出现 0、1、8、9 就说明抄错了）会直接报错，不做猜测性纠错。编码不是加密，谁拿到都能还原。

—

—
—

使用步骤

  1. 选方向：文本转 Base32，或 Base32 转文本。
  2. 粘贴内容；解码时带空格、连字符、小写都没关系。
  3. 编码结果看分组写法核对位数，主结果是可直接使用的连续串。
  4. 解码报错时先查 0/1/8/9 与长度（应为 8 的倍数，= 补齐）。

计算原理与示例

基本用法

先选方向，再填内容：编码方向得到 Base32 串，同时给出「每 8 字符分组」的写法——手抄或对账时不容易错位；解码方向把 Base32 还原成文本。主结果右侧的复制按钮拿到的就是可粘贴的完整值。

为什么 Base32 比 Base64 长

Base32 的字母表只有 32 个符号（A~Z 加 2~7），每 5 位放一个字符；Base64 用 64 个符号、每 6 位一个字符。同样的数据，Base32 大约长 60%，换来的是「全大写、不含易混淆符号、可以手抄」——两步验证密钥、激活码这类要人手输入的场景才用它。

解码报错通常是什么原因

Base32 字母表里没有 0、1、8、9（只有 2~7），所以 O/0、I/1 写混时通常一眼能看出来。另一个常见原因是长度：结果长度要是 8 的倍数，不足但末尾由 = 补齐，长度不对就无法还原。本工具会自动忽略空格、连字符与填充，并接受小写输入。

口径：按 RFC 4648 的 Base32 字母表（A~Z 与 2~7）编码，输入按 UTF-8 转字节后每 5 位取一个字符，末尾用 = 补足到 8 的倍数；解码容忍小写、空格、连字符与填充，遇到字母表之外的字符直接报错，不做纠错猜测。

代码示例

Python 标准库直接支持 

import base64

base64.b32encode(b"hello")     # b"NBSWY3DP"
base64.b32decode("NBSWY3DP")   # b"hello"

# 中文先按 UTF-8 编码再转，一个汉字约 3 字节，结果会明显变长

Shell 命令行互转 

echo -n "hello" | base32        # Linux（GNU coreutils 自带）
echo "NBSWY3DP" | base32 -d     # 解码

# macOS 没有内置 base32，装 GNU 版：
# brew install coreutils，然后 gbase32

常见问题

Base32 和 Base64 有什么区别？

Base64 用 64 个符号（含大小写与 +/），每 6 位放一个字符，体积只比原文大约 33%，但结果里会出现大小写混排与 +、/ 这类符号，抄写和口头传达都容易错。Base32 只用 32 个符号、全大写、不含 0/1/8/9，体积大约多 60%，代价换来了可手抄——两步验证密钥就是典型场景。

为什么两步验证的密钥都用 Base32 写？

两步验证密钥需要用户手动抄进验证器、有时还要在客服电话里念出来，因此要避开大小写混排和 0/O、1/I/l 这类易混字符。Base32 的字母表正好满足：全大写、只用 2~7 与 A~Z，抄错或听错的风险最低。

解码提示非法字符，一般是哪里错了？

最常见的是输入里带了 0、1、8、9 或空格以外的符号——Base32 的字母表里没有这四个数字。其次是长度不对：正确长度应为 8 的倍数（末尾用 = 补齐）。还有一种是把 Base64 的串当 Base32 粘贴过来了，两者字母表不同，无法互相识别。

结果里的空格分组会影响复制使用吗？

不会。分组只是给人看的：复制时把空格一起带走也能用，本工具解码时会自动忽略空格、连字符与填充。真正需要原样粘贴进配置文件（如 Base32 密钥）时，建议用主结果里的连续写法。

中文和 emoji 编码后会变长很多吗？

会。文本先按 UTF-8 转成字节再编码，一个汉字通常占 3 字节、一个 emoji 占 4 字节，而英文单词里的字母只占 1 字节，所以中文内容的 Base32 结果会明显更长。例如「你好」2 个汉字是 6 字节，编码后是 10 个字符（4S62BZNFXU）。

Base32 能当加密用吗？

不能。编码只是换一种写法，谁拿到串都能一键还原，它不提供任何保密性。密钥、口令不要指望靠 Base32 藏起来；真要保护内容需要加密算法（如 AES）并妥善保管密钥。本工具也刻意不做任何「加密」字样。

为什么解码出来的文本里有乱码方块？

说明这段 Base32 并不是某个文本的编码结果，而是二进制数据（如图片、压缩包的一段、随机字节）。这些字节按 UTF-8 解释时无法对应到合法字符，就显示成替换符号。想确认原始字节数可以看结果下方的字节数统计。

页面上的转换会不会把密钥发到服务器？

不会。编解码在浏览器内完成，输入内容不经过服务器，也不写入 localStorage——本工具没有「计算历史」区块，正是因为输入里常含两步验证密钥。

延伸阅读

来自本站原创文章，讲清这个工具背后的算法与口径。