Base64 编码完全指南：体积、乱码与常见误区

开发者工具箱 · 使用教程

接口里那串 aGVsbG8= 是什么？为什么图片变成 Base64 后大了一圈？为什么中文解码出来是乱码？这篇文章把 Base64 讲清楚，顺便纠正一个最常见的误解——Base64 不是加密。

一、Base64 是什么

Base64 是一种用 64 个可打印字符来表示二进制数据的编码方式。这 64 个字符是：

A-Z (26)  a-z (26)  0-9 (10)  +  /   →  合计 64 个
末尾的 = 是填充符

它的核心动作只有一个：把每 3 个字节（24 位）切成 4 组 6 位，每组对应上面表里的一个字符。所以 3 字节的数据编码后变成 4 个字符。

因为很多协议是“纯文本协议”，只保证能安全传输可打印字符。原始二进制字节里可能有换行符、控制字符、null 字节，这些东西在传输途中会被误当作协议指令，或者干脆被截断。

典型场景：

这是纯数学的结果：3 个字节（24 位）的信息，需要用 4 个字符（每个 6 位）来装。

原始数据     3 字节
Base64 后    4 字节
增加比例     4/3 - 1 = 33.3%

所以一个 300 KB 的图片转成 Base64 会变成 400 KB 左右。如果后面还要塞进 JSON 字符串（多一层转义），可能再涨一点。

这就是为什么不要用 Base64 传输大文件。多出来的 33% 是实打实的带宽成本和内存占用。图片内联只适合小图标（几 KB 级别）。

根源在于：Base64 编码的是字节，不是字符。

而“字符”变成“字节”这一步，依赖字符集。同一个汉字在不同字符集下字节完全不同：

"中"
  UTF-8  →  E4 B8 AD        →  Base64: 5Lit
  GBK    →  D6 D0           →  Base64: 1tA=

所以编码和解码两边必须约定同一套字符集。现代系统的正确做法是：

乱码的典型原因就是一边用 UTF-8、另一边用 GBK，或者某一步用了系统默认编码（Windows 上常是 GBK）。

标准 Base64 用了 + 和 / 两个字符，而这两个在 URL 里有特殊含义（+ 会被解析成空格，/ 是路径分隔符）。所以有了 URL 安全版 Base64URL：

JWT 用的就是 Base64URL。如果你把 JWT 丢进 URL 参数后解码失败，先检查是不是把 -、_ 换回了 +、/。

这是最需要纠正的误解。Base64 只是编码，没有密钥，任何人都能解开。

把密码、token 做 Base64 然后放前端，等于把明文贴在页面上——因为 btoa() 是浏览器自带函数，一秒钟就能还原。

需要保密请用真正的加密（AES、RSA、SM 系列），需要防篡改用签名（HMAC、RSA 签名）。Base64 解决的是“怎么传”，不是“怎么藏”。

纯浏览器本地处理，输入的内容不会离开你的电脑。

Base64 能压缩数据吗？: 不能，反而会变大 33%。它的目标是“让二进制安全穿过文本通道”，不是节省空间。真要压缩得用 gzip、zstd 这类算法，而且通常先压缩再 Base64。
为什么有时候 Base64 末尾有一两个等号？: 填充符。Base64 要求输入长度是 3 的倍数，不足时用 = 补齐。1 个等号表示补了 1 字节，2 个等号表示补了 2 字节。解码时收到等号是正常现象，不是数据损坏。
解码报“非法字符”或“长度错误”怎么办？: 先检查三件事：有没有复制到换行和空格（很多系统分行输出，要先去空白）；长度是否是 4 的倍数；+ / 是否被换成了 - _（或者反过来）。这三点覆盖九成失败情况。
Base64 和 MD5、SHA 有什么区别？: 性质完全不同。Base64 是可逆的编码，能还原原数据；MD5/SHA 是单向哈希，无法还原，用途是校验完整性。看到一串字符先分清是哪一类，用法差别很大。
图片转 Base64 放网页里好不好？: 小图标（几 KB）可以，能省掉一次 HTTP 请求。大图不要——体积涨 33%，还不能被浏览器缓存单独复用，整体反而更慢。
为什么解码出来是一堆乱码符号？: 大概率是解出来的是原始二进制（比如一张图片的字节），而工具按文本显示。这时应该把结果保存成文件，或者确认你解码的对象本来就是文本。