MIME文档说明书.doc

MIME协议文档说明书 RFC#1521协议 简介 RFC#822定义了消息头的传输标准，而把消息体当成纯ASCII文本。这个文档重新定义了消息体的格式，使得消息体在交换非文本信息时不会失真。同时也使得消息可以在RFC#822主机和X.400主机（认为在消息体中加入非文本信息是合法的）之间进行交换。 该文档主要描述了MIME-Version字段、Content-Type字段、 Content-Transfer-Encoding字段。另外还简单的介绍了两个额外的字段：Content-ID和Content-Description MIME是可扩展的，它允许通过一定的方式向IANA注册新的字段或对现有字段的取值范围进行扩充。 在对文档进行进一步描述之前，需要先界定如下字段的含义： message,当没有进一步说明，它可以表示一个正在网上传输的完整消息，也可表示封装在一个Content Type值为message/rfc822或message/partial的body里的消息。 body part，表示Content-Type值为multipart的消息实体的一部分，它有一个头和一个体。 entity，实体，由MIME定义的头和消息或body part中的内容组成。 body,表示message或body part的体部分。 MIME-Version字段 该字段用一个版本号说明了消息所要遵循的规范，以区别不兼容的消息版本。如，MIME-Version: 1.0表示该消息遵循rfc#1521。为了便于描述以后扩展的消息格式，我们把MIME-Version字段定义为： version := MIME-Version : 1*DIGIT . 1*DIGIT ;两个被点（.）分开的整数。 由于MIME-Version头字段被要求放在消息的顶层。因此并不是每一个multipart entity的body part都要使用。只有当内嵌消息自己声明为MIME-conformant时，该字段才是必须的。 另外，值得注意的是，对于某些特定的content-types，版本控制不是由MIME-Version机制完成的。特别地，一些格式（如application/postscript）的版本编号方式规则是与特定的文档格式相关的。当这些规则存在的时候，MIME不会替代它们；当这些规则不存在的时候，必要时或许会在content-type字段的version参数里使用MIME类型。 注：所有在该文档中定义的字段，包括MIME-Version,Content-type都必须遵循在RFC#822中定义的头字段的句法规则。另外，所有字段均可包含注释。例如，如下两种表达方式是等价的： MIME-Version: 1.0 MIME-Version: 1.0 (Generated by GBD-killer 3.7) Content-Type字段 Content-Type字段，用于描述消息体中的数据类型以使消息接受者能够选择合适的机制来使这些数据呈现在用户面前。 Content-Type字段主要是通过给定类型和子类型以明确消息体的数据类型，对于某些类型或许还需要提供某些辅助信息。在类型和子类型名之后是一系列的以属性或值表达的参数。不同的类型有不同的参数，没有对于所有类型都适用的参数。参数的排序是没有意义的。在定义的参数当中有一个名为charset，通过这个参数可以声明在消息体中使用的字符集。 一般，Content-Type字段的高层用于声明通用的数据类型，而子类型(subtype)用于指定针对特定数据类型的格式。例如，当Content-Type字段值为image/xyz时，我们可以断定该消息体数据类型为图像，尽管我们不知道xyz是哪一种图像格式。 尽管大多数参数只对特定Content-Type字段有意义，有的参数却可以应用于任何子类型。例如boundary或许只对multipart字段有意义，但是charset却对几个Content-Type字段均有意义。 该文档初始定义了Content-Type字段的七个属性值，以后更多的类型可能会被定义以作为对该标准的扩充。因此当用户需要使用其它字段时，必须在字段名前加X-，以免与以后官方定义的名字相冲突。 以扩充的BNF语法来定义RFC#822，一个Content-Type字段可以定义如下： content := Content-Type : type / subtype *(; parameter) ; case-insensitive matching of type and subtype type := application