跳到主要内容

1. 引言

数据的基数编码在许多场景下用于在被限制为 US-ASCII [1] 数据的环境中存储或传输数据，这种限制或许出于历史原因。基数编码也可用于没有历史限制的新应用，仅仅是因为它使得用文本编辑器操作对象成为可能。

过去，不同应用有不同的需求，因此有时会以略微不同的方式实现基数编码。如今，协议规范有时会泛泛地使用基数编码，尤其是 "base64"，却没有精确的描述或引用。多用途互联网邮件扩展（MIME）[4] 常被作为 base64 的参考，却未考虑其对换行或字母表外字符的影响。本规范的目的是确立通用的字母表与编码考量。这将有望减少其他文档中的歧义，从而带来更好的互操作性。

为什么需要基数编码​

核心问题​

许多历史系统与原生协议只能处理文本数据（US-ASCII），无法直接传输二进制数据：

问题场景：
❌ 电子邮件系统（SMTP）——仅支持 7 位 ASCII
❌ URL 参数——某些字符具有特殊含义
❌ JSON/XML——无法直接嵌入二进制数据
❌ 文本编辑器——无法编辑二进制文件

基数编码解决方案​

二进制数据 → 基数编码 → 文本数据
（不可打印）   （转换）     （可打印、可传输）

示例：
原始数据：[0x48, 0x65, 0x6C, 0x6C, 0x6F]  （二进制）
Base64：   "SGVsbG8="                      （文本）

历史背景与互操作性问题​

实现差异引发的问题​

在 Base64 标准化之前，不同实现之间存在差异：

实现行长度限制填充规则字母表
MIME76 字符必需标准
PEM64 字符必需标准
某些 URL 编码无限制可选URL 安全

这些差异导致了：

  • ❌ 跨系统数据交换失败
  • ❌ 解码错误
  • ❌ 安全漏洞

RFC 4648 的价值​

本规范通过以下方式解决这些问题：

  1. 统一字母表——明确定义 Base64、Base32、Base16 的标准字母表
  2. 清晰规则——规定如何处理换行、填充、非法字符
  3. 提供变体——定义 URL 安全的 Base64 变体
  4. 互操作性——确保不同实现之间的兼容性

适用场景​

Base64 的典型应用​

1. 电子邮件附件（MIME）
   Content-Transfer-Encoding: base64
   
2. Data URI
   data:image/png;base64,iVBORw0KGgo...
   
3. JWT 令牌
   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
   
4. HTTP 基本认证
   Authorization: Basic dXNlcjpwYXNz
   
5. 在 XML/JSON 中嵌入二进制数据
   {"avatar": "SGVsbG8gV29ybGQ="}

为什么不直接传输二进制？​

原因：
1. 协议限制——SMTP、HTTP 头部仅支持 ASCII
2. 文本安全性——避免控制字符引发的问题
3. 可编辑性——可用文本编辑器查看与修改
4. 兼容性——跨平台、跨系统传输更可靠

本规范的目标​

RFC 4648 旨在：

✅ 消除歧义——提供清晰、无歧义的编码定义
✅ 提升互操作性——确保不同实现之间的兼容
✅ 提供选择——为不同场景提供合适的编码变体
✅ 安全考量——明确规定与安全相关的实现要求

后续步骤​

后续章节将详细讲述：

  • 第 2 节：RFC 2119 关键词的使用约定
  • 第 3 节：实现差异与推荐行为
  • 第 4–8 节：各类基数编码的详细规范
  • 第 9–10 节：示例与测试向量
  • 第 12 节：安全注意事项