每年都会有人尝试翻译 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 字符串以 "===" 完结), 则超出的填充字符【能够】被疏忽。3.4. 字母表的抉择
不同的利用对字母表中的字符有不同的需要。以下是一些需要, 用于确定该当
应用哪个字母表:
Josefsson Standards Track [Page 4]
RFC 4648 Base-N Encodings October 2006
o 由人类解决。字符 "0" 和 "O" 很容易混同, 字符 "1"、"l" 和 "I" 也很
容易混同。在上面的 base32 字母表中, 没有字符 "0" (零) 和 "1" (一),
依据状况, 一个解码器可能将 0 解释为 O, 并将 1 解释为 I 或 L。( 但
是, 在默认状况下, 不应如此; 见后面的章节。)
o 编码后的数据, 其构造要满足其它要求。对于 base 16 和 base 32 编码,
这确定了应用大写或小写的字母表。对于 base 64 编码, 非字母表中的字
符 (特地是 "/") 可能会在文件名和 URL 中呈现问题。o 用作标识符。一些字符, 特地是 base 64 字母表中的 "+" 和 "/", 会被传
统的文本搜寻 / 索引工具视为分词符。没有可能满足所有的需要、被广泛承受的字母表。一个对于高度专业化变体的
示例, 见 IMAP [8]。在此文档中, 咱们记录并命名了一些以后正在被应用的字
母表。3.5. 标准编码 (Canonical Encoding)
base 64 和 base 32 编码中的填充步骤, 如果没有被正确地实现, 将会导致编
码后的数据呈现不易觉察的扭转。例如, 对于 base 64 编码, 如果它的输出仅
为一个八位字节, 则应用到了第一个符号中所有 6 个比特位, 然而只应用了下
一个符号中前 2 个比特位。遵循协定的编码器【必须】将裁减的比特地位零,
这将在下文形容填充符时提高一阐明。如果不保留这一个性, 则不存在对 base
编码的标准示意, 且会呈现: 多个 base 编码字符串被解码为雷同的二进制数
据。如果保留这一个性, 则可能保障标准编码。在一些环境中, 对于数据中的变动十分严格, 因而: 如果未将填充比特地位为
零, 则编码器【能够】抉择回绝编码数据。与此相关的标准可能规定一个非凡
的行为。4. Base 64 编码
下文中对 base 64 编码的形容来自于 [3], [4], [5] 与 [6]。能够应用
"base64" 来代称此编码方案。Base 64 编码被设计成: 在容许应用辨别大小写的示意模式时, 它可能示意任
意的八字节序列, 然而并不需要被人类可读。Josefsson Standards Track [Page 5]
RFC 4648 Base-N Encodings October 2006
编码应用了一个蕴含 US-ASCII 中的 65 个字符的字符子集, 其中的每个可打
印字符可能示意 6 比特的数据。( 额定的第 65 个字符是 "=", 其被用于示意
须要非凡的解决 )。编码的过程是将 "24 位组" 的多组输出比特, 示意为多个 " 由 4 个编码字符
形成 "的多个字符串。依照从左至右的解决程序, 每 3 个"8 位组 " 的原始输
入形成一个 "24 位组" 的编码输出。这些 "24 位组" 的输出将被视作由 4 个
"6 位组" 的数据形成, 每一组都会被编码为 base 64 字母表中的单个字符。每个 6 位组的数据被用作 "64 个可打印字符的数组" 的索引。被索引所援用
的字符置于输入字符串中。表 1: Base 64 编码的字母表
值 编码 值 编码 值 编码 值 编码
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (填充符) =
15 P 32 g 49 x
16 Q 33 h 50 y
如果在数据的开端, 可用于编码的数据少于 24 比特, 则需进行非凡的解决。使得在对数据的开端编码时, 总是可能以残缺的 "24 位组" 的编码方式完结。当输出比特组中的位数少于 24 比特时, 会在输出的右侧增加值为 0 的比特,
以形成一个残缺的 "6 位组"。接着应用字符 "=" 对数据的开端进行填充。因
为, 所有 base 64 编码的输出都是整数个八位字节, 所以只会呈现一下状况:
(1) 如果编码输出的最初局部的比特位数是 24 的整数倍; 则编码输入的最初
局部的字符个数是 4 的整数倍, 且没有用字符 "=" 填充。Josefsson Standards Track [Page 6]
RFC 4648 Base-N Encodings October 2006
(2) 如果编码输出的最初局部的比特位数刚好是 8 位; 则编码输入的最初局部
将会是: 2 个编码字符, 再后跟 2 个 "=" 填充符。(3) 如果编码输出的最初局部的比特位数刚好是 16 位; 则编码输入的最初部
分将会是: 3 个编码字符, 再后跟 1 个 "=" 填充符。5. 具备 "对 URL 和文件名平安的字母表" 的 Base 64 编码
具备 "对 URL 和文件名平安的字母表" 的 Base 64 编码, 曾经被用于 [12]。有些替换用的字母表, 倡议应用 "~" 作为第 63 个字符。因为, 在一些文件系
统的环境中, 字符 "~" 具备非凡的含意, 所以倡议还是应用本节所形容的编码
计划。残余的未被 URI 所保留的字符是 ".", 然而在一些文件系统的环境中,
不容许在一个文件名中应用多个 ".", 因而使得字符 "." 也没有吸引力。当在 URI [9] 中应用时, 填充字符 "=" 通常是被百分号编码的 (percent-
encoded), 然而如果隐士地晓得数据的长度, 则能够通过跳过填充符来防止这
一状况; 见第 3.2 节。这里给出的编码方案可用 "base64url" 来代称。不应认为此编码与 "base64"
编码雷同, 且不应仅用 "base64" 来指代此编码。除非另有阐明, 否则
"base64" 指代的是后面章节中的 base 64 编码。此编码方案, 除了在第 62 个和第 63 个字符上有所区别, 从技术上而言与之
前的雷同, 如表 2 所示。Josefsson Standards Track [Page 7]
RFC 4648 Base-N Encodings October 2006
表 2: "对 URL 和文件名平安的" Base 64 编码的字母表
值 编码 值 编码 值 编码 值 编码
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 - (减号)
12 M 29 d 46 u 63 _ (下划线)
13 N 30 e 47 v
14 O 31 f 48 w
15 P 32 g 49 x
16 Q 33 h 50 y (填充符) =
6. Base 32 编码
下文中对 base 32 编码的形容来自于 (更正后的) [11]。能够应用 "base32"
来代称此编码方案。Base 32 编码被设计成: 在须要应用不辨别大小写的示意模式时, 它可能示意
任意的八字节序列, 然而并不需要被人类可读。编码应用了一个蕴含 US-ASCII 中的 33 个字符的字符子集, 其中的每个可打
印字符可能示意 5 比特的数据。( 额定的第 33 个字符是 "=", 其被用于示意
须要非凡的解决 )。编码的过程是将 "40 位组" 的多组输出比特, 示意为多个 " 由 8 个编码字符
形成 "的多个字符串。依照从左至右的解决程序, 每 5 个"8 位组 " 的原始输
入形成一个 "40 位组" 的编码输出。这些 "40 位组" 的输出将被视作由 8 个
"5 位组" 的数据形成, 每一组都会被编码为 base 32 字母表中的单个字符。当一个比特流通过 base 32 编码方式进行编码时, 必须假设该比特流的位序满
足最高位优先。因而, 在比特流的第一个 8 位字节中, 第一个比特是最高位,
第八个比特是最低位, 依此类推。Josefsson Standards Track [Page 8]
RFC 4648 Base-N Encodings October 2006
每个 5 位组的数据被用作 "32 个可打印字符的数组" 的索引。被索引所援用
的字符置于输入字符串中。这些字符是从 US-ASCII 的数字和大写字母中选出,
如下表 3 所示:
表 3: Base 32 编码的字母表
值 编码 值 编码 值 编码 值 编码
0 A 9 J 18 S 27 3
1 B 10 K 19 T 28 4
2 C 11 L 20 U 29 5
3 D 12 M 21 V 30 6
4 E 13 N 22 W 31 7
5 F 14 O 23 X
6 G 15 P 24 Y (填充符) =
7 H 16 Q 25 Z
8 I 17 R 26 2
如果在数据的开端, 可用于编码的数据少于 40 比特, 则需进行非凡的解决。使得在对数据的开端编码时, 总是可能以残缺的 "40 位组" 的编码方式完结。当输出比特组中的位数少于 40 比特时, 会在输出的右侧增加值为 0 的比特,
以形成一个残缺的 "5 位组"。接着应用字符 "=" 对数据的开端进行填充。因
为, 所有 base 32 编码的输出都是整数个八位字节, 所以只会呈现一下状况:
(1) 如果编码输出的最初局部的比特位数是 40 的整数倍; 则编码输入的最初
局部的字符个数是 8 的整数倍, 且没有用字符 "=" 填充。(2) 如果编码输出的最初局部的比特位数刚好是 8 位; 则编码输入的最初局部
将会是: 2 个编码字符, 再后跟 6 个 "=" 填充符。(3) 如果编码输出的最初局部的比特位数刚好是 16 位; 则编码输入的最初部
分将会是: 4 个编码字符, 再后跟 4 个 "=" 填充符。(4) 如果编码输出的最初局部的比特位数刚好是 24 位; 则编码输入的最初部
分将会是: 5 个编码字符, 再后跟 3 个 "=" 填充符。(5) 如果编码输出的最初局部的比特位数刚好是 32 位; 则编码输入的最初部
分将会是: 7 个编码字符, 再后跟 1 个 "=" 填充符。Josefsson Standards Track [Page 9]
RFC 4648 Base-N Encodings October 2006
7. 具备 "扩大十六进制的字母表" 的 Base 32 编码
下文中对 base 32 编码的形容来自于 [7]。能够应用 "base32hex" 来代称此
编码方案。不应认为此编码与 "base32" 编码雷同, 且不应仅用 "base32" 来
指代此编码。此编码有被用于 NextSECure3 (NSEC3) [10]。此字母表具备一个 base64 和 base32 的字母表所短少的个性, 即: 当对数据
通过按位比拟的形式进行排序时, 该字母表能保障编码后的数据具备同原始数
据雷同的排序程序。此编码方案, 除了在字母表上有所区别, 其它方面与之前的雷同。新的字母表
如表 4 所示。表 4: "扩大十六进制的" Base 32 编码的字母表
值 编码 值 编码 值 编码 值 编码
0 0 9 9 18 I 27 R
1 1 10 A 19 J 28 S
2 2 11 B 20 K 29 T
3 3 12 C 21 L 30 U
4 4 13 D 22 M 31 V
5 5 14 E 23 N
6 6 15 F 24 O (填充符) =
7 7 16 G 25 P
8 8 17 H 26 Q
8. Base 16 编码
下文中的形容是原始的, 然而与先前的形容相似。实质上, Base 16 编码是标
准的不辨别大小写的十六进制编码, 且能够应用 "base16" 或 "hex" 来代称此
编码方案。编码应用了一个蕴含 US-ASCII 中的 16 个字符的字符子集, 其中的每个可打
印字符可能示意 4 比特的数据。编码的过程是将 "8 位组" (即八位字节) 的多组输出比特, 示意为多个 " 由 2
个编码字符形成 " 的多个字符串。依照从左至右的解决程序, 从原始输出中取
出 "8 位组" 作为编码输出。这些 "8 位组" 的输出将被视作由 2 个 "4 位
组 " 的数据形成, 每一组都会被编码为 base 16 字母表中的单个字符。每个 4 位组的数据被用作 "16 个可打印字符的数组" 的索引。被索引所援用
的字符置于输入字符串中。Josefsson Standards Track [Page 10]
RFC 4648 Base-N Encodings October 2006
表 5: Base 16 编码的字母表
值 编码 值 编码 值 编码 值 编码
0 0 4 4 8 8 12 C
1 1 5 5 9 9 13 D
2 2 6 6 10 A 14 E
3 3 7 7 11 B 15 F
不同于 base 32 和 base 64 编码, 这里不须要非凡的填充符; 因为 base 16
编码的最小单元是八位字节, 这在所有的数据中都能失去保障。9. 图解和示例
为了在二进制和 base 编码之间进行转换, 须要将输出存储在某一构造中, 并
从中提取所需的输入。下图中所展现的 base 64 编码的例子, 来自于 [5]。+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
下图所展现的 base 32 编码的例子, 来自于 [7]。在 base-32 编码后的值中,
每个间断的字符都示意: 原始的八位字节序列中的 5 个间断比特。因而, 每组
"由 8 个编码字符形成" 字符串示意一个 "由 5 个八位字节形成" (40 比特)
的序列。1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
+--------+--------+--------+--------+--------+
<===> 8th character
<====> 7th character
<===> 6th character
<====> 5th character
<====> 4th character
<===> 3rd character
<====> 2nd character
<===> 1st character
Josefsson Standards Track [Page 11]
RFC 4648 Base-N Encodings October 2006
上面无关 Base64 数据编码的示例来自于 [5] (已更正)。Input data: 0x14fb9c03d97e
Hex: 1 4 f b 9 c | 0 3 d 9 7 e
8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110
Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l +
Input data: 0x14fb9c03d9
Hex: 1 4 f b 9 c | 0 3 d 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36
pad with =
Output: F P u c A 9 k =
Input data: 0x14fb9c03
Hex: 1 4 f b 9 c | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
10. 测试样例
BASE64("") =""
BASE64("f") = "Zg=="
BASE64("fo") = "Zm8="
BASE64("foo") = "Zm9v"
BASE64("foob") = "Zm9vYg=="
BASE64("fooba") = "Zm9vYmE="
BASE64("foobar") = "Zm9vYmFy"
BASE32("") =""
BASE32("f") = "MY======"
BASE32("fo") = "MZXQ===="
Josefsson Standards Track [Page 12]
RFC 4648 Base-N Encodings October 2006
BASE32("foo") = "MZXW6==="
BASE32("foob") = "MZXW6YQ="
BASE32("fooba") = "MZXW6YTB"
BASE32("foobar") = "MZXW6YTBOI======"
BASE32-HEX("") =""
BASE32-HEX("f") = "CO======"
BASE32-HEX("fo") = "CPNG===="
BASE32-HEX("foo") = "CPNMU==="
BASE32-HEX("foob") = "CPNMUOG="
BASE32-HEX("fooba") = "CPNMUOJ1"
BASE32-HEX("foobar") = "CPNMUOJ1E8======"
BASE16("") =""
BASE16("f") = "66"
BASE16("fo") = "666F"
BASE16("foo") = "666F6F"
BASE16("foob") = "666F6F62"
BASE16("fooba") = "666F6F6261"
BASE16("foobar") = "666F6F626172"
Josefsson Standards Track [Page 13]
RFC 4648 Base-N Encodings October 2006
11. ISO C99 中的 Base64 编码的实现
在 ISO C99 中有 Base64 编码与解码的实现, 该实现被认为是遵循了此 RFC
中的所有倡议, 能够从这里获取:
http://josefsson.org/base-encoding/
其中给出的代码不是必须的。因为工作流程相干的起因, 不能在此 RFC 中蕴含该代码 ( 见 RFC 3978 中第
5.4 节 )。12. 平安注意事项
在实现 base 编码与解码时, 须要留神: 不要引入会造成内存溢出攻打、或其
它攻打的破绽。解码器不应因有效输出而解体, 例如遇到了嵌入在数据中的字
符 NUL (ASCII 0).
在解码过程中, 如果抉择疏忽掉非字母表中的字符, 且没有 (依照倡议) 回绝
掉整个编码数据, 则可能产生成一个导致信息 "泄露" 的荫蔽信道 (covert
channel)。被疏忽的字符也能够被用于其它的歹意目标, 例如: 躲避字符串的
判等、或登程实现中的 bug。未遵循举荐做法的利用, 该当弄清: 疏忽非字母
表中的字符, 这一行为背地的含意。相似的, 当以不辨别大小写的形式来解决
base 16 和 base 32 的字母表时, 字母大小写的变动可能被用于泄露信息、或
导致字符串的判等失败。当应用填充符时, 须要思考一些非无效比特位的安全性, 因为它们可能被滥用
来泄露信息、或绕过字符串的判等、或触发实现中存在的问题。Base 编码从视觉上暗藏了那些的易被辨认的信息, 例如明码, 然而它实际上并
未提供任何的计算保密性。而这有可能会导致安全事故, 例如: 当用户在报告
网络协议所替换的详细信息时 (可能是为了阐明其它问题), 会意外地将明码泄
露, 因为她并没有意识到 base 编码不能爱护明码。Base 编码不会使文本熵增, 然而它的确减少了文本的长度, 并以特色概率分布
(characteristic probability distribution) 的模式为明码剖析过程
(cryptanalysis) 提供了签名。Josefsson Standards Track [Page 14]
RFC 4648 Base-N Encodings October 2006
13. 自 RFC 3548 以来的批改
增加了 "应用扩大十六进制字母表的 base32" 的内容, 该编码被用于保留编码
数据的排序程序。参考了 IMAP, 以阐明其中用到的非凡的 Base64 编码。修复了从 RFC 2440 复制过去的示例。增加了无关 "提供明码剖析签名" 的平安注意事项。增加了测试样例。修复了笔误。14. 致谢
Several people offered comments and/or suggestions, including John E.
Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and
Andrew Sieber. Text used in this document are based on earlier RFCs
describing specific uses of various base encodings. The author
acknowledges the RSA Laboratories for supporting the work that led to
this document.
This revised version is based in parts on comments and/or suggestions
made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
15. Copying Conditions
Copyright (c) 2000-2006 Simon Josefsson
Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of
this document, that were written by Simon Josefsson ("the author",
for the remainder of this section), the author makes no guarantees
and is not responsible for any damage resulting from its use. The
author grants irrevocable permission to anyone to use, modify, and
distribute it in any way that does not diminish the rights of anyone
else to use, modify, and distribute it, provided that redistributed
derivative works do not contain misleading author or version
information and do not falsely purport to be IETF RFC documents.
Derivative works need not be licensed under similar terms.
Josefsson Standards Track [Page 15]
RFC 4648 Base-N Encodings October 2006
16. 参考文献
16.1. 前提类参考文献
[1] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
16.2. 信息类参考文献
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[7] Klyne, G. and L. Masinter, "Identifying Composite Media
Features", RFC 2938, September 2000.
[8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[10] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
Authenticated Denial of Existence", Work in Progress, June
2006.
[11] Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
2000.
[12] Wilcox-O'Hearn, B.,"Post to P2P-hackers mailing list",
http://zgp.org/pipermail/p2p-hackers/2001-September/
000315.html, September 2001.
Josefsson Standards Track [Page 16]
RFC 4648 Base-N Encodings October 2006
作者地址
Simon Josefsson
SJD
EMail: simon@josefsson.org
Josefsson Standards Track [Page 17]
RFC 4648 Base-N Encodings October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Standards Track [Page 18]