Cra*_*ker 238
读取它可能有点密集,但RFC 1341的"Content-Transfer-Encoding"部分包含所有细节:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
情况有点变得越来越糟.这是我的总结:
根据定义(RFC 821),SMTP将邮件限制为每行7位的1000个字符的行.这意味着您向管道发送的所有字节都不能将最高有效("最高位")位设置为"1".
我们想要发送的内容通常不会遵守此限制.想象一下图像文件或包含Unicode字符的文本文件:这些文件的字节通常将其第8位设置为"1".SMTP不允许这样做,因此您需要使用"传输编码"来描述您如何解决不匹配问题.
Content-Transfer-Encoding标题的值描述了您选择解决此问题的规则.
7bit简单地表示"我的数据仅包含US-ASCII字符,每个字符仅使用低7位." 您基本上保证内容中的所有字节都符合SMTP的限制,因此不需要特殊处理.你可以按原样阅读.
请注意,当您选择时7bit,您同意内容中的所有行的长度都少于1000个字符.
只要您的内容符合这些规则,7bit就是最好的传输编码,因为不需要额外的工作; 你刚从管道中读取/写入字节.它也很容易引人注目7bit并理解它.这里的想法是,如果你只是用"简单的英文文本"写作,你会没事的.但在2005年并非如此,今天并非如此.
8bit表示"我的数据可能包含扩展的ASCII字符;它们可能使用第8个(最高)位来指示标准US-ASCII 7位字符之外的特殊字符." 与此同时7bit,仍有1000个字符的行限制.
8bit就像7bit,当它们被写入或从线路读取时,实际上并没有对字节进行任何转换.它只是意味着您不能保证没有任何字节将最高位设置为"1".
这似乎是一个进步7bit,因为它为您提供了更多的内容自由.但是,RFC 1341包含这个小节目:
截至本文档发布时,没有标准化的Internet传输,在邮件正文中包含未编码的8位或二进制数据是合法的.因此,在任何情况下,"8位"或"二进制"内容传输编码在互联网上实际上都是合法的.
RFC 1341在20多年前问世.从那时起,我们在RFC 6152中获得了8位MIME扩展.但即便如此,行限制仍然可能适用:
请注意,此扩展不会消除SMTP服务器限制行长度的可能性; 服务器可以自由地实现此扩展,但仍设置不低于1000个八位字节的行长度限制.
binary是相同的8bit,除了没有行长度限制.您仍然可以包含任何您想要的字符,并且没有额外的编码.类似于8bit,RFC 1341声明它不是真正的合法编码传输编码.RFC 3030对此进行了扩展BINARYMIME.
在8BITMIME扩展之前,需要有一种方法来发送无法7bit通过SMTP的内容.HTML文件(可能包含超过1000个字符的行)和具有国际字符的文件就是很好的例子.的quoted-printable编码(在RFC 1341的5.1节中定义的)被设计成处理这一点.它做了两件事:
引用的Printable,由于逃避和短线,人类比7bit或更难阅读8bit,但它确实支持更广泛的可能内容.
如果您的数据主要是非文本(例如:图像文件),则您没有很多选项.7bit不在桌子上.8bit并且binary在MIME扩展RFC之前不受支持.quoted-printable会工作,但效率很低(每个字节将由3个字符表示).
base64对于这种类型的数据是一个很好的解决方案.它将3个原始字节编码为4个US-ASCII字符,这是相对有效的.RFC 1341进一步将base64-encoded数据的行长度限制为76个字符以适合SMTP消息,但是当您只是按固定长度拆分或连接任意字符时,这相对容易管理.
最大的缺点是 - base64编码数据几乎完全是人类无法读取的,即使它只是下面的"普通"文本.