Base64 是 Web 开发中最常用的编码方式之一，从邮件附件到图片内嵌，从 JWT Token 到数据 URI，它的身影无处不在。然而，许多开发者对 Base64 的理解仅停留在"编码工具"层面，不清楚其底层原理和使用边界。本文将从零开始，系统讲解 Base64 的核心机制。
为什么需要 Base64？
计算机系统中，数据以二进制形式（0 和 1）存储和传输。然而，许多通信协议（如 SMTP 电子邮件）和文本格式（如 JSON、XML、HTML）最初设计为仅支持 ASCII 文本。当需要在这些文本环境中传输二进制数据（如图片、音频、PDF）时，就需要一种将二进制数据转换为文本字符串的方法。
Base64 正是这样一种编码方案：它将任意二进制数据转换为只包含 64 个安全 ASCII 字符的文本字符串，从而确保数据能在文本通道中安全传输。
编码原理
Base64 的核心思想是将二进制数据按每 3 个字节（24 位）为一组，拆分为 4 个 6 位（6 bits）的单元。每个 6 位单元可以表示 0-63 的数值，对应 Base64 字符表中的一个字符。
Base64 字符表
标准的 Base64 使用以下 64 个字符：
- A-Z：0-25
- a-z：26-51
- 0-9：52-61
- + /：62-63
编码流程示例
以字符串 "Man" 为例：
- 将 "Man" 转换为 ASCII 二进制：
01001101 01100001 01101110 - 按 6 位分组：
010011010110000101101110 - 转换为十进制：19, 22, 5, 46
- 查表得到 Base64：T, W, F, u
- 最终编码结果：
TWFu
填充处理
当原始数据不是 3 字节的整数倍时，需要进行填充。Base64 使用等号 = 作为填充字符：
- 剩余 1 字节：编码为 2 个字符 + 2 个
= - 剩余 2 字节：编码为 3 个字符 + 1 个
=
例如，字符串 "M"（1 字节）编码为 TQ==，字符串 "Ma"（2 字节）编码为 TWE=。
Base64 不是加密
这是最常见的误解。Base64 是一种编码，而非加密。编码是单向可逆的映射过程，没有密钥参与，任何人都可以轻易解码。将敏感数据用 Base64 编码并不能提供任何安全性。
如果需要保护数据机密性，应使用 AES、RSA 等真正的加密算法，并结合 HTTPS/TLS 安全传输。
URL 安全 Base64（Base64URL）
标准 Base64 中的 + 和 / 在 URL 中有特殊含义（空格和路径分隔符），直接在 URL 中传递会导致问题。URL 安全 Base64 做了以下替换：
+→-/→_- 去掉末尾的
=填充
URL 安全 Base64 广泛应用于 JWT Token、OAuth 参数和 URL 短链等场景。
典型应用场景
1. 图片内联（Data URI）
将图片转换为 Base64 编码后，可以直接嵌入 HTML 或 CSS 中，无需额外 HTTP 请求：
<img src="data:image/png;base64,iVBORw0KGgo..." />这种方式适合小图标和背景图，但对于大图片会增加约 33% 的体积，不建议滥用。
2. JWT Token
JSON Web Token 的 Header 和 Payload 使用 Base64URL 编码。将 JWT 的点号分隔部分解码即可获得明文 JSON 数据（注意：签名部分用于验证，不可省略）。
3. 邮件附件（MIME）
SMTP 协议仅支持 7 位 ASCII 文本。邮件中的二进制附件（如 PDF、图片）通过 Base64 编码后嵌入邮件正文传输。
4. API 数据传输
在 RESTful API 中，有时需要将二进制数据（如图片缩略图）以文本形式返回。Base64 编码后的字符串可以直接嵌入 JSON 响应中。
性能与体积考量
Base64 编码后，数据体积会增加约 33%（3 字节变 4 字符）。例如，一个 1MB 的文件编码后约为 1.37MB。在带宽敏感的场景中需要权衡。
此外，Base64 编解码需要额外的 CPU 计算。对于高频操作（如实时图片流），应考虑使用二进制传输代替。
总结
Base64 是连接二进制世界与文本世界的桥梁，理解其原理有助于我们在合适的场景正确使用它。记住核心原则：Base64 是编码不是加密，适合数据传输而非数据保护。对于 Web 开发中的 URL 场景，优先使用 URL 安全 Base64。合理运用，它将成为你工具箱中不可或缺的一员。