翻译 RFC 4648: Base16、Base32 和 Base64 数据编码

每年都会有人尝试翻译 RFC 系列文档，为了能更好地迭代和组织所翻译的内容，我建立了一个 GitHub 仓库，希望有兴趣的人可以参与进来。翻译是个既耗时又费力的事情，因此我期望的是一种细水长流的模式，即使是几句话的翻译或调整，都可以通过 PR 或邮件的方式提交，慢慢地积累来完成这一项目。

https://github.com/dianbo-rfc/dianbo-rfc

另外，为了方便 RFC 文档的阅读，我试着建立了一个网站。网站的视觉效果应该会好些，使用了等宽字体，并且有中英对照；但毕竟是第一次进行网站开发，且使用的是最低配的服务器，响应时间、页面布局会有很多问题。

https://dianbo-rfc.cn/progress

下面的译文是发布此文章时的版本，未来可能更新的译文需要到 GitHub 或网站上阅读：

Network Working Group                                       S. Josefsson
Request for Comments: 4648                                           SJD
Obsoletes: 3548                                             October 2006
Category: Standards Track


                   Base16、Base32 和 Base64 数据编码

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

摘要

   此文档描述了经常使用的 base 64、base 32 和 base 16 编码方案。此外, 它
   还讨论了以下内容: 在编码数据中使用换行符、在编码数据中使用填充符、在
   编码数据中使用非字母表中的字符、不同编码字母表的使用、及规范编码。


























Josefsson                   Standards Track                     [Page 1]

RFC 4648                    Base-N Encodings                October 2006


目录

   1. 导言 ............................................................3
   2. 此文档中使用的约定 ..............................................3
   3. 各实现间的差异 ..................................................3
      3.1. 编码数据中的换行符 .........................................3
      3.2. 编码数据中的填充符 .........................................4
      3.3. 编码数据中非字母表中字符的解释 .............................4
      3.4. 字母表的选择 ...............................................4
      3.5. 规范编码 (Canonical Encoding) ..............................5
   4. Base 64 编码 ....................................................5
   5. 具有 "对 URL 和文件名安全的字母表" 的 Base 64 编码 ..............7
   6. Base 32 编码 ....................................................8
   7. 具有 "扩展十六进制的字母表" 的 Base 32 编码 ....................10
   8. Base 16 编码 ...................................................10
   9. 图解和示例 .....................................................11
   10. 测试样例 ......................................................12
   11. ISO C99 中的 Base64 编码的实现 ................................14
   12. 安全注意事项 ..................................................14
   13. 自 RFC 3548 以来的修改 ........................................15
   14. 致谢 ..........................................................15
   15. Copying Conditions ............................................15
   16. 参考文献 ......................................................16
      16.1. 前提类参考文献 ...........................................16
      16.2. 信息类参考文献 ...........................................16


























Josefsson                   Standards Track                     [Page 2]

RFC 4648                    Base-N Encodings                October 2006


1.  导言

   由于历史遗留原因, 有些环境只能使用 US-ASCII [1] 表示的数据, 而数据的
   Base 编码 (Base encoding) 经常被用在这种情况中。Base 编码也可以被用于
   不受历史遗留原因所限制的新应用中, 仅仅是因为它使得 "通过文本编辑器来
   操作对象" 成为可能。


   过去, 不同的应用程序具有不同的需求, 因此它们有时会以略微不同的方式来
   实现 Base 编码。如今, 有些协议规范有时会普遍地使用 Base 编码, 尤其是
   "base64", 但是却没有该编码的准确描述或参考文献。多用途互联网邮件扩展
   (MIME, Multipurpose Internet Mail Extensions) 经常被用作是 base64 的
   参考文献, 但是它没有考虑到换行符 (line-wrapping) 或非字母表中字符所造
   成的结果。此规范的目的是建立起通用的字母表及编码时的注意事项。这将有
   望减少其它文档中的歧义性, 从而实现更好的互操作性。




2.  此文档中使用的约定

      在此文档中, 关于关键词【必须】、【禁止】、【必要的】、【应当】、
      【不应】、【推荐的】、【可以】与【可选的】的解释, 见 [2] 中的描
      述。

3.  各实现间的差异

   这里, 我们将讨论过去的各 Base 编码实现之间的差异, 并在适当时, 规定了
   用于将来的具体的推荐行为。


3.1.  编码数据中的换行符

   MIME [4] 经常被用作是 base 64 编码的参考文献。但是, MIME 并没有定义
   "base 64" 本身, 而是定义了被用于 MIME 中的 "base 64 内容传输编码"
   ("base 64 Content-Transfer-Encoding")。其中, MIME 强制性限制了: 使用
   base 64 编码的数据, 其每行长度为 76 个字符。MIME 继承了隐私增强邮件
   (PEM, Privacy Enhanced Mail) [3] 中的编码, 并指出它 "实际上是相同的";
   但是, PEM 使用的每行长度为 64 个字符。MIME 和 PEM 的限制都是由于 SMTP
   中存在的限制所造成的。


   程序实现【禁止】向使用 base 编码的数据中添加换行符, 除非参考了此文档
   的其它规范, 有明确地指示 base 编码器: 在特定数量的字符后添加换行符。







Josefsson                   Standards Track                     [Page 3]

RFC 4648                    Base-N Encodings                October 2006


3.2.  编码数据中的填充符

   在某些情况下, 不需要或不用在 base 编码的数据中使用填充符 ("=")。在一
   般情况下, 当无法假设传输数据的大小时, 需要使用填充符来产生正确的编码
   数据。


   程序实现【必须】在编码数据的末尾包含适当的填充字符, 除非参考了此文档
   的其它规范另有明确规定。


   base64 和 base32 编码中的字母表使用了填充符, 见下面第 4 节和第 6 节的
   描述, 但是 base16 编码中的字母表不需要它, 见第 8 节。


3.3.  编码数据中非字母表中字符的解释

   Base 编码使用了一个特殊的、删减版的字母表来编码二进制数据。由于数据损
   坏或设计原因, base 编码的数据中可能存在非字母表中的字符。非字母表中的
   字符可能被用作 "隐蔽信道" ("covert channel"), 其中非协议的数据可能出
   于恶意目的而被发送。此外, 为了探索实现中的错误 (例如, 可能导致内存溢
   出攻击), 非字母表中的字符也可能会被发送。



   当程序实现在解释 base 编码的数据时, 若发现数据中包含 base 字母表外的
   字符, 程序实现【必须】拒绝编码数据, 除非参考了此文档的其它规范另有明
   确规定。这些规范可能会同 MIME 一样规定: 在解释数据时, 应当简单地忽略
   掉在 base 编码字母表以外的字符 ("在接受的内容上要放宽")。注意, 这意味
   着: 任何相邻的回车/换行 (CRLF) 均构成 "非字母表中字符", 并被忽略掉。
   此外, 这类规范【可以】将出现在编码数据末尾的填充符 "=" 认作是非字母表
   中的字符, 并将其忽略掉。如果在字符串的末尾发现了超出允许数量的填充字
   符 (例如, 一个 base 64 字符串以 "===" 结束), 则超出的填充字符【