6.8 Base64 Content-Transfer-Encoding
设计Base64内容传输编码是为了描述任意的不需要人为识别的字节序列。编码及解码算法很简单，不过，编码后的数据总是比编码前的数据长33%。Base64与RFC1421中定义的Privacy Enhanced Mail (PEM)是同一个编码方法。
由US－ASCII中65个字符组成一个子集，使用6位来表示每一个可打印的字符（第65个字符“=”表示要进行特殊的操作）
注意：这个子集有个很重要的性质，那就是，在任何版本的ISO 646(包括US-ASCII)中，它都被描述成相同的内容。而且，在任何版本的EBCDIC中，子集中的所有字符也都具有相同的描述。其它常用的的编码，如UUENCODE、Macintosh binhex 4.0 [RFC-1741]、base85就没有这些性质，因此就无法满足邮件二进制传输编码的可移植性要求。
编码时，每次输入24位数据，输出为4个编码字符。将输入的3个8位字节从左到右连续排列，就可以形成24位数据。将这24位看做是4个连续的6位组，每组都可以单独译成一个base64表中的字符。当通过base64编码方式编码一个位流时，必须假定位流为“重要位优先”的顺序。就是说，位流中的第1位应该是第一个字节中的最高位；位流中的第8位应该是第一个字节中的最低位，依此累推。
用每组(6位)的值来索引64个可打印字符。索引后将得到的字符依次放入输出字符串中。选择表1中的这些字符，是为了能够完备的描述，并且排除在SMTP中有特殊意义的字符(如‘.’、CF、LF)以及在RFC2046中定义的multipart的边界分隔符中有特殊意义的字符(如‘-’)。
表1：base64字母表
Value Encoding Value Encoding Value Encoding Value Encoding
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 (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
编码输出的流必须被描述成一些不大于76字节的行。解码时，必须要忽略换行符及其它所有不存在于表1中的字符。在base64数据中，除表1中字符、换行符、空格之外的字符都可能表示存在传输错误，在某些情况下，可以适当的给出一些警告信息甚至是拒绝信息。
如果需要被编码数据的剩余部分不足24位，则要执行特殊的操作。编码量通常在主体（body）结尾部分结束。当输入少于24位时，会在末尾(右侧)添加一些值为0的位，以形成完整的6位组。用“=”来表示数据结尾的填充。因为所有base64的输入都是完整的字节，所以只可能出现如下情况：(1)最后的编码输入是完整的24位；这时，编码输出的最后一个单元会是完整的4个不为“=”的个字符。(2)最后的输入是8位；这时，编码输出的最后一个单元是两个编码字符后接两个填充字符“=”。(3)最后的输入刚好是16位；这时，编码输出的最后一个单元是三个编码字符后接一个填充字符“=”。
因为“=”是用来填充数据的结尾部分，所以，它的出现意味着可能已经到达数据末尾(但不切断传输)。然而，也可能无法以这种方式进行判断：当传输的字节个数是三的整数倍时，编码中就不会出现“=”。
在base64编码数据中，要忽略任何不属于base64字母表的字符。
一定要注意，当base64编码直接应用于未经过规范化的文本内容时，要使用恰当的字节做为换行符。特别是在进行base64编码前，必须要将文本换行符转换为CRLF序列。要注意，一件很重要的事情就是：这些操作可以直接由编码器来完成，而不是在一些实现中先进行一个标准化的步骤。
注释：不用担心multipart实体中的base64编码部分引用到潜在的边界分隔符（boundary delimiter），因为base64编码中没有使用连字符“-”。
7. Content-ID 头字段
在构建一个高级别的用户代理时，可能会需要在一个主体（body）中涉及到另一个主体。因此需要用“Content-ID”头字段给主体（body）设置标签。这个字段在语法构成上与“Message-ID”相同：
id := "Content-ID" ":" msg-id
与Message-ID的值一样，Content-ID的值也必须是世界上唯一的。
Content-ID的值可以被用来在多处上下文中唯一的确定MIME实体，尤其用于被message/external-body机制所引用的缓存数据。虽然Content-ID头字段通常是可选的，但是对于生成可选的媒体类型“message/external-body”的实现程序来说，它则是必须存在的。这就是说，每一个message/external-body实体（entity）必须有一个Content-ID字段来允许对这些数据的缓存。值得注意的是，Content-ID值在multipart/alternative媒体类型中有特殊的意义。这一点会在RFC2046中关于multipart/alternative的那一节中进行解释。
