Base64 编码详解：原理、体积膨胀 33% 与中文处理
什么是 Base64 编码
Base64 是一种把二进制数据转换成纯文本的编码方式。它用 64 个可打印 ASCII 字符来表示任意字节序列，最早出现在 MIME 邮件协议里，目的是让二进制附件能安全通过只支持文本的通道传输。想直接编码或解码数据，试试我们的 Base64 编解码工具——支持 Unicode 和 URL 安全变体。
这 64 个字符构成一张固定的码表：
| 取值 | 字符范围 | 数量 |
|---|---|---|
| 0-25 | A-Z | 26 |
| 26-51 | a-z | 26 |
| 52-61 | 0-9 | 10 |
| 62 | + | 1 |
| 63 | / | 1 |
额外还有一个 = 字符，只用于末尾的填充（padding），不算在这 64 个里。
Base64 编码原理
Base64 把输入字节每 3 个一组（共 24 bit），拆成 4 个 6-bit 段。每个 6-bit 段对应码表里的一个字符，所以 3 字节最终变成 4 个字符。
以 ASCII 字符串 Man 为例：
原始字节: M(77) a(97) n(110)
二进制: 01001101 01100001 01101110
按 6-bit 分组: 010011 010110 000101 101110
对应十进制: 19 22 5 46
查表结果: T W F u
最终编码结果是 TWFu。
当输入字节数不是 3 的倍数时，需要填充：
- 多 1 个字节（共 1 字节）：补 4 个 0 bit，编码出 2 个字符，再加两个
=, 形如XX== - 多 2 个字节（共 2 字节）：补 2 个 0 bit，编码出 3 个字符，再加一个
=, 形如XXX=
所以你经常会在 Base64 字符串末尾看到一到两个 =，这是正常的填充标记。
中文和 Emoji 的处理
Base64 编码的对象是字节，不是字符。中文、Emoji 这类字符在 UTF-8 下会占多个字节（一个汉字通常 3 字节，一个 Emoji 可能 4 字节）。
正确做法是先把字符串按 UTF-8 编码成字节序列，再对字节做 Base64。很多旧工具会跳过这一步，直接把每个字符当作单字节处理，结果中文全变成 \uXXXX 形式的乱码，或者直接报错。
终端里用 UTF-8 locale 时，下面的命令能正确编码中文：
echo -n "你好" | base64
# 输出: 5ZG95ZG9
解码再转回 UTF-8 也不会丢字：
echo "5ZG95ZG9" | base64 -d
# 输出: 你好
ToolVault 工具匣 的 Base64 工具内部走的是 UTF-8 字节路径，中文、日文、Emoji 都能正确往返。
URL 安全 Base64
标准 Base64 里有 + 和 / 两个字符，放在 URL 或文件名里会被当成特殊符号，导致解析出错。于是有了 URL 安全 Base64（也叫 Base64url）变体：
- 用
-替换+ - 用
_替换/ - 去掉末尾的
=填充
| 标准 Base64 | URL 安全 Base64 |
|---|---|
a+b/c= | a-b_c |
这种变体常见于 JWT（JSON Web Token）的 header 和 payload 部分，也用在 Data URL 和短链接场景。如果你的数据要拼进 URL，一定要用 URL 安全版本。
实际开发中经常踩的边界：HTTP 头里的 = 填充在某些代理被剥掉，或 JSON 里 + 被当成空格转义。遇到「本地能解，线上解不开」时，优先检查两端是否都用了 URL 安全变体，以及 padding 是否被中间层吃掉。
JWT 三段和 PEM 不是「随便一种 Base64」
日常排障里三种方言会撞车：
| 你粘贴的是… | 方言 | 优先工具 |
|---|---|---|
aaaa.bbbb.cccc（两个点） | Base64URL × 3 | JWT 解码器 |
-----BEGIN CERTIFICATE----- | 标准 Base64 + 约 64 列换行 | 证书解码器 |
码表含 - / _、无点号 | Base64URL 整块 | 本页打开 URL 安全 |
JWT 的 header/payload 解出来是 JSON；signature 是不透明字节。PEM 正文用标准码表且依赖换行——「整理掉换行」常让严格解析器失败。码表对照、padding 算法与决策树见 Base64 与 Base64URL：JWT 与 PEM。claims 可见之后的时钟问题走 JWT exp/nbf 时钟漂移；证书链信任走 证书链不完整排查。
大整数与精度陷阱
Base64 解出来的字节如果包含 19 位雪花 ID（snowflake ID），JSON.parse 会按 IEEE754 双精度解析，尾部静默舍入。这不是 Base64 的错，而是「编码层无损、解码层丢精度」。处理大整数 ID 时：
- 在解码后立即用
parseLossless/JSON.parse带 reviver 的写法把大数字转成字符串； - 或者后端直接把 ID 序列化为字符串，避免依赖前端特殊解析。
本站 JSON 格式化工具 已内置无损解析；JWT 解码器也按同一路径展示大整数 claims。
实现注记 / Implementer's note
本站 Base64 工具内部用 TextEncoder/TextDecoder 做 UTF-8 字节与字符的转换，再对字节做 Base64 运算——这是「中文/Emoji 不乱码」的关键。文件拖放编码时，先把 ArrayBuffer 转字节，再分块 base64，避免一次性大字符串内存峰值。URL 安全切换只做码表映射与 padding 处理，不改变编码语义。
如何使用在线工具
用 ToolVault 工具匣 的 Base64 编解码工具 非常简单：
- 打开工具页面
- 在输入框粘贴或输入要处理的文本
- 选择 编码 或 解码
- 结果实时出现在输出区，点复制按钮即可取走
工具全程在浏览器本地运算，数据不会上传到任何服务器，适合处理包含敏感信息的字符串。
FAQ
Base64 是加密吗？
不是。Base64 只是编码，任何人都能解码还原原文，没有任何保密性。它解决的是"怎么让二进制数据安全通过文本通道"的问题，和加密是两回事。需要保密请用 AES 等真正的加密算法。
编码后体积会变化吗？为什么是约 33%？
会变大。Base64 把每 3 字节编成 4 字符，固定开销约 (4−3)/3 ≈ 33.3%。短字符串因填充符 = 可能涨得更多。公式：编码后长度 ≈ 4 × ceil(n/3)。详细演算（Hi / Hello / 1MB）见 为什么 Base64 会让文件变大 33%。也可用 Base64 编解码工具 即时对比长度。
为什么我的中文编码后是乱码？
通常是工具没有按 UTF-8 处理字节。换一个支持 Unicode 的工具（比如上面的 Base64 编解码工具）就能解决。判断标准很简单：把"你好"编码后再解码，能不能原样还原。
Base64 能用来存图片吗？
可以。把图片字节做 Base64 编码后嵌进 HTML 或 CSS 的 Data URL 里，能减少一次 HTTP 请求。但体积会涨 33%，大图片不建议这么做。
为什么 JWT 的一段丢进普通 Base64 会失败？
JWT 用 Base64URL：-/_ 代替 +/，且通常省略 padding。打开 URL 安全开关，或直接用 JWT 解码器。详见 Base64 与 Base64URL。
相关阅读
本文出自 ToolVault 工具匣。更多免费本地工具见 首页。