rfcrfc2046.txt

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

5. 2. 2  Partial子类型
"partial"子类型是用来把大的邮件分成几个独立的片段进行传送，然后由接受方的用
户代理自动地组装。（这思想与IP分组后用基本的IP协议组装相似。）当中间传输代理限制
了单个可传送报文的大小时就可使用这种机制。媒体类型"message/partial"就这样指出，主体
包含了一个大的邮件的片段。
因为"message"类型的数据从不会用base64或quoted-printable（加引号的可打印）类型
编码，若"message/partial"邮件在支持binary或8bit传输的环境中构建，那就会出现问题。
这问题就是binary数据将会被分成多部分的"message/partial"报文，每一部分要求二进制传
输。若这些报文在网关遇到了7bit的传输环境，除了等待所有的片段组装成内部的报文，
然后把组装的数据以base64或quoted-printable类型编码，没有合适的方法进行7bit的编码。
虽然不同的分组可以经由不同的网关，但是这仍然是不可接受的解决办法。因此规定了
"message/partial"类型邮件必须有7bit（默认）的内容传输编码。特别的，即使在支持binary
或者8bit传输的环境中，使用8bit或binary的内容传输编码对"message/partial"类型的MIME
邮件来说是明确禁止的。这也就反过来意味着内部的报文决不能使用8bit或binary编码。
因为一些报文传输代理选择自动地把大的报文分段，并且因为这些代理使用不同的分
段极限，所以部分的报文片段在重新组装以后，可以看出他们是由部分的报文组成的，这是
明确允许的。
在"message/partial"类型的内容类型字段必须规定三个参数：首先是ID，这是一个唯一
的标志符，是使用来匹配所有的分段。（通常，标志符必须是一个message-id；如果放在双
引号中，它可以是任何的message-id,与RFC 2045中给出的BNF参数是一致的。其次是
number,一个整形，是分段号，它指示了每个分段的次序。最后是total，另一个整形，是分
段的总数。在最后一个分段上必须由这个字段，在之前的分段上它是可选的（虽然最好写上）。
同样注意：这些参数的顺序是任意的。
这样，三部分报文的第二部分可以是下列报头字段的任一种：
Content-Type: Message/Partial; number=2; total=3;
                   id="oc=[e-mail]"

    Content-Type: Message/Partial;
                   id="oc=[e-mail]";
                   number=2
但是第三部分必须指定总的分段数：
Content-Type: Message/Partial; number=3; total=3;
                   id=oc=[e-mail]
请注意：分段编号从1而非0开始。
当一个邮件以这种方式被分解成的片段组合在一起，结果总是一个完整的MIME邮件，
它可能有自己的内容类型报头字段，因此可能含有任何其它的数据类型。
5. 2. 2. 1报文分段和重组
重组分段报文的语义必须是"inner"报文的语义，而不是包含内部报文的报文语义。这就
使得以单独的分组报文发送一个大的audio报文成为可能，而且对接受方与其说是一个包含
一个audio报文的封装报文，不如说是一个简单的audio报文。那就是说，封装的报文是透
明的。
当产生和重组"message/partial"类型的报文片段时，被封装报文的报头必须与封装实体的
报头合并。在这个过程中必须遵守下列规则：
（1）分片代理必须只用边界线把报文分割。引入这条限制是因为在点上而非在行的末
尾进行分割，反过来依靠报文传输能够保留不以CRLF序列结束的报文语义。许多传输是不
能保留这种语义的。
（2）除了那些以"Content-"或特定的报头字段"Subject"、 "Message-ID"、          
"Encrypted"、 "MIME-Version"开始的报头外，其它所有来自初始嵌套报文的报头字段都必
须按序复制到新的报文中去。
（3）以"Content-"加上 "Subject"、 "Message-ID"、 "Encrypted"和 "MIME-Version"字
段开始的嵌套报文头字段必须按序添加到新报文的报头字段。任何不以"Content-"开始的嵌
套报文头字段将被忽视或丢弃。（除了"Subject"、 "Message-ID"、 "Encrypted"和"MIME-          
Version" 字段）
（4）第二或以后嵌套报文的所有报头字段都会被重组过程丢弃。
5. 2. 2. 2  分割和重组实例
如果一个audio报文被分割成两个部分，第一部分可以是这样：

     X-Weird-Header-1: Foo
     From: [e-mail]
     To: [e-mail]
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 1 of 2)
     Message-ID: <[e-mail]>
     MIME-Version: 1.0
     Content-type: message/partial; id="[e-mail]";
     number=1; total=2

     X-Weird-Header-1: Bar
     X-Weird-Header-2: Hello
     Message-ID: <[e-mail]>
     Subject: Audio mail
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... first half of encoded audio data goes here ...
第二部分可以是这样：

     From: [e-mail]
     To: [e-mail]
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 2 of 2)
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-type: message/partial;
                   id="[e-mail]"; number=2; total=2

       ... second half of encoded audio data goes here ...
然后，当分割的报文重组后，显示给用户的结果报文应该是这样：

     X-Weird-Header-1: Foo
     From: [e-mail]
     To: [e-mail]
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail
     Message-ID: <[e-mail]>
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... first half of encoded audio data goes here ...
       ... second half of encoded audio data goes here ...
分割报文第二和以后片段的报头中包括"References"字段，参考先前片段的Message-Id
对邮件读者理解和跟踪参照来说有益的。然而，象参考字段这样的字段是完全可以任意选择
的。
5. 2. 3  External-Body(外部主体)子类型
    External-Body(外部主体)子类型表明实际体数据仅仅是被引用,而不被包含在内.既然这
