Base64 编码/解码

Base64 完全指南：编码规则、填充、体积开销与常见误区

Base64 到底做了什么

Base64 把任意二进制数据重新映射到 64 个可打印字符上：A-Z、a-z、0-9，加上 + 和 /。映射是每 3 个字节（24 位）切成 4 组 6 位，每组查表得到一个字符，所以输出长度总是输入长度的 4/3。

它存在的原因不是"加密"，而是为了穿过那些只允许文本的通道。SMTP 邮件、HTTP 头、JSON 字符串、XML 文本节点、URL 查询参数——这些地方一旦出现不可打印字节就会被截断或改写。Base64 把任意字节变成这些通道能安全承载的字符集。

填充符 = 是怎么来的

输入长度不一定是 3 的整数倍，这时最后一块会缺字节，编码器用 = 补齐到 4 个字符：

填充符只表示"原始数据到这里结束"，不含任何信息。所以有些场景会把它去掉以省体积——但去掉后长度不再能被 4 整除，解码器必须自己补回来。Base64 的填充是可选的，但解码器处理必须正确，否则会得到最后一个字节错误的输出。

体积开销：不是"差不多"，是实打实涨 33%

4/3 意味着 体积增加约 33.3%。一张 300 KB 的图片转成 Base64 字符串会变成约 400 KB。再叠加几层（比如把 Base64 塞进 JSON 再塞进另一层 Base64），膨胀会累积。

这带来几个真实的坑：

• Cookie：单个 Cookie 通常限制在 4 KB 左右，Base64 之后只剩约 3 KB 原始空间。
• 内联到 HTML/CSS：data URI 会让页面体积变大，且无法被浏览器单独缓存，每次都要随主文档下载。小图标和字体子集值得内联，几百 KB 的图片不值得。
• 数据库字段：把二进制存成 Base64 文本，存储和索引都会变差，数据库的原生 binary 类型更合适。

URL-safe 变体：为什么要换掉 + 和 /

标准 Base64 的字母表含 + 和 /，这两个字符在 URL 里有特殊含义（空格与路径分隔），直接放进 URL 会被再编码或截断。RFC 4648 第 5 节定义了 URL-safe 变体：

注意：Base64 和 Base64url 的编码结果不同，不能互解。把 JWT 里的 - _ 原样丢给一个只认标准字母表的解码器，会得到乱码。这个工具两种都支持。

Base64 不是加密，也不是哈希

这三个概念经常被混在一起，但性质完全不同：

任何人都能还原 Base64。把密码、API Key、身份证号做 Base64 之后再传输，等同于明文传输。浏览器里 F12 打开控制台，一行 atob() 就还原了。真要保密，用 TLS 传，或者用带认证的加密方案（AES-GCM 这类）。

常见错误清单

• 重复编码：解码失败时第一反应是"再解一次"，结果把本来正确的结果解坏。先确认输入到底是几层。
• 把换行当成数据：MIME Base64 每 76 字符插入换行。解码前如果不把空白字符去掉，会得到"invalid character"错误。
• 字符集错位：YQ== 解出来是字节 0x61，它是 a 也是 ASCII 的 97，但不是数字 97 的文本表示。Base64 还原的是字节，不是字符——非 UTF-8 编码的文本要在解码后再按正确字符集解读。
• 拿它当安全措施：见上一节。
• URL 里直接用标准字母表：/ 会被当成路径分隔符，+ 在查询参数里可能被解成空格。

什么时候该用它，什么时候不该

该用：把二进制塞进文本协议（JWT、邮件、XML、JSON）、把图标内联进 CSS、在日志里安全记录二进制片段、构造 Basic Auth 头。

不该用：传输敏感数据（用 TLS）、存储密码（用 bcrypt/argon2）、大文件在 HTTP 里搬运（用 multipart 或直接二进制传输，省 33% 带宽）、需要压缩的场景（先压缩再 Base64，顺序反了就没效果）。

本工具全程在浏览器本地运行，不发送任何数据。要处理大文件时，可以先在开发者工具的 Network 面板确认没有对外请求。