Base64 解释：编码、填充、Data URL 与常见误区

Base64 把输入字节按 24 位分组，再用 64 个字符组成的字母表表示。结果比原数据更长，但能安全通过只接受普通文本的协议、文件格式或 API 字段。它不是为了人类阅读，而是为了传输。

很多 Base64 字符串末尾的等号是填充。当输入长度不能被 3 字节整除时，就需要它。不同系统对填充的要求不同：有的保留、有的省略、有的自动推断。调试时应先确认字母表和填充规则。

标准 Base64 使用加号和斜杠，这些字符在 URL 中不方便。Base64URL 通常把它们替换为连字符和下划线，并经常省略填充。JWT 的 header 和 payload 就使用 Base64URL。标准解码器不一定接受 URL 安全变体。

Base64 编码的是字节，不是抽象字符。如果原文是 UTF-8，解码得到的是 UTF-8 字节，还要按 UTF-8 解释。若另一系统假设了其他字符编码，非 ASCII 文本仍会损坏，即使 Base64 步骤本身正确。

Data URL 把内容直接嵌进类似 URL 的字符串，常用 Base64 表示图片或文件。它适合小图标、演示或自包含示例，不适合大文件，因为会增加体积、削弱缓存并让 HTML、CSS 或 JSON 臃肿。

任何人都能不需要密钥地解码 Base64。它只是让内容不那么直观。密码、token、私钥、证书和客户数据编码后仍然敏感。日志里尤其容易出错：看似无害的字符串，解码后可能就是凭据。

先识别变体：标准、URL 安全、有填充还是无填充。然后解码无害样例，判断输出是文本、JSON、图片、证书还是任意字节。文本要确认字符编码，JSON 要格式化，二进制应看文件签名或十六进制。