Base64 编码完全指南

Base64 是互联网上出现频率最高的编码之一：邮件附件、JWT、图片内联、证书、二进制文件传输都能见到它。但关于它的误解也最多——它既不是加密，也不能压缩空间，用错还会引入编码问题。

本文先把原理讲透，再说明标准变体之间的差别，最后集中清理几个反复出现的误区。

一、原理：三字节变四字符

Base64 的核心操作是把输入当成字节流，每 3 个字节（24 位）一组，重新切分为 4 个 6 位单元，每个 6 位单元映射到 64 个可打印字符中的一个（A–Z、a–z、0–9、+、/）。所以「Base64」这个名字指的是字母表大小，而不是某种进制转换。

当输入长度不是 3 的倍数时，需要补零凑满最后一组，并在输出末尾用等号补足长度，这就是常见的 = 或 == 填充。填充只是为了让解码端知道原始长度，本身不携带数据。

3 字节变 4 字符，意味着体积固定放大约 33%（4/3）。再加上 JSON 与 HTML 里的转义，实际开销可能更高。这决定了 Base64 的适用范围：它适合「必须走文本通道」的二进制数据，不适合把本来就大的二进制内容塞进文本里传输。

举例来说，把一个 200 KB 的图片内联成 Base64 写进 CSS，会得到约 267 KB 的文本，而且无法被浏览器单独缓存、无法被 CDN 独立压缩优化。小图标（几 KB）尚可接受，大图通常得不偿失。

标准 Base64：字母表含 + 与 /，用 = 填充，用于邮件（MIME）与一般数据传输；
URL-safe Base64：把 + 换成 -、/ 换成 _。因为 + 在 URL 查询串里会被解析成空格、/ 会被当成路径分隔符，放在 URL 或文件名里必须用它；
无填充变体：省略结尾的等号，解码端按长度推算原始长度。JWT 使用的就是 URL-safe 且无填充的组合，所以你看到的令牌里通常没有等号；
MIME 变体：每 76 个字符插入换行，仅用于邮件正文的展示友好性，解析时需要先把换行去掉。

误区一：Base64 是加密。它没有任何密钥，任何人拿到字符串都能还原出原文，只起到「让内容不被人眼一眼看懂」的效果。需要保密请用真加密；
误区二：Base64 能省空间。恰恰相反，体积必然增大；
误区三：Base64 与字符集无关。它对字节操作，因此「中文先按什么编码取字节」决定了结果。同一段中文，UTF-8 与 GBK 编出来的 Base64 完全不同，解码后也要按对应编码还原；
误区四：加了 Base64 就能安全传参。URL-safe 变体解决的是「字符是否合法」而不是「内容是否可信」，仍须做长度限制与内容校验；
误区五：所有语言的 Base64 都能互通。标准与 URL-safe 混用会直接解码失败，跨系统交互时要明确约定使用哪一种。

浏览器早期的解码函数按单字节字符处理，遇到 UTF-8 的多字节中文就会破坏字节序列，导致解码结果为乱码。正确做法分两步：编码时先把字符串按 UTF-8 取字节数组再编码；解码时先还原字节数组，再按 UTF-8 解回字符串。这两步做错任何一步都会出现「编码时对了、解码时错了」的不对称问题。

如果编码结果只有 ASCII 字符却在解码后得到问号，通常说明某一步用了有损转换——问号意味着原始字节在中途已经被替换掉，无法逆向恢复。

需要即时验证时使用 Base64 编码解码工具，它按 UTF-8 处理中文并支持文件转换。相关主题可继续阅读《URL 编码完全指南》与《字符编码与乱码排查》——三者是同一类问题的不同侧面。