Base64：它不是加密，也不是压缩

Base64 只做一件事：把任意字节映射到 64 个可打印字符。它不隐藏内容，不缩小体积，也不校验完整性。

为什么需要它

有些通道只允许文本：邮件正文、JSON 字段、URL、HTTP 头。二进制直接放进去会被截断或转义出错。Base64 把 8 位字节拆成 6 位一组，每组映射一个字符。

输入 "Man"  →  4D 61 6E  →  010011 010110 000101 101110  →  "TWFu"

3 字节进，4 字符出。体积增加约 33%。

常见误解

误解	事实
它是加密	任何人 base64 解码就能读到原文
它能压缩	它必然变大约三分之一
它是安全的传输方式	只解决字符集，不解决保密与篡改
它能替代哈希	完全可逆，不能做指纹

把敏感信息 base64 后放进 URL 参数或 cookie，等于明文。很多「token 泄露」就是这么发生的。

变体与坑

Base64 有几个不兼容的变体：

变体	差异	用在哪
标准	+ /，末尾 = 补齐	邮件、JSON
URL 安全	- _，通常无补齐	URL、文件名、JWT
无补齐	去掉 =	长度敏感处

把标准变体的字符串塞进 URL 会出错：+ 在查询串里会被解码成空格，/ 也可能被路径解析吃掉。JWT 用 URL 安全变体且去掉补齐，正是为此。

补齐符 = 的规则

输入长度不是 3 的倍数时补 =：

1 字节 → 2 字符 + "=="
2 字节 → 3 字符 + "="
3 字节 → 4 字符

解码时必须能接受有补齐和没补齐两种形式，否则对接会莫名其妙失败。

什么时候不该用

• 想保密 → 加密（AES-GCM 之类），不是 base64
• 想省空间 → 压缩，或直接用二进制字段
• 想校验 → 哈希或带校验和的编码

真正合适的场景只有：数据必须穿过纯文本协议，且接收方能可靠地反向解码。

看到一长串 A-Za-z0-9+/ 结尾带 = 的字符串，先假定它是明文。