Base32 编解码

Base32 (RFC4648) 编码与解码。

什么是Base32 编解码?

Base32 是一种把二进制数据编码成纯文本(ASCII 字符)的编码方式,遵循 RFC 4648 标准,只使用 A-Z 和数字 2-7 共 32 个字符(不区分大小写,且刻意去掉了容易与字母混淆的 0、1、8、9),编码后可能用 = 补齐长度。 它和 Base64 目的相同——让二进制数据能安全地放进只支持文本的场景(URL、文件名、语音报读、某些不区分大小写的系统)——但字符集更小、更不容易被人读错或听错。

为什么使用Base32 编解码?

Base32 最常见的实际用途是 TOTP 动态口令(如 Google Authenticator、各类二次验证 App)的密钥格式:网站生成的二次验证密钥几乎都是 Base32 编码的字符串,因为它可以让用户手动输入密钥时不区分大小写、且没有容易混淆的字符。此外 Base32 也用于某些文件系统对大小写不敏感的场景、DNS 相关编码、以及需要「人类可读性」优先于编码密度的场合。 和 Base64 相比,Base32 编码后的字符串更长(每字符只携带 5 bit 而不是 6 bit),但抗听写/抄写错误能力更强;和十六进制相比,Base32 编码密度更高。需要强调的是,Base32 只是编码方式,不是加密算法,任何人拿到编码后的字符串都能直接还原出原始数据,不提供任何机密性。

使用示例

编码文本

输入文本 "Hello",Base32 编码结果为 JBSWY3DP(无需补齐 = 号,因为 5 字节恰好编码为 8 个字符)。

编码带补位

输入 "Hi"(2 字节),编码结果为 JBQQ====,末尾的 = 是为了让输出长度凑成 8 的倍数而做的填充。

解码 TOTP 密钥

网站给出的二次验证密钥类似 JBSWY3DPEHPK3PXP,把它粘贴进解码框可以还原出原始的二进制密钥字节,用于核对该密钥是否和另一处配置一致。

使用提示

如果解码时报错或者结果乱码,先检查字符串里是否混入了小写字母之外的非法字符(比如误把 O 看成 0、把 I 看成 1),Base32 字母表里没有数字 0、1、8、9,遇到这些字符基本可以判断输入有误。

常见问题

Base32 和 Base64 有什么区别?
Base32 使用 32 个字符(A-Z、2-7)编码,比 Base64 更适合不区分大小写的场景(如口述、二维码、文件名),但编码后长度更长。
支持中文 / UTF-8 吗?
支持。编码时先按 UTF-8 转字节再做 Base32,解码时反向还原,中文、emoji 均可正确处理。
数据会上传吗?
不会。编码解码全部在浏览器本地完成,遵循 RFC4648 标准字母表。
Base32 是加密吗,安全吗?
不是。Base32 只是编码格式,没有密钥、不提供机密性,任何人都能反向解码出原文,不能用它来「加密」敏感信息,只适合让二进制数据能以文本形式传输或展示。
和 Base64 有什么区别,该用哪个?
Base64 用 64 个字符编码,密度更高(输出更短)但区分大小写、包含 +/= 等在 URL 或语音场景不友好的字符;Base32 只用大写字母和 2-7,长度更长但不区分大小写、更适合人工抄写和口述,TOTP 密钥等场景通常用 Base32。
为什么末尾会有多个等号?
Base32 要求输出长度是 8 字符的整数倍,原始数据长度不是 5 字节的整数倍时就需要用 = 补齐到规定长度,等号数量由原始数据末尾剩余字节数决定,是标准规定的填充规则,不影响解码。
能处理中文等非 ASCII 文本吗?
可以,Base32 编码的对象是字节而不是字符,工具会先把文本按 UTF-8 编码成字节,再对字节做 Base32 编码,解码时按同样方式还原,因此中文、emoji 等都能正常处理。

相关工具

← 返回工具箱· 数据均在浏览器本地处理,不上传服务器。