Base64 编码详解：何时有用，何时有害 | Toolars

Base64 是把任意字节写成纯文本的标准方式。64 个可打印字符——A–Z、a–z、0–9，外加 + 和 /——代表六位一组的数据，因此每三个输入字节恰好变成四个输出字符。这个映射没有任何秘密，也绝不会比原始数据更小。

公开字母表字母表是固定且公开的；任何人用任何语言的一行代码都能解码 Base64 字符串，这正是它可互操作的原因。
没有保密性它不是加密：没有密钥、没有保密性、没有访问控制——任何人把消息粘进解码器就能读出内容。
绝不会更小它也不是压缩：输出总是比输入大，绝不会更小，因为六位数据要装进八位字符里传输。

因为三字节变成四字符，Base64 输出恒为输入的三分之四——未计填充约大 33%。一张 900 KB 的图片会变成约 1.2 MB 文本，这份膨胀会跟着数据走到每一处。

线路上传输成本：嵌入 HTML 或 CSS 的 Data URL 以文本形式被下载、解析与缓存，每次页面加载都要多付这三分之一。
内存中内存与存储成本：携带 Base64 字段的 JSON 或 XML 负载以字符串形式驻留，有些管线还会把值存两份——一份编码、一份解码。
邮箱里邮件会放大它：为传输而 Base64 编码的附件在线路上膨胀三分之一，所以 25 MB 的附件上限实际只意味着约 18 MB 的文件。

Base64 存在的理由是许多信道只能传文本。邮件标准写于七位 ASCII 时代，JSON 装不下原始字节，URL 遇到二进制数据就会断裂——于是一种字节安全的文本表示就成了桥梁。

Data URLData URL 把小素材内联：data:image/png;base64,… 让图标或微小占位图随 CSS 或 HTML 一起传输，省去一次额外请求。
邮件与 MIME邮件附件依赖 Base64，因为 SMTP 是为文本设计的；MIME 把二进制部分编码，使其在每一跳中继中完好无损。
令牌与证书令牌与证书——JWT 分段、PEM 文件、HTTP Basic 凭据——使用 Base64 或其 URL 安全变体，让二进制结构适配文本协议。

编码后的样子看似难以辨认，因此常被误当作保护。它不是：解码轻而易举、瞬间完成、不需要任何凭据。把编码后的秘密当作安全，是已提交代码与日志中凭据泄露最常见的原因之一。

任何人都能读配置文件里 Base64 编码的密码，只是多了几步的明文密码；任何有读取权限的人都已经拥有了秘密。
仍然是凭据出现在 URL、截图与错误报告中的编码令牌仍然是凭据——要像对待原始值一样把它们抹掉。
用真正的保护真正的保护意味着用密钥加密、用哈希做校验，或者干脆不暴露这个值；编码永远无法替代其中任何一项。

大多数 Base64 故障都是方言问题。经典字母表用 + 和 / 并以 = 填充；URL 安全变体换成 - 和 _ 且常常省略填充；MIME 每 76 个字符折行。期望一种方言的解码器会拒绝另一种，而错误信息很少说明它想要哪一种。

字母表不匹配字母表不匹配：含 - 或 _ 的 URL 安全字符串会被严格的经典解码器拒绝，反之经典 + 和 / 也会破坏 URL 安全处理。
填充缺少填充：带填充的方言要求长度是四的倍数，被剥掉的 = 尾巴会让严格解析器失败，即使数据完好无损。
杂散字符杂散字符：MIME 折行、开头的 data:…;base64, 前缀，或从邮件客户端粘来的空格，都会被判为非法输入。

Base64 字符串通常是某个敏感物的片段：配置文件、令牌、正要发往客户邮件的图片。在随手找到的网站上解码，等于把这些材料粘进别人的日志。