Base32 编码解码

普通文本会先按 UTF-8 编码，再转换为 Base32。
0 输入字符

在线完成 Base32 编码、解码和文件转换，支持 4 种变体、padding 处理、Hex 查看与本地下载，适合 TOTP 密钥、可读 ID 和二进制调试场景。

相关推荐

Base58 编码解码

Base64 编码

URL Safe Base64

十六进制编码解码

文件转 Base64

Base64 解码

什么是 Base32？

Base32 是把二进制数据映射为 32 个可打印字符的编码方案。标准版来自 RFC 4648，默认字符表是 A-Z 和 2-7，每 5 bit 数据对应 1 个输出字符，因此结果通常比原始字节大约多 60%。

Base32 的优势不是最紧凑，而是更适合不区分大小写、人工抄录或需要避免 + / 等特殊字符的场景。TOTP 密钥、某些 DNS / 配置值、人工校验码和可读 ID 都经常使用 Base32。

不同变体会改变字符表和容错规则。本页同时支持 RFC 4648 标准 Base32、Base32hex、Crockford Base32 与 z-base-32，并提供严格校验、padding 开关、换行输出、文本 / 文件互转与十六进制查看，方便你在不同协议和工具链里直接验证结果。

适用场景

  • 校验 TOTP / OTP 密钥是否是标准 Base32，或需要把密钥改写成 Crockford、z-base-32 等更易读的形式时使用。
  • 把二进制配置、证书片段、离线激活码或资源指纹转换为不含特殊符号的可读字符串时使用。
  • 排查第三方系统返回的 Base32 字符串是否缺失 padding、混用了错误变体，或需要严格验证长度时使用。
  • 收到一段 Base32 内容但不确定是文本还是文件时，可先解码查看 UTF-8 / Hex，再决定是否下载原始二进制。

使用方法

  1. 先选择要处理的变体：如果对方文档明确写 RFC 4648、Base32hex、Crockford 或 z-base-32，就按同一种变体操作。
  2. 编码时选择“文本”或“文件”输入，再按需要决定是否输出 padding、是否转小写，以及是否按 64 / 76 字符换行。
  3. 解码时粘贴 Base32 字符串；如果需要更严谨的结果，开启严格校验来检查长度和 padding 是否规范。
  4. 查看输出结果：文本内容可直接复制，非文本内容可切到 Hex 或下载还原后的文件继续排查。

功能特点

  • 4 种 Base32 变体同页切换：RFC 4648、Base32hex、Crockford、z-base-32。
  • 文本与文件双模式：可把 UTF-8 文本编码为 Base32，也可把任意文件转成 Base32 字符串。
  • 解码结果可直接看 UTF-8 文本、Hex，或下载还原后的二进制文件。
  • 支持 padding、大小写与换行控制：可按 RFC 风格每行 64 / 76 字符输出，也能自定义宽度。
  • 严格校验与本地处理并存：需要时可检查长度和 padding，所有编解码过程都在浏览器内完成。

该用 Base32、Base64 还是 Base58？

这几种编码都能把二进制转为可打印字符，但适合的任务并不一样。先看你更在意兼容性、字符安全还是输出长度。

格式更适合取舍
Base32TOTP 密钥、可读 ID、不区分大小写的环境字符集更安全、更适合人工抄录，但输出比 Base64 更长。
Base64通用文本 / 文件传输、Data URL、API 载荷结果更紧凑，但可能出现 + / = 等特殊字符；URL 或文件名场景常要换成 URL-safe 变体。Base64 编码Base64 URL Safe
Base58人工抄写地址、二维码短串、区块链地址不含 0/O/I/l，更适合防混淆，但不是 RFC 4648 体系，和 TOTP / 标准 Base32 场景不能混用。Base58 编码解码

最佳实践

先确认对方要求的是哪一种变体

Base32 问题里最常见的坑不是算法本身，而是标准不一致。对方如果写的是 Base32hex、Crockford 或 z-base-32，必须按对应字符表处理，否则结果看起来像对的，实际却无法被对方系统接受。

调试失败时先切到 Hex 再判断是不是文本问题

Base32 解码后的原始字节不一定是 UTF-8 文本。先看 Hex，能更快分辨它到底是证书、图片头、压缩包、随机密钥还是纯文本。

