Base64 怎么用？编码解码、URL 安全变体与乱码排查
接口里传过来一串看不出意义的字符、图片要内嵌进 CSS、JWT 中间那段要看看里面写了什么 —— 这些场景都会遇到 Base64。它规则简单，但「为什么多了几个等号」「中文怎么解出乱码」这两类问题几乎人人都踩过。
- Base64 是编码不是加密：任何人拿到编码结果都能在一步之内还原原文，绝不能用它保护密码或密钥
- 编码后体积比原文增大约 33%（3 字节变 4 字符），大文件用 Base64 内嵌会明显变大
- 标准 Base64 里的 + 和 / 在 URL 和文件名中是特殊字符，放进 URL 必须改用 URL 安全变体（- 和 _）
- 结尾的 = 只是补齐 4 的倍数，删掉通常仍能解码，但不代表可以随意去掉
- 中文解出乱码几乎都是编码不匹配：编码时用了 UTF-8、解码时按 GBK 或 Latin-1 处理
#先把两个最常见的误解说清
Base64 是编码，不是加密。 它的全部作用是「把任意字节转成 64 个安全可打印字符」，没有任何密钥参与。任何人拿到编码结果都能立刻还原出原文，所以拿 Base64 存密码、藏接口密钥都是无效的防护。
Base64 也不是压缩，它会让数据变大。 编码规则是每 3 个字节拆成 4 个字符，所以体积是原来的 4/3，也就是增大约 33%。一个 1 MB 的图片转成 Base64 大约是 1.33 MB，再加上 DataURL 前缀还要再多几十字节。
这两点解释了后面所有的「怪现象」：为什么内嵌图片会让 CSS 文件暴涨、为什么别人一眼就能看到你「加密」过的参数。
#三步完成编解码
- 打开 Base64 编码解码工具，把内容粘到输入框。
- 选择方向。工具会尝试自动识别（能合法解码就当 Base64 处理），不确定时手动切换更稳妥。
- 中文内容确认字符集选 UTF-8，核对输出结果后复制。
要处理的是图片、PDF 这类二进制文件，直接用 图片转 Base64，它会连同 data:image/png;base64, 前缀一起生成，粘进 HTML 或 CSS 就能用，不需要自己拼前缀。
#三种「Base64」别混用
网上说的 Base64 其实有三个不同的字符表，选错了就会出现「明明是对的字符串却解不出来」：
| 变体 | 字符表差异 | 典型出现位置 |
|---|---|---|
| 标准 Base64 | 使用 + 和 /，结尾用 = 补齐 | MIME 邮件、接口字段、配置文件 |
| URL 安全 Base64 | 把 + / 换成 - _，通常去掉 = | URL 查询参数、文件名、JWT |
| DataURL | 标准 Base64 前面加 data:<MIME>;base64, | HTML / CSS 内嵌图片、字体 |
判断方法：字符串里出现 - 或 _，就是 URL 安全变体，需要换字符表再解码；出现 + 或 /，就一定不是 URL 安全变体。
把标准 Base64 直接拼进 URL 会出错。+ 在查询串里会被解析成空格、/ 会被当成路径分隔符，另一个系统收到的字符串已经不是你发的那一份了。放进 URL 前先转成 URL 安全变体（或者用 URL 编码解码 整体转义一次）。
#中文解出乱码，按这张表排查
乱码不是「工具坏了」，而是编码和解码用的字符集不一致。
| 你看到的现象 | 原因 | 怎么改 |
|---|---|---|
解出一串 测试 这类字符 | 原文是 UTF-8 字节，却按 Latin-1 解码 | 字符集选 UTF-8 重新解码 |
解出 锟斤拷 或连续问号 | 原文是 GBK，却按 UTF-8 解码 | 先把源文件转成 UTF-8 再编码 |
| 编码时就报错「无效字符」 | 用了只支持 Latin-1 的老式接口 | 先做 UTF-8 编码再转 Base64，两步分开 |
| 能解码但少末尾几个字符 | 传输中被截断，或者 + 变成了空格 | 核对长度与校验值，URL 场景改用安全变体 |
一个可以自己验证的事实：Base64 本身不带任何校验信息。传输过程丢了一个字符，解码仍然会「成功」，只是结果末尾几个字节错了 —— 所以关键数据不要只靠肉眼对比 Base64 字符串，要对比原始数据的哈希值（SHA 系列哈希 或 MD5 加密）。
#什么时候该用哪个工具
| 你想做的事 | 用哪个 | 说明 |
|---|---|---|
| 文本 / 二进制转 Base64 再还原 | Base64 编码解码 | 日常最常用，支持大文本 |
| 图片转成 DataURL 内嵌网页 | 图片转 Base64 | 自动带 MIME 前缀，也能反向还原成图 |
| 字符串放进 URL 查询参数 | URL 编码解码 | 遵循 RFC 3986 百分号编码，与 Base64 是两回事 |
中文变成 \u4e2d\u6587 | Unicode 中文互转 | 这是 Unicode 转义，不是 Base64 |
HTML 里的 < > 被转成实体 | HTML 实体转义 | 防 XSS 与显示错乱，别和 Base64 混用 |
判断顺序很简单：只有 64 个字母数字加 +/= 的才可能是 Base64；带 % 的是 URL 编码；&# 或 & 是 HTML 实体；\u 开头是 Unicode 转义。
#两个真实场景的完整做法
#看懂 JWT 中间那一段
JWT 的格式是三段用 . 连接的字符串，中间那段是 URL 安全 Base64 编码的载荷。把中段复制出来（注意先看有没有 - _，有就是 URL 安全变体），解码后就是一段 JSON，能看到 sub、exp、iat 等字段。
JWT 的载荷也是只编码不加密的。任何人都能解出里面的内容，所以绝对不要把手机号、身份证号这类敏感信息直接放进 JWT 载荷 —— 只有签名能防篡改，防不住被读取。
#让接口支持传二进制
有些老接口的传输格式只接受可打印字符，传图片、压缩包时要先转成 Base64 作为字段值，接收方拿到后再解码成字节写入文件。
这里的坑在于大小限制：Base64 的 33% 膨胀意味着 10 MB 的文件会变成 13.3 MB 的字段，很容易超过接口或网关的请求体上限。
#常见问题
#Base64 可以用来保护密码吗？
不能。Base64 是编码不是加密，没有密钥、没有可逆难度，任何人拿到字符串一秒就能还原。要保护密码应该用哈希（服务端加盐存储），要保护传输内容应该用真正的加密算法，例如 AES / DES 加解密。
#结尾的等号（=）可以删掉吗？
可以，但要看对方实现。= 只是把长度补齐到 4 的倍数，很多解码器能自行推算出来。不过并非所有实现都做了这个兼容，标准做法是保留。反过来说，如果解码时提示长度非法，先检查是不是有人在传输过程中删掉了 =。
#为什么 Base64 编码后变大这么多？
因为它的字符表只有 64 个，一个字符只能表示 6 位信息（2^6 = 64），而一个字节是 8 位。所以每 3 字节（24 位）要用 4 个字符（24 位）来表示，体积变成 4/3，也就是增大约 33%。这是用「可打印」换「体积」的代价。
#Base64 能压缩数据吗？
不能，正好相反。如果看到有工具说「Base64 压缩」，那它实际上是先做了 gzip 之类的压缩再 Base64 编码 —— 两步操作，Base64 只是把压缩后的二进制变成安全字符这一步。
#用 Base64 传图片和内嵌图片，哪个更好？
看场景。小图标（几 KB 以内）内嵌进 CSS 能减少请求数，划算；大图内嵌会让 CSS 或 HTML 文件暴涨且无法单独缓存，应该用独立文件。经验阈值是 10 KB 以内考虑内嵌，超过就用外链。