如何用 Base64 与 Hex 编码和解码数据
何时以及为何使用 Base64、Base64-URL、Base32 与 Hex；二进制无法当 ASCII 时怎么办；以及如何解码且不丢失末尾零。
与本篇教程搭配使用的更多工具：
为什么这个工具重要
二进制数据必须经过只接受文本的系统传输。典型例子：把 PNG 放进 JSON API。Base64 把每 3 字节变成 4 个 ASCII 字符，这是安全传输的代价。变体搞错（+/ vs -_，有无填充）解码就会出一堆乱码。弄清该用哪种编码及其坑点，就能把「一行报错」变成无事发生。
三个真实场景
将文件编成 Base64 写入 JSON，服务端再解码回字节。
单次往返搞定
按点号分段，对 header 与 payload 做 Base64-URL 解码，再用密钥核对签名。
校验签名
粘贴十六进制对，编解码工具输出原始字节供后续分析。
还原二进制帧
操作演练
打开 编解码工具。
选择编码
Base64（RFC 4648 标准）、Base64-URL（URL 安全）、Base32 或 Hex。字母表与填充规则各不相同。
放入输入
文本或文件在左侧窗格。若为二进制文件而非 ASCII，请切换输入模式。
切换编码 / 解码
对称操作：编码后再解码应还原原文。若解码乱码，多半输入用了另一种变体。
输出选择 UTF-8 或原始字节
文本载荷解码为 UTF-8；图像、压缩包等二进制请下载为文件。
复制或下载
纯文本复制到剪贴板；二进制结果按推断的 MIME 类型下载。
字节
Hello, GitHub?编码
Standard: SGVsbG8sIEdpdEh1Yj8=
URL-safe: SGVsbG8sIEdpdEh1Yj8
(no padding, '+'/'/' replaced with '-'/'_')字节
\x00\x0F\xA5\xFFHex
00 0F A5 FF
实用技巧
- JWT 各部分是无填充的 Base64-URL。 标准 Base64 解码器可能报错 —— 请用 URL-safe 配置。
- 解码前先去掉空白。 从 PDF 粘贴的 Base64 常含软换行，旧解码器可能拒绝。
- 抓包里 Hex 对人类可读；传输优先 Base64。 Hex 体积约为源字节的 2 倍；Base64 约为 1.33 倍。
- 校验文件完整性。 解码后用 哈希生成器 对结果哈希，并与源文件哈希比对。
常见陷阱
常见误区
解码文本出现怪字符或「�」
字节序列合法但并非合法 UTF-8。请把输出模式从「UTF-8 文本」改为「原始字节」/ 文件下载。
常见误区
邮件里粘贴的末尾「=」被拒
部分编码器用 = 填充，部分省略。请按目标要求重新编码（显式填充）或去掉填充以匹配对方。
常见误区
带分隔符的 Hex（00:0F:A5）解码失败
先去掉冒号、空格与换行 —— 解码器期望连续十六进制数字。
不适合用本工具的情况
- 哈希（单向，用于校验或口令存储）— 请用 哈希生成器。Base64 可逆，不是哈希。
- 加密（保密性）— Base64 不是加密。请使用真实算法并保管密钥。
- 压缩 — Base64 增大体积。若在乎大小，应先 gzip 再 Base64。
常见问题
为什么 Base64 有约 33% 开销？
每 3 字节输入映射到 64 字符字母表中的 4 个字符。4/3 ≈ 1.33 倍。输入长度不是 3 的倍数时，填充还会略微增加开销。
Base64 是哈希函数吗？
不是。Base64 是可逆编码。任何人拿到编码串都能还原原文。
工具会上传我的数据吗？
不会。编解码在浏览器内完成；文件不会上传。
延伸阅读
- 用 哈希生成器 对二进制输出做完整性校验。
- 用 HMAC 生成器 为 API 载荷签名。
- 需要在 HTML/CSS 内嵌图片且无 CDN 时，可用 图片转 Base64 工具。