给人手动录入的字符串优先考虑 Crockford 或 z-base-32

如果你的重点是降低人工录入错误，而不是严格对接 RFC 4648，Crockford 和 z-base-32 会比标准 Base32 更友好。它们能减少 O/0、I/1 这类误读带来的问题。

需要和邮件、API 或文件工具串联时别只盯着 Base32

很多实际任务的下一步不是继续 Base32，而是转成 Base64、Hex 或直接下载原文件继续处理。根据任务链切换到更适合的格式，通常比硬把所有流程都塞进 Base32 更省事。

Base64 编码Hex 转换

常见问题

Base32 和 Base64 该怎么选？

想要更短、更常见的传输格式时，优先用 Base64；想减少特殊字符、兼容不区分大小写的环境，或处理 TOTP 密钥、人工抄录串时，更适合 Base32。Base32 结果会更长，但字符集更克制。

RFC 4648、Base32hex、Crockford、z-base-32 有什么区别？

它们的核心区别是字符表和容错策略。RFC 4648 是通用标准；Base32hex 按数字顺序排列；Crockford 适合人工录入，能容忍 O/0、I/1、L/1；z-base-32 默认小写，常用于更强调可读性的短串。编码和解码必须使用同一变体。

为什么有些 Base32 字符串带 =，有些没有？

RFC 4648 和 Base32hex 常使用 = padding 来补齐长度；Crockford 与 z-base-32 通常不带 padding。本页编码时可以控制是否输出 =，解码时也能在宽松模式下处理缺失 padding 的字符串。

解码后出现乱码怎么办？

这通常不是 Base32 算法错误，而是原始内容不是 UTF-8 文本，例如图片、证书、压缩包或任意二进制数据。此时请切换到 Hex 查看，或直接下载还原后的文件。

支持文件 Base32 编码和文件还原吗？

支持。编码模式下可上传任意文件并生成 Base32；解码模式下可把 Base32 还原为二进制并下载。对于证书、配置包、图片和密钥材料，这比只看文本结果更实用。

上传的文本或文件会发送到服务器吗？

不会。当前页面的 Base32 编解码、Hex 查看与文件下载都在浏览器本地完成，内容不会上传到远程服务器。

故障排查

明明能解码，为什么和第三方结果对不上？

先检查是否选错了变体。标准 Base32、Base32hex、Crockford 和 z-base-32 的字符表不同，哪怕只有一两个字符不同，整体结果也会完全不一样。

开启严格校验后报长度错误怎么办？

这通常说明输入缺少 padding、混入了错误字符，或本来就不是该变体生成的 Base32。可以先关闭严格模式确认大致内容，再根据结果回头修正原串。

为什么解码后得到空白或乱码文本？

原始数据可能不是 UTF-8 文本，而是二进制文件或随机字节。请切换到 Hex 模式，或直接下载解码后的二进制文件继续分析。

术语表

RFC 4648 Base32
最常见的标准 Base32 变体，字符表为 A-Z 和 2-7，可带 = padding。
Base32hex
RFC 4648 定义的十六进制排序变体，字符表为 0-9 和 A-V，便于按数值顺序比较。
Crockford Base32
强调人工可读性和容错的变体，去掉 I、L、O、U，并把 O/0、I/1、L/1 视为等价。
z-base-32
偏向人工输入与短串传输的变体，默认小写、通常不使用 = padding。
padding
标准 Base32 末尾用于补齐长度的 = 字符。RFC 4648 与 Base32hex 常见，Crockford 与 z-base-32 一般不用。

4 种 Base32 变体速查

如果你不确定该选哪个变体，先看字符表和典型用途。

变体字符表是否常用 =典型场景
RFC 4648A-Z + 2-7常用TOTP、标准 Base32 兼容
Base32hex0-9 + A-V常用按数值顺序比较或特定协议字段
Crockford0-9 + A-Z（去 I/L/O/U）通常不用人工录入、短码、容错校验
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769通常不用更强调可读性的短串

标准 Base32 长度与 padding 关系

RFC 4648 / Base32hex 编码时，末尾 = 的数量取决于原始字节长度。

原始字节数有效 Base32 字符需要补的 =
126
244
353
471
580

Authoritative References