Base64 编码与解码

它是干什么用的

Base64 解决一个问题：你手上有任意字节，而通道只肯承载可打印文本。邮件头、JSON 的字符串字段、URL、HTML 属性，以及相当多的老旧基础设施，遇到裸二进制都会翻车。Base64 把每三个字节映射成四个字符，取自一个能穿过上述所有场合的 64 符号字母表。

这就是它的全部用途。它不是压缩——输出还大了三分之一。它不是加密——根本没有密钥。它是一种传输编码，而人们错误地加在它头上的每一种特性，都来自把「我看不懂这个」误认成「这个受到了保护」。

你会在哪里遇到它

• JWT。 三段全都是，用的是去掉填充的 URL 安全字母表。
• HTTP 基本认证。 Authorization: Basic 无非就是把 user:password 做了 Base64 编码——这正是为什么在纯 HTTP 上用 Basic 认证，等同于把密码明文发出去。
• data URI。 data:image/png;base64,... 把一个文件直接嵌进 HTML 或 CSS。
• PEM 证书和密钥。 -----BEGIN----- 和 -----END----- 之间的那些行，就是 Base64 编码的 DER。
• 邮件附件。 SMTP 是文本协议；MIME 用 Base64 来承载一切不是文本的东西。

Unicode 陷阱

浏览器给了你 btoa 和 atob，而它们是个陷阱。两者处理的都是以字符串表示的字节，所以 btoa 遇到任何高于 U+00FF 的字符就会抛错。拿一个 emoji 试试，你会得到 InvalidCharacterError。

解决办法是先转成 UTF-8 字节，本页做的正是这件事：

// Encode any string safely
const bytes = new TextEncoder().encode(text);
const b64 = btoa(String.fromCharCode(...bytes));

// Decode back
const binary = atob(b64);
const out = new TextDecoder().decode(
  Uint8Array.from(binary, c => c.charCodeAt(0))
);

编码那一行有个要注意的地方：把一个很大的数组展开传给 String.fromCharCode，在十万个元素上下就会把调用栈撑爆。数据一大就要分块循环——本页就是这么做的，所以它能处理几兆字节的粘贴而不倒下。

两套字母表

填充才是惹麻烦的那部分。它唯一的职责是把长度补成四的倍数，而解码器总能算出缺了多少——所以 URL 安全变体干脆把它丢掉。可严格的解码器随后就会拒绝这个结果，这就是为什么一段 JWT 粘进别的工具里那么容易失败。这里的解码器会自己把填充补回来。

它在哪些地方被误用

正因为 Base64 一眼看不懂，它被当成秘密来用。这几种具体模式值得点名：

• 拿 Base64 存密码。 这是穿了戏服的明文。密码需要的是慢速单向哈希——bcrypt、scrypt、Argon2。
• 把 JWT 载荷里的 Base64 当成私密的。 载荷对任何持有该令牌的人都是可读的，包括那位用户本人。绝不要往里面放任何你不愿意给他看的东西。
• 用 Base64 把数据偷偷绕过过滤器。 这管用，但只管用一小会儿，而任何值得一用的扫描器都照样会解码它。

涵盖这三者的一条规则是：如果某样东西的安全性取决于读者不去解码它，那它就没有安全性。

相关

JWT 解码器会一步把令牌拆开并解析两个段。如果你要处理的是「把文本放进 URL 时的转义」而不是「编码字节」，那么百分号编码才是你多半想要的那件不同的东西。而如果你解出来的结果原来是 JSON，格式化器会把它排好。