摘要

  • RFC 3548 处理的是一个不起眼却反复出现的互操作问题：协议只写“base64”，却没有交代字符表、换行、填充或遇到非字母表字符时该怎么办。
  • 它的核心提醒是，MIME 邮件中的传输行为只是一个特定配置，并非所有解码器都应遵守的通用契约。

文本编辑器能够打开 Base64 字符串，于是很容易产生一种直觉：字节变成可打印字符，任何解码器都能原路还原。RFC 3548 记录的历史并没有这么简单。各实现早已积累了细小差异，而协议文件又常把“base64”当作足以说明一切的标签。

分歧不在六位分组的算术，而在外围规则：编码器要不要插入换行？末尾的 = 填充是否必须保留？解码器遇到意外字符是拒绝，还是忽略？64 个位置分别对应哪些符号？沿用相邻格式的答案，可能在那个格式内有效，却会与期待另一套行为的对端发生冲突。

RFC 3548 于 2003 年 7 月发布，类别是 Informational。它的引言指出，一些协议没有准确描述或引用，就直接使用“base64”；MIME 常被拿来充当依据，却没有同时考虑折行和非字母表字符的后果。RFC 3548 因而汇集了常见的 Base16、Base32 和 Base64 方案，并把这些外围选项明确列出。

MIME 的特殊性恰恰使它容易被误当成通用规定。RFC 2045 定义的是邮件内容中的 Base64 Content-Transfer-Encoding。每行最多 76 个字符属于邮件场景；PEM 采用过 64 个字符的行长，也有其传输背景。RFC 3548 对通用引用方给出的规则是：除非所引用的规范明确要求，否则不要添加换行。如果另一端会把它当作数据或直接拒绝，那么换行就不是排版问题。

填充与容错也由配置决定。RFC 3548 要求编码器补足适当的填充，除非引用规范另作说明；解码器则应拒绝字母表之外的字符，除非规范明确选择其他行为。MIME 可以忽略这类字符，包括 CRLF，但那是它自己的例外。把这种宽容带入别的协议，就改变了可接受输入的集合。RFC 提到隐蔽通道与实现错误是应谨慎处理的原因，并未声称某个具体产品因此遭到攻击。

字符表同样需要准确命名。标准 Base64 用 + 和 / 表示数值 62、63。RFC 3548 还列出适合 URL 和文件名的变体，以 和 _ 替代。文件明确说它不能被视为同一种编码，也不应只称作“base64”。路径、文件名和标识符字段面对的约束，与邮件正文并不相同。

2006 年 10 月，RFC 4648 以 Standards Track 文件取代 RFC 3548，保留了按配置说明编码的思路，并新增规范编码规则：Base64 和 Base32 编码器必须把填充位设为零，否则多个字符串可能解出相同字节。这与 MIME 是否折行是两件不同的事。两份 RFC 合起来说明：“解码成功”并未完成协议定义；通信双方仍须约定字符形式、填充、容错，以及在哪一层解释这个值。

Base 编码不是加密，也不能证明消息真实。它只是让八位组能以文本形式通过某些传输。RFC 3548 最持久的历史贡献并不夸张：它要求协议作者不要把熟悉的名字误当作完整规则。

来源