关于电子邮件中编码规范的一些总结

关键词:邮件  编码规范  透明加密

关于电子邮件中编码规范的一些总结：

 

在这些文件的早期版本中存在一些混淆，关于电子邮件数据被转换为规范形式和被编码时的模式，特别是这个过程将如何影响所有CRLF的处理，考虑到换行符因系统而异。为此，下面介绍编码的典型模型。组成MIME实体的过程可以在许多步骤中建模完成。

 

（1）创建本地形式。

 

要传输的正文是在系统中创建的原生格式。使用本地字符集，在适当的情况下，本地行尾约定同样也被使用。正文可能是一个UNIX风格的文本文件，或者一个太阳的光栅图像，或者一个VMS索引文件，或者依赖于系统的格式仅存储在内存中的音频数据，或者用于某种形式的表示信息的与本地相对应的任何其他内容模型。基本上，数据是在“本地”形式，对应于指定的类型媒体类型。

 

（2）转换为规范形式。

 

整个正文，包括以外的信息如记录的长度和可能的文件属性信息，被转换为通用的规范形式。正文的特定媒体类型以及它的相关属性决定了它使用的规范形式的本质。转换到正确的规范形式可能涉及字符集转换， 音频数据的转换，压缩或各种其他特定于各种媒体类型的操作。但是，如果涉及字符集转换，请小心必须理解媒体类型的语义，这可能对任何字符集转换都有强烈影响，例如关于文本子类型中具有语法意义的字符除“plain”外。例如，在text/plain 类型数据的情况下，文本必须转换为被支持的字符集，并且所有的行必须按照按照RFC 822规范用英文中的CRLF分隔符分隔，注意RFC822中必须具备的行长度限制被取消，如果下一步采用quoted-printable或base64编码。

 

（3）应用传输编码。

 

本结构专有的Content-Transfer-Encoding已经被应用。请注意，媒体类型和传输编码之间没有固定的关系。特别是，根据特定于正文的特定实例的字符频率总数来选择base64或QP编码。

 

（4）插入实体。

 

被编码的正文被插入拥有合适标题的MIME实体中。根据实际需求该实体然后插入更高级别实体的主体（message or  multipart ）。从实体形式到本地形式的转换是通过 颠倒这些步骤。请注意，可能会产生这些步骤的逆转由于不能保证原来的和不同的结果最终的本地形式是相同的。需要注意的是，这些步骤只是一个模型; 他们尤其不是制定实际系统的蓝图。特别注意，该模型未能说明两种常见设计：

 

（1）在许多情况下，事先转换为规范形式再编码将被纳入编码器本身， 它直接了解本地格式。例如，文本体的本地换行约定可能是与编码器一起传送到编码器本身了解这种格式是什么。

 

（2）编码器的输出可能必须通过一个或者更多步骤在被作为一个消息传输之前的。这样，编码器的输出可能不符合RFC 822规定的格式。特别是，再次说明他可能适合使用本地换行约定来表示转换器的输出，而不是使用标准的RFC 822 CRLF分隔符。其他的实现变化也是可以想象的。这个讨论的重要方面就是这个，尽管有任何优化，所需步骤失去控制，或着插入额外的处理，由此产生的消息必须与由那些在这里描述的模型所产生的消息一致。例如，具有以下内容的消息标题栏：

Content-type: text/foo; charset=bar  

Content-Transfer-Encoding: base64 必须首先以text/foo的形式表示，然后（如有必要）用“bar”字符集表示，最后通过转换 base64算法转换为邮件安全形式。注意：一些混淆是由系统使用与RFC822 CRLF约定不同的本地换行符约定格式的代表消  息造成 。注意到这一点很重要 这些格式不是经典的RFC822 / MIME。这些格式是作为 代替RFC822的编码，其中规范表示的消息中的CRLF序列被编码作为本地换行符的约定。    请注意，编码CRLF序列的格式如下所示，例如，LF不能表示包含包含二进制数据的      MIME消息，该二进制数据包含不是CRLF行序列分离部分的LF 8位字节。

 

最后推荐一款在学习邮件协议时遇到的一个关于邮件透明加密的产品，就是天御云安推出的隐秘邮，隐秘邮在确保邮件内容加密的同时，部署对于用户也是透明的，既满足加密需求也不影响用户使用习惯。网址： https://mail.tyyunan.com/

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69911143/viewspace-2637993/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/69911143/viewspace-2637993/