Base64 是什么？由来、原理与使用场景
从历史背景、3 字节变 4 字符的工作原理，到填充、Base64URL、体积开销和常见使用场景，科学读懂 Base64。
一句话说清 Base64
Base64 是一种“二进制到文本”的编码方法：它把任意字节序列改写成由少量通用字符组成的字符串。它不关心这些字节原本是一张图片、一份 PDF，还是“你好”两个字，只负责给它们套上一件适合在文本系统里旅行的外衣。
这个过程可逆、无损，但它不是加密、哈希或压缩。看到一串 Base64，只能说明数据换了表示方法，不能说明数据变安全了。
Base64 从哪里来
早期网络和电子邮件系统并不总能可靠传输任意 8 位字节；某些网关只认短行的 7 位可打印文本，二进制内容可能被改写。uuencode 等更早的二进制转文本方案也在解决同类问题。现代 Base64 的直接技术脉络之一，是 RFC 1421 为增强隐私邮件（PEM）规定的 64 字符可打印编码。
随后 MIME 把 Base64 命名为邮件正文和附件的一种内容传输编码。2006 年发布的 RFC 4648，则成为标准 Base64 与 URL 安全变体的通用参考。因此它更像是标准协作逐步打磨出的“公共语法”，而不是某位发明家灵光一闪的魔法。
为什么偏偏是 64，以及 3 变 4 的原理
6 个二进制位恰好能表示 0 到 63 共 64 个值。标准 Base64 用 A–Z、a–z、0–9、+ 和 / 对应这些值。编码器每次读取 3 个字节：3 × 8 = 24 位；再把边界重新切成 4 组、每组 6 位，用每组数值去查字符表，最终输出 4 个字符。
以 ASCII/UTF-8 中的“Man”为例，三个字节被切成 19、22、5、46 四个索引，对应 T、W、F、u，所以结果是 TWFu。解码只是把这条路倒着走一遍。
- 输入
Man- 输入字节
01001101 01100001 01101110- 6 位分组
010011 010110 000101 101110- 字母表索引
19 · 22 · 5 · 46- Base64 输出
TWFu
填充符、Unicode 与 Base64URL
最后一组如果只有 1 个输入字节，会产生 2 个有效字符并补上 ==；如果有 2 个字节，则产生 3 个有效字符并补上 =。等号不是“加密内容”，只是告诉解码器：最后一个 24 位分组里有多少位来自真实数据。某些能从上下文确定长度的协议允许省略填充。
Base64 处理的是字节，不是抽象字符。“中文”或 emoji 通常要先按 UTF-8 变成字节，再做 Base64。放进 URL 或文件名时，base64url 会把 +、/ 换成 -、_；它是相关但不同的字母表，不能不看协议就随意混用。
哪些场景真的适合 Base64
经典场景包括 MIME 邮件附件、PEM 证书或密钥块，以及在 HTML/CSS 的 data: URL 中内嵌小图片或字体。JSON、XML 等纯文本格式有时也用它承载小型二进制数据。HTTP Basic 凭据使用 Base64，JWT 的各段使用 URL 安全变体——这两种用法都不等于内容已经保密。
共同点只有一个：外层通道想要文本，内层载荷却是字节。如果图片上传、对象存储或数据库 BLOB 本来就能安全处理二进制，再套一层 Base64 往往只是增加负担。
体积与性能账单
每 3 个完整输入字节会变成 4 个输出字符，精确长度是 4 × ceil(n / 3)。数据足够大时，体积开销趋近 33.3%；数据很小时比例可能更高，换行和 data URL 前缀还会再加一点。
传输层压缩有时能减少实际网络流量，但编码仍会占用内存与 CPU，也让大段内容更难阅读和调试。文件较大时，直接传二进制通常更清爽。
Base64 做不到什么
Base64 不提供机密性或真实性：任何人无需密钥都能解码，也能篡改内容。不要用它“保护”密码、API Token 或个人数据。需要保密时应使用加密和 TLS 等经过认证的传输；需要摘要时用密码学哈希；需要防篡改时用数字签名或消息认证码。
一个既活泼又严格的判断口诀是：用 Base64 穿过文本边界，别指望它守住安全边界。