Base64 要解决什么问题

很多系统只传"文本"：邮件协议为 7 位 ASCII 设计，JSON 定义为文本，HTML 属性里放的是字符串。但我们真正想传输的东西——图片、PDF、密钥、二进制协议数据——是字节流，里面很容易混进控制字符、引号和换行。

把原始二进制直接塞进文本通道，迟早会出问题：换行被改写、引号提前结束字符串、代理服务器吃掉一个字节。Base64 的做法是：只用 64 个所有文本系统都认的字符重新表示这些字节。

A–Z  a–z  0–9  +  /

末尾的 = 只用于补齐。整个字母表就这些。

Base64 的原理

Base64 每处理 3 个字节（24 位），就把它们重写成 4 个字符（4 × 6 位）：

输入 位数 输出
Man 24 位 TWFu
Ma 16 位 + 补齐 TWE=
M 8 位 + 补齐 TQ==

由此直接得到两个结论：

  1. 结果大约比原文大 33%（3 个字节变成 4 个字符）；
  2. = 的数量告诉解码器最后一组缺了几字节，一个或两个 = 表示末尾不完整。

Base64 是可逆的、完全公开的编码，没有密钥，也没有任何保密性。

日常开发中在哪里遇到 Base64

  • Data URI：background-image: url(data:image/png;base64,...) 把小图标直接内嵌进 CSS。
  • JSON 接口：在 JSON 字段里传文件、缩略图或签名。
  • 邮件附件：MIME 用 Base64 编码附件，让它们能穿过只支持文本的邮件服务器。
  • HTTP Basic 认证：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的编码结果。
  • JWT：Token 的 header 和 payload 两段都是 Base64URL 字符串。

Base64 不是加密

这是最重要的一点：Base64 不提供任何保密性。

任何人拿到 Base64 字符串，打开浏览器控制台一行就能还原——不需要密钥，也不需要工具。编码解决的是"怎么传"，加密解决的是"给谁看"。需要保密就用 TLS 传输 + 真加密（AES-GCM、libsodium、age 等），需要文本通道时再对密文做 Base64。

怎么在线编解码

不用装任何东西。本站的 Base64 在线编解码工具 完全在浏览器本地运行，不上传数据，离线也能用。

  1. 选择「编码」或「解码」；
  2. 把文本或 Base64 字符串粘贴到输入框；
  3. 点击「开始转换」（或按 Ctrl/⌘ + Enter）；
  4. 复制或下载结果。

因为工具是纯 HTML、没有后端，处理内部 ID、配置片段、日志片段都没问题；但生产环境的密钥不要粘进任何你不掌控的在线工具。

五个常见坑

**1. URL-safe Base64 用的是另一套字母表。**标准 Base64 含 + 和 /，它们在 URL 里有含义；URL-safe 版本（RFC 4648 §5）会换成 - 和 _。如果解码器莫名其妙报错，先看字母表。

**2. 补齐的 = 有时被省略。**不少编码器会去掉末尾的 = 省空间，解码时需要自己推断缺失字节。多数库能处理，严格的库会直接抛错。

**3. 换行和空格。**经典 MIME 输出每 76 个字符换行。多数解码器会忽略 \n 和空格（我们的工具也会），但不要假设所有解码器都这样。

**4. btoa() 不认识 UTF-8。**浏览器里 btoa('中文') 会抛 InvalidCharacterError，因为 btoa 只接受 Latin-1。正确做法是先用 TextEncoder 把字符串转成 UTF-8 字节，再编码。靠谱的工具都替你做了这件事。

**5. 重复编码。**对已经是 Base64 的内容再编码一次，会得到一层"看起来合法但没有意义"的结果。如果解码出来仍是乱码，多半是编码了两遍，或者你编码的本来就不是文本数据。

常见问题

Base64 会让数据变大多少？ 压缩前大约 33%。1 MB 的图片会变成约 1.37 MB 的文本。

能手工解码吗？ 理论上可以，它就是一张 6 位映射表；实际上用工具更快。

Base64 会压缩数据吗？ 不会，它会膨胀。想要更小的体积，先压缩（gzip、Brotli、zstd）再编码。

Base64 能直接放进 URL 吗？ 只有 URL-safe 字母表可以，否则还要再做一次百分号编码——我们的 URL 编解码工具 正是干这个的。

相关工具与文章