Base64 编码解码器

Base64 之所以存在,是因为很多围绕文本构建的基础设施——邮件、JSON、XML、URL——都无法可靠地承载任意的二进制字节,这些字节可能包含控制字符、空字节,或者会提前终止字符串、直接破坏解析器的字节序列。Base64 把任意二进制数据每三个字节映射成四个字符,这些字符全部取自一个固定的 64 字符集合——字母、数字和两个符号——每一个基于文本的系统都能安全处理,所以编码后的结果可以嵌入 JSON、作为邮件附件发送,或者包含在文档里,而不会被下游的任何环节误解成纯文本以外的东西。

这份安全性带来的开销是固定且无法避免的:每三个输入字节对应四个输出字符,膨胀幅度大约 33%,无论底层数据实际是什么。这是为了保证能在纯文本通道中安全传输而付出的代价,不是某个具体实现的缺陷。

浏览器内置的 `btoa` 函数——很多快速实现的 Base64 工具会直接调用它——一遇到码点高于 U+00FF 的字符就会报错,这个范围几乎包括了所有的表情符号、中文、日文、韩文、西里尔字母、希腊字母和阿拉伯文文本,还有相当一部分用在法语、德语、西班牙语等语言中的重音拉丁字符。这并不是影响罕见输入的冷门边界情况,它影响的是现实世界文本中相当大的一部分,这也是为什么这么多手写的 Base64 工具,在用纯英文输入测试时表现完美,却在用户第一次粘贴带表情符号或非拉丁文姓名的内容时就失败了。

正确的修复方法是先把文本编码成 UTF-8 字节,再对这些字节做 Base64 编码——这正是正确构建的编码器、以及这个工具本身的做法——而不是试图把 Unicode 码点直接塞进一个只为 256 以内字节序列设计的编码方案里。

标准 Base64 的字符集包含 `+` 和 `/`,这两个字符在 URL 里都有各自的含义——`+` 有时会被解释成空格,`/` 是路径分隔符——所以一个标准 Base64 字符串直接粘贴进查询字符串或文件名,可能会在解析这个 URL 的过程中被悄悄破坏或截断。Base64URL 把这两个字符替换成 `-` 和 `_`,这两个符号在 URL 里都没有特殊含义,通常还会去掉末尾的 `=` 填充字符——这些填充符纯粹是用来标示长度的,一旦解码器已经知道该如何预期它们,就不再需要了。

JSON Web Token 采用 Base64URL 正是出于这个原因:JWT 被设计成要在 HTTP 的 Authorization 请求头里传递,有时也会出现在 URL 里,而标准 Base64 里那些有特殊含义的字符会让这一点变得不可靠。

这一点值得明确说清楚,因为这个误解经常出现:Base64 不提供任何机密性。整个过程中不涉及任何密钥,所以任何拿到一段 Base64 字符串的人,只需要一次标准库调用,或者一个像这样的工具,就能瞬间把它解码回原始数据。在存储或传输密码或 API 密钥之前用 Base64 编码它们,不提供任何实质保护——它只是让这个值不至于被随手一瞥就看懂,这和真正的安全性是完全不同的属性。