RFC2045译文(3)

3. MIME头字段（MIME Header Fields）

MIME定义了许多新的RFC822头字段，用以描述MIME实体内容(entity content)。这些头字段至少会在以下两个地方出现：

 

（1）      做为规则的RFC822消息(message)头信息的一部分。

 

（2）      在多部分结构（multipart construct）里，存在于“部分主体”（body part）头信息中。

 

这些头字段的形式定义如下：

 

     entity-headers := [ content CRLF ]

                       [ encoding CRLF ]

                       [ id CRLF ]

                       [ description CRLF ]

                       *( MIME-extension-field CRLF )

 

     MIME-message-headers := entity-headers

                             fields

                             version CRLF

                          ; 当前BNF所暗含的实体头信息

                          ; 顺序可以被忽略。

     MIME-part-headers := entity-headers

                          [ fields ]

                          ; 任何不以“content-”开始的字段

                          ; 都没有被定义，可以被忽略。

                          ; 当前BNF所暗含的实体头信息

                          ; 顺序也可以被忽略。

 

不同的MIME头字段的语法细节会在下面的章节中说明。

 

4. MIME-Version头字段

自从1982年发布了RFC 822以来，实际上只存在这一种Internet消息格式标准，而且几乎没人意识到需要声明那些正在使用中的格式。这篇文档是一个补充RFC822的独立说明。虽然在这篇文档中所做的扩展已经被定义为与RFC 822兼容，但是，邮件处理代理仍然需要知道一个消息是否是按照新的标准构成。

 

为此，本文档定义了一个新的头字段：“MIME-Version”。它被用来声明Internet消息主体(message body)所使用格式的版本号。

 

按照本文档格式所构成的消息(message)，必须按如下格式包含这个头字段：

 

MIME-Version: 1.0

 

这个字段就是一个声明，它表示消息的结构符合本文档所规定的格式。

 

因为今后的文档中有可能再次扩展消息格式的标准，所以这里给出MIME-Version头字段的BNF：

 

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

 

这样，将来的格式说明符都被约束为以小数点分隔的两个整数，它们可能会替代或扩展字符：“1.0”。如果接收到一个消息，它的MIME-version值不是“1.0”，那么就可以假定它不符合本文档的规范。

 

还有一件值得注意的事情是，不可以使用MIME-Version机制来实行对媒体类型的版本控制。特别的，一些格式（如application/postscript）拥有包含在媒体格式内部的约定版本号。当这种约定存在时，MIME不会将其取代。当这种约定不存在时，MIME会在必要的时候使用“content-type”字段中的一个“version”参数进行声明。

 

实现者要注意的问题：在检查MIME-Version的时候，一定要忽略任何在RFC822中所定义的注释部分。详细的说，以下的MIME-Version字段是等价的：

 

        MIME-Version: 1.0

 

           MIME-Version: 1.0 (produced by MetaSend Vx.x)

 

           MIME-Version: (produced by MetaSend Vx.x) 1.0

 

           MIME-Version: 1.(produced by MetaSend Vx.x)0

 

当缺少MIME-Version字段时，接收邮件的代理（无论此代理是否符合MIME要求）都可以按照本地的约定，任意的解释消息体。在当前的使用中存在的许多这样的约定。应该注意到，在实际中非MIME消息可以包含任何内容。

 

无法确定一个非MIME邮件消息中只包含US-ASCII字符集的纯文本内容，因为这个消息很可能使用了一些非标准的比MIME更早出现的本地约定，或是包含其它字符集的内容或非文本的内容，这样，消息就无法被自动的识别。（如用UUENCODE方式编码的UNIX tar压缩文件）