Skip to main content

1. Introduction (简介)

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

在过去，不同的应用有不同的需求，因此有时会以略有不同的方式实现Base编码。如今，协议规范有时会笼统地使用Base编码，特别是"base64"，而没有精确的描述或参考。多用途互联网邮件扩展 (Multipurpose Internet Mail Extensions, MIME) [4] 经常被用作base64的参考，但没有考虑换行或非字母字符的后果。本规范的目的是建立通用的字母表和编码考虑因素。这有望减少其他文档中的歧义，从而实现更好的互操作性。

为什么需要Base编码？​

核心问题​

许多传统系统和协议只能处理文本数据 (US-ASCII)，无法直接传输二进制数据：

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

Base编码的解决方案​

二进制数据 → Base编码 → 文本数据
(不可打印)     (转换)     (可打印、可传输)

示例:
原始数据: [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. 数据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章: 各种Base编码的详细规范
  • 第9-10章: 示例和测试向量
  • 第12章: 安全考虑
Last updated on