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压缩文件)

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值