案例库 · 工程与运营 · 技术决策 · 1987-2006
Base64 将每 6 位打包成一个可打印字符，让任何二进制数据都能通过纯文本通道
Base64 将每 6 位映射为一个安全的可打印字符，从而使图像和文件能够嵌入 7 位文本中传输。
IETF
那一手
电子邮件、URL、XML 和 JSON 都是文本传输通道：它们可以携带字节，但只能可靠地携带狭窄的安全子集。直接发送原始图像会导致数据损坏。笨拙的替代方案是将文件作为附件发送，这需要特殊处理，并且在消息正文中会出问题。
Base64 通过将二进制转换为文本来绕过此问题。它将每 3 个字节一组，拆分为 4 个 6 位块，然后从 64 个字符的字母表中为每个块打印一个字符，当输入不能平均分割时，用等号填充。输出中的每个字节都是可打印的 ASCII 字符。
由于编码规则固定，它成为 MIME 电子邮件附件、HTTP 基本认证、数据 URI 和 JWT 的默认方案。它没有解决传输限制；而是巧妙地绕过了这些限制，以至于不需要其他方案。
为什么管用
- 选择 64 个字符的字母表是为了确保在任何文本通道中都是安全的，这样任何字符都不会被邮件系统或解析器破坏。
- 3 到 4 的比例使输出可预测且可逆，使用一个小的固定表即可实现，因此各种实现可以完全一致。
- 填充使输出自描述，解码器可以知道后面有多少真实字节。
- 它首先解决了电子邮件附件的问题，从而在后来所有需要在文本中携带字节的格式中得到了应用。
值了多少将二进制数据编码为可打印的 ASCII 字符，每 6 位对应一个字符。聪明
可以搬走什么
当通道无法携带任意数据时，将数据转换为通道自身的安全字母表；针对通道约束优化的格式会被广泛应用。
后来呢
Base64 在 1990 年代初随 MIME 标准化，后来在 2006 年被纳入 RFC 4648，同时增加了 URL 安全变体。现在它已内置于 JSON、XML、HTTP 认证、JWT 和数据 URI 中。其缺点是增加 33% 的体积，新的二进制协议宁愿容忍这一点，也不愿替换它。
资料来源
发现哪里写错了？告诉我们。