上个月联调接口，后端返回一段以 = 结尾的长字符串，前端同事说“这是 Base64，解码看看”。我第一次见这玩意儿，还以为是加密，问了句“怎么解密”，被笑了半天。后来才发现 Base64 是程序员最常用的老朋友：邮件附件、图片内嵌、接口传参，到处都有它。这篇把它彻底讲明白。
Base64 是什么？先记住一句话
Base64 是把二进制数据用 64 个可打印字符表示的编码方式。它不改变数据的含义，只是换一种“写法”——所以它不是加密：加密需要密钥，Base64 谁都能解开。
为什么偏偏是 64 个字符
2 的 6 次方等于 64，所以 6 位二进制正好对应 64 种组合。Base64 用大小写字母（52 个）、数字（10 个）、加号和斜杠凑齐 64 个字符，再把二进制数据每 6 位一组映射成可见字符，末尾用 = 做填充。
一张图看懂编码过程
为什么末尾总有 =
Base64 每 4 个字符表示 3 个字节。如果原始数据长度不是 3 的倍数，最后就用 = 补齐到 4 的倍数。所以看到结尾一个或两个 = 是正常现象，说明原始数据长度刚好不是 3 的倍数，不是出错了。
Base64 都用在哪些地方
- 图片内嵌：把图片转成 data URI 直接写进 HTML 或 CSS，减少请求数——用图片转Base64可以一键生成；
- 邮件附件：早期邮件协议只能传输文本，附件会先编码成 Base64 再发送；
- 接口传参：二进制数据不好直接放 URL 或 JSON，先编码成安全字符串再传；
- 配置存储：把二进制内容以文本形式存进数据库或配置文件。
URL 场景要用 URL Safe 变体
标准 Base64 的字符表里有 + 和 /，这两个字符在 URL 里会被特殊处理（+ 可能被当成空格，/ 会干扰路径），所以 URL 场景一般用 URL Safe 变体：把 + 换成 -、/ 换成 _，结尾的 = 也常常去掉。本站的Base64编解码工具提供了 URL 安全模式选项，遇到这类需求直接勾选即可。
Base64 和十六进制（Hex）是一回事吗
不是一回事。Hex 把每个字节拆成两个十六进制字符（0-9、a-f），体积膨胀一倍；Base64 每 3 个字节用 4 个字符，膨胀约 1/3，更紧凑。Hex 适合人读、方便对齐查看，Base64 适合机器间传输，各有用处。
直接动手编解码
打开Base64编解码工具，输入任意文本（中文也支持）立刻看到编码结果；把一串 Base64 粘进去就能解码。想试试图片版，用图片转Base64，拖一张图进去就出 data URI。
常见问题（FAQ）
Base64 是加密吗？
不是。加密需要密钥且通常不可逆，Base64 只是编码格式，任何懂原理的人都能一眼解码。不要把密码、密钥等敏感信息用 Base64 传输，那等于明文。
为什么 Base64 之后体积变大了？
每 3 个字节会变成 4 个字符（每个字符 1 字节），体积大约膨胀 33%。这是 Base64 的代价，换来的是“可以在纯文本环境安全传输”。
中文编码出来是乱码吗？
中文是多字节字符（UTF-8 下一个汉字占 3 字节），直接编码没有问题，解码时记得用 UTF-8 解码。本站工具已处理这个细节，中文编解码不会乱。
Base64 不难，难的是第一次建立起“编码不是加密”的直觉。花两分钟用工具玩一次，下次再看到 = 结尾的字符串，你就知道它是什么了。
