rfcrfc2046.txt

本程序为在linux下实现FTP传输文件的实现

preamble := discard-text
epilogue := discard-text
discard-text := *(*text CRLF) *text
                  ；可以忽视或丢弃
body-part := MIME-part-headers [CRLF *OCTET]
                  ；在主体部分的内容千万不能以特定的虚边界开始，分隔符也不能在主
体的任何地方出现。注意到主体部分的语法分析器不同于报文的语法分析器，正如在文本中
描述的那样。
    OCTET := <any 0-255 octet value>
重要的：在这个BNF中显示的成分中自由地插入linear-white-space和RFC822注解是
不允许的。因为这个BNF没有指定一个结构化的报头字段。
注意：在确定的传输领域，RFC822的限制条文比如限制主体部分使用printable 
US-ASCII 字符可能并不是有效的。（那就是说，传输领域中存在着类似在RFC821中规定
且在RFC822中假定的internet邮件传输标准，但是没有确定的限制条文。）对这些限制的放
宽可以这样被认为是局部地扩展主体的定义，比如说：在US-ASCII的范围外再包含八位位
组，只要传输支持这些扩展，并且在Content- Transfer-Encoding（内容传输编码）报头字段
中充分地记录。但是头部（不管是报文头还是主体部分的头部）在任何情况下都不允许包含
非US-ASCII字符。
注意：在multipart类型中明显缺少的是一种结构化的主体部分。那些若想提供更多结
构化或完整化的multipart报文传输便利性，则需要定义在语句构成上一致的multipart的子
类型，但在不同部分要定义相互关系。举个例子，multipart的子类型可以被定义为包括一个
特有的部分，它依次被使用来规定不同部分的关系，可以在Content-ID（内容ID）字段注
明。若采用这种方法的话，旧的执行部分将无法识别新的子类型，但将把它作为
multipart/mixed类型，这样使得用户能识别标志的部分。
5. 1. 2处理嵌套的报文和multiparts（多部分）
在这个文档的并发部分定义的"message/rfc822"子类型除非数据用完，否则不会终结。
同样，一个不正确地缩短了的"multipart"实体可能没有终止边界标记，由于邮件系统的瘫痪
在操作上会出现这种情况。
当这些实体嵌入到另一个multipart结构中时，有必要对这些实体进行正确的处理。因
此MIME的执行就要能识别在任何层次内部嵌套中的外层的边界标记。仅仅检查下一个预
期的标记或其它终结条件是不够的。
5. 1. 3 Mixed子类型
当主体部分是独立的并且需要按一定的顺序捆绑时就要用到multipart类型的子类型
"mixed" 。任何一种执行时无法识别的multipart子类型都被视为子类型"mixed"。
5. 1. 4 alternative子类型
"multipart/alternative"类型与"multipart/mixed"在语句构成上是一致的，但语意是不同的。
不同处在于主体的每一部分都是相同信息的选择性版本。
系统应当承认不同部分的内容是可互换的。系统可以根据本地的环境和参照来选择最
好的类型，有时甚至可以通过与用户的交互。对于"multipart/mixed"类型，主体部分的顺序
是很重要的。因此，alternatives以不断忠实于原文的顺序出现。通常，最佳的选择是最后部
分用系统本地环境易于接收的类型。
举个例子，"multipart/alternative"可以用来以文本格式发送报文从而能方便地在任何地方
展现出来：

From: Nathaniel Borenstein <[e-mail]>
     To: Ned Freed <[e-mail]>
     Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
     Subject: Formatted text mail
     MIME-Version: 1.0
     Content-Type: multipart/alternative; boundary=boundary42

     --boundary42
     Content-Type: text/plain; charset=us-ascii

       ... plain text version of message goes here ...

     --boundary42
     Content-Type: text/enriched

       ... RFC 1896 text/enriched version of same message
           goes here ...

     --boundary42
     Content-Type: application/x-whatever

       ... fanciest version of same message goes here ...

     --boundary42--
在这个例子中，邮件系统理解了"application/x-whatever"格式的用户只愿看到想要的版
本，而其它用户根据他们系统的实际容量将只愿看到enriched（丰富的）版本或plain text(纯
文本的)版本。
通常，组织"multipart/alternative" 实体的用户代理商必定按偏爱递增的顺序来放置主体部分，
也就是说首选的格式放在最后。对fancy text格式，发送方用户代理商会把最简单的格式放
在最前，最丰富的格式放在最后。接手方用户代理商可挑选显示他们能够显示的最后的格式。
如果二中之一自身是multipart类型且包含不可识别的子部分时，用户代理商就会选择或者
显示这其中之一，即早期的那个，或者两者都显示。
注意：从执行者的观点看，也许把这个顺序倒过来更明智些，就是把最简单的放在最
后。然而，当"multipart/alternative"实体被认为用non-MIME-conformant阅读器时，把最简单
的放在最先是一种可能的选择。然而这种方法加重了conformant MIME阅读器的负担，在
此时它与旧的邮件阅读器的互用性就非常重要了。
也许会出现这种情况，一些用户代理如果能够识别不止一种格式，他们将会让用户选
择观看的格式。举个例子，如果报文既包括了精细格式的image 版本，又包括了易于编辑
的text版本，那将是很有意义的。但是最重要的是，用户并非无意识地看到了同一数据的多
种版本。用户或可看到最后被识别的版本，或可以作出选择。

在MULTIPART/ALTERNATIVE中CONTENT-ID（内容ID）的语义："multipart/alternative"
实体的每一部分代表了相同的数据，但是两者之间的映射并不一定没有信息丢弃。举个例子，
当把ODA翻译成附言或纯文本时，信息就会丢弃。在两部分信息内容不一致处，建议给每
一部分一个不同的Content-ID（内容编号）值。当信息内容一致时。比如说，
"message/external-body"类型的几个部分规定了交替的方法存取一致的数据，此时就应当使用
相同的Content-ID字段值来优化任何的高速缓存机制，这机制在接受方的终端。然而，如
果有这种Content- ID字段的话，不同部分的Content- ID值也不该与描述
"multipart/alternative"的完全相同。也就是说，一个Content- ID值指着"multipart/alternative" 实
体，然而一个或多个其它的Content-ID值将指向各部分的内部。
5. 1. 5 Digest子类型
这个文档定义了multipart内容类型的digest子类型。这个类型在语句构成上跟
"multipart/mixed"是一致的，但语义是不同的。尤其是，在摘要中，主体部分缺省的内容类
型值是在"text/plain"和"message/rfc822"之间变化的。这样做就允许了易读的摘要格式，它对
RFC934的兼容性非常的好（除了引用文惯例）。
注意：虽然在不同于"message/rfc822"的摘要的主体部分指定一个内容类型值是可行的，
比如一个"text/plain"部分包含了摘要内容的描述，事实上这样做是不可行的。
"multipart/digest"内容类型是用来发送报文集的。如果需要"text/plain"部分，它将作为
"multipart/mixed"报文的单独的部分包括进来。
这种格式的摘要看起来如下：

     From: Moderator-Address
     To: Recipient-List
     Date: Mon, 22 Mar 1994 13:34:51 +0000
     Subject: Internet Digest, volume 42
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="---- main boundary ----"

     ------ main boundary ----

       ...Introductory text or table of contents...

     ------ main boundary ----
     Content-Type: multipart/digest;
                   boundary="---- next message ----"

     ------ next message ----

     From: someone-else
     Date: Fri, 26 Mar 1993 11:13:32 +0200
     Subject: my opinion

       ...body goes here ...

     ------ next message ----

     From: someone-else-again
     Date: Fri, 26 Mar 1993 10:07:13 -0500
     Subject: my different opinion

       ... another body goes here ...

     ------ next message ------

     ------ main boundary ------


5. 1. 6.  Parallel 子类型
这个文档定义了"multipart"内容类型的"parallel"子类型。这种类型在句法上与
"multipart/mixed"是一致的，但是语义是不同的。特别的，在一个并行实体中，主体部分的
顺序并不是非常重要的。
这种类型的一个普通的介绍就是把各部分同时在可能的软硬件上显示出来。然而，组织
代理会意识到许多邮件读者不具备这种能力，无论如何都会顺序地显示各部分。
5. 1. 7其他的Multipart子类型
其他的Multipart子类型将会出现。MIME的实现通常必定把无法被识别的multipart子
类型等同地视为"multipart/mixed"。
5.  2. 报文媒体类型
在发送邮件时，通常希望封装在另一个邮件报文中。一种特殊的媒体类型"message"就
是被定义来实现这个功能的。特别的是，"message"（报文）的"rfc822"子类型就是用来封装
RFC822报文。
注意：报文的子类型或许被定义来接受或丢弃报文。然而，接受或丢弃的报文可以被当
成多部分报文来处理，其中第一部分包含了所有的控制和描述信息，第二部分
"message/rfc822"类型是被接受或丢弃报文。在这种方式下，组和起来的接受或丢弃的报文
将会保留在原始报文中的类型信息，允许它正确地递交给接受方，因此它是被倡导的。
报文的子类型常常在在允许编码的地方加上限制。这些限制的描述和每一种特定的子类
型都是关联的。
邮件网关、中继和其它的邮件处理代理通常是改变RFC 822报文的顶层（top-level）报
头。特别是，他们频繁地增加、删除、追加头文件字段。这些操作对封装的即内含在message
类型的报文主体内的报头来说是明确禁止的。
5. 2. 1  RFC 822子类型
"message/rfc822"的媒体类型指出：主体按照RFC 822报文的句法包含了封装的报文。
然而，不象顶层的RFC 822报文，这些限制（也就是说每个"message/rfc822"主体必须包含
一个"From", "Date"和至少一个目的头文件）被删除了，以这样的要求来替代：也就是说必
须出现"From", "Subject", 或 "Date" 中的一个。
应当注意到：尽管使用了数字"822"，但是"message/rfc822"实体并不严格限于与RFC 822
完全一致。"message/rfc822"对象的语义也不必限定于RFC 822中定义的语意。更明确的是，
"message/rfc822"报文可以是消息条款或一种MIME报文。 
除了"7bit"、"8bit"或"binary"外，其它的编码对"message/rfc822"实体的主体来说都是不
允许的。报头字段在任何情况下都是US-ASCII，主体内的数据仍可编码，在这种情况下，
处在封装的报文内的Content-Transfer-Encoding（内容传送编码）的报头字段将会反映这一
点。在封装的报文头的Non-US-ASCII text可以指定为使用RFC 2047中描述的机制。