Base64 编码详解：它是什么，何时用

Base64 在数据 URI、邮件附件、API 令牌和配置文件中不断出现，却很少被讲清楚。它常被误认为加密，从而导致真正的安全错误。本指南讲清 Base64 究竟做什么、为什么让数据变大、在哪里真正有用，以及值得抛弃的误区。

Base64 是什么

Base64 是一种编码，不是加密也不是压缩。它的工作是仅用 64 个“安全的”文本字符来表示任意二进制数据 —— 一张图片、一个文件、任意字节序列：A–Z、a–z、0–9，加上 + 和 /（用 = 作填充）。这些字符都能安然通过为处理纯文本而设计的系统，这正是 Base64 存在的全部原因。

为什么需要它

许多虽老却仍关键的系统 —— 邮件是典型例子 —— 被设计用来传输 文本，而非原始二进制。直接把二进制发过去可能损坏数据：某些字节值会被当作控制字符、被剥离或被弄乱。Base64 通过把二进制翻译成一种能原样通过的文本形式，再在另一端翻译回来，绕开了这个问题。

从概念上看，这个往返是这样的：

二进制数据  →  Base64 文本  →  二进制数据
(原始)          (可安全发送)     (完全相同的副本)

为什么 Base64 让数据大约变大 33%

没有免费的午餐。Base64 把输入的三个字节（24 位）拆成四个 6 位组，每组映射到 64 个字符之一。三字节进、四字符出 —— 所以编码输出比原始大约大三分之一。这份开销是让二进制能安全以文本传输的代价，也是你不该无缘无故对大文件做 Base64 编码的原因。

你实际会在哪里见到它

数据 URI

你可以把一张小图片作为 Base64 数据 URI 直接嵌入 HTML 或 CSS，省去一次单独的网络请求：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUh..." />

这对很小的图标很方便，但因为 33% 的体积代价，对任何较大的东西都不是好选择。

邮件附件

在底层，邮件附件被 Base64 编码，好让二进制文件完好地穿过基于文本的邮件系统。

令牌与配置

令牌和凭据常被 Base64 编码，以便安全地放进头部、URL 或文本配置文件里。例如，JWT（JSON Web Token） 就是用点连接的三段 Base64 —— 这正是 JWT 解码器能立刻读出其内容的原因。

安全误区

最重要的一点：Base64 不是加密，不提供任何安全性。 没有密钥、没有秘密 —— 任何人都能在一瞬间把 Base64 解回原始数据。如果你看到某个密码或 API 密钥仅靠 Base64 来“保护”，就把它当作明文，因为实际上就是。

Base64 回答的是“我如何让这份数据安全地通过文本通道？”，而不是“我如何让这份数据保密？”。要保密你需要真正的加密。把两者结合很常见：先加密，再对加密结果做 Base64 编码，以便作为文本传输。

Base64 与 URL

标准 Base64 使用 + 和 /，它们在 URL 中有特殊含义，作为查询参数传递时可能被破坏。一个叫 Base64URL 的变体把它们换成 - 和 _ 并去掉填充，让输出可以直接放进 URL。如果你还在与 URL 里的空格或与号之类的字符较劲，那是 URL 编码 的活儿 —— 针对不同问题的不同工具。

自己动手编码和解码

你很少需要手工做 Base64，但常常需要查看或生成它 —— 读一个数据 URI、看看令牌里有什么、创建一张嵌入图片。我们的 Base64 编码器和解码器 能双向即时转换文本，全程在你的浏览器中完成，因此即便是敏感值也绝不离开你的设备。粘贴 Base64 看原文，或粘贴文本得到编码形式。

一句话总结

Base64 把二进制变成安全文本再变回来，代价是体积大约多 33%，且毫无保密性。用它来 传输 数据，绝不要用它来 保护 数据。