样,参数就描述一种访问外部数据的机制.当一个MIME实体是 "message/external-body"类型,
它包括一个报头,两个连续的CRLFs,以及用于被压缩报文的报头.如果出现另一对连续
CRLFs,用于被压缩报文的报头就结束.然而由于被压缩的报文主体本身是外部的,它并不会
出现在随后的区域内.以如下报文为例:
        Content-type: message/external-body;
                   access-type=local-file;
                   name="/u/nsb/Me.jpeg"

     Content-type: image/jpeg
     Content-ID: <[e-mail]>
     Content-Transfer-Encoding: binary

     THIS IS NOT REALLY THE BODY!
    称之为"影子主体(phantom body)"的结尾区域对大多数的外部主体报文来说是被忽略的.
然而,当访问类型是"mail-server(邮件-服务)"时,它用于包含某些辅助信息.
   在文档中定义的使用影子主体(phantom body)的唯一访问类型是"mail-server(邮件-服务)",
但未来在其他规范中可能会定义另外一些使用这一区域的访问类型.
   在所有"message/external-body(报文/外部主体类型)"实体中,这些被压缩的报头必须包含
一个Content-ID(内容ID)字段作为唯一标识用来引用数据.当访问类型是"mail-server(邮件-服
务)"时,这个标识被用于缓冲机制和数据接收的识别.
  注:正如这儿所说明的,用于描述external-body(外部主体)数据的标记,例如文件名以及邮件
服务命令在US-ASII字符集中是必须的.
   如果在实际应用中存在问题,那么可能就需要一种新的机制作为MIME的未来扩充,要么
为"message/external-body(报文/外部主体)"定义最新的访问类型,要么通过其他一些机制.
  与"message/partial(报文/部分)"一样,类型"message/external- body(报文/外部主体)"的MIME
实体必须一个7bit(缺省)的
content-transfer-encoding(内容传送编码).特别的,对于"message/external- body(报文/外部主
体)"类型的实体来说,即使在支持binary(二进制)和8bit传输的环境中,binary(二进制)和8bit
的内容编码传送的使用也是被明确禁止的.
5. 2. 3. 1. 普通external-body(外部主体)参数
  可以和任何"message/external-body(报文/外部主体)"一起使用的参数是:
  (1)ACCESS-TYPE--表示被支持的访问机制的命令,通过它可以获取文件和数据.这个命令
不区分大小写.它的值包括但不限于"FTP", "ANON-FTP", "TFTP", 
"LOCAL-FILE","MAIL-SERVER".
如RFC 2048中描述的,除以"X-"开头的测试值以外,其他值都必须到IANA注册.这个参数不
是无条件的命令,它必须出现在每个"message/external-body(报文/外部主体)"中.
  (2)EXPIRATION--过了这个日期(在RFC822"date-time(日期-时间)中定义,RFC1123中得到
扩充,允许在年字段有4个数字)之后,外部数据的存在将得不到保证.这个参数可以和任何
access-type一起使用,并一直是可选的.
  (3)SIZE --数据大小(八位字节).这个参数的目的是为了帮助接收方决定是否耗费必要的资
源取回外部数据.注意这儿,它描述了数据在标准形式下的大小,标准形式就是在任何
Content-Transfer-Encoding被应用之前,或者数据被解码之后.这个参数可以和任何access-type
一起使用,并一直是可选的.
  (4)PERMISSION --一个不区分大小写的字段,它表明客户试图修改数据是否是可以的.默认
情况下,或者如果permission值"read",前提条件就是他们不允许"read",并且如果数据被重新得
到过一次,它就不在需要了.如果permission值是"read-write",那么前提条件就是无效的,并且
任何本地拷贝必须仅仅被看作一个高速缓冲器. "Read" 和 "Read-write"是唯一被定义的
permission值.这个参数可以和任何access-type一起使用,并一直是可选的.
  这里定义的access-types精确语义将在下面各节中描述.
5. 2. 3. 2  'ftp' and 'tftp' Access-Types(访问类型)
   FTP或者TFTP访问类型表明报文主体可以被作为分别使用 FTP [RFC-959] 或者 TFTP 
[RFC- 783]的文件一样访问.对于这些访问类型来说,以下这些附加参数是强制需要的:
  (1)   NAME -- 包含实际主体数据的文件名.
  (2)   SITE --通过使用给定的协议,文件可以获取的机构.它必须是一个完整的经过资格认
证的域名,而不是一个随便取的绰号.
  (3) 通过使用FTP,任何数据在被重新得到之前,用户通常被要求为通过site参数命名机构提
供登录id和密码.基于安全方面的原因,id和密码不被作为content-type(内容类型)指定,而必须
从用户那里获得.
  另外,以下一些参数是可选的:
  (1)   DIRECTORY -- 通过NAME命名的数据可以被重新得到的目录.
  (2)  MODE --一个不区分大小写的字符串,它表明找回信息时要用到的模式.跟TFTP协议 
[RFC-783]中所说明一样,对于"TFTP"访问类型来说有效的值是"NETASCII", "OCTET"," 
MAIL".
对于 "FTP" 访问类型来说有效的值是"ASCII", "EBCDIC", "IMAGE",和 "LOCALn",其中的
"n"是一个十进制整数,例如8.和FTP协议[RFC-959]中说明的一样,以"A" "E" "I" and "L n"代
表相应的类型.注意,对MODE参数来说,"BINARY" 和"TENEX"是无效,应该以"OCTET"或者 
"IMAGE"或者 "LOCAL8"代替.如果MODE参数没有被详细说明, 对TFT