rfcrfc2046.txt

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

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：阮健（ruanjian   [e-mail]）
译文发布时间：2001-12-9
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



Network Working Group                                          N. Freed
Request for Comments: 2046                                     Innosoft
Obsoletes: 1521, 1522, 1590                               N. Borenstein
Category: Standards Track                                 First Virtual
                                                          November 1996
MIME第二部分:媒体类型
(RFC2046——Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types)

本备忘录的状态
本文档描述了用于Internet交流的Internet标准路径协议的规范,还需要讨论和建议来改
进. 请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
摘要
STD11,RFC 882定义了一种信息表示协议,该协议规定了US-ASCII格式信息头的详细细
节,但是信息内容或者信息体仍是flat US-ASCII text.本文档和其他一系列文档一起称为
MIME,重新定义了允许的信息格式.
(1) 非US-ASCII的字符集的文本报文主体
(2)非文本报文主体的不同格式的扩展集
(3)多部分报文主体
(4)除了US-ASCII的字符集的文本报头信息
这一整套文档基于更早的文档RFC934和RFC1049,但对它们进行了扩展和修正.由于
RFC822对报文主体涉及太少,所以这些文档大多数和RFC822是没有关系的.
RFC2045是这套文档中的最初的文档,它规定了用于描述MIME消息结构的多种报头.
第二个文档定义了MIME媒体类型系统的总体结构并且定义了媒体类型的初始集.第三个文
档是RFC2047,它扩展了RFC822,允许在Internet邮件头域中有非US-ASCII文本.第四个文档
RFC2048说明了与MIME相关设备的多种注册程序.第五个也是最后一个文档RFC2049描述了
MIME一致性标准,同时提供了一些关于ＭＩＭＥ消息格式的说明性的例子,还有感谢和参考
数目.
这些文档都是RFC1521和RFC1522的修正版,RFC1521和1522又是RFC1341和1342
的修订版.在RFC2049中的附录描述了和以前版本的不同和变化.


目录
1. 介绍	3
2．顶层媒体类型的定义	3
3．初始顶层媒体类型的概述	3
4．离散的媒体类型值	4
4. 1 文本（Text）媒体类型	4
4. 1. 1 换行的表示	5
4. 1. 2 字符集参数	5
4. 1. 3.  Plain(纯文本)子类型	7
4. 1. 4.Unrecognized（未被承认的）子类型	7
4.  2.  Image Media Type（ 图象类型）	7
4.  3.  Audio Media Type（音频类型）	7
4.  4.  Video Media Type（视频类型）	8
4.  5.  Application Media Type（ 应用类型）	8
4. 5. 1. Octet-Stream Subtype（8bit子节流子类型）	8
4. 5. 2. PostScript Subtype（标注类型）	9
4. 5. 3. 其它application的子类型	10
5.  Composite Media Type Values（复合类型值）	10
5. 1.  Multipart Media Type（多部分类型）	10
5. 1. 1.Common Syntax（共同语法）	11
5. 1. 2处理嵌套的报文和multiparts（多部分）	14
5. 1. 3 Mixed子类型	15
5. 1. 4 alternative子类型	15
5. 1. 5 Digest子类型	16
5. 1. 6.  Parallel 子类型	17
5. 1. 7其他的Multipart子类型	18
5.  2. 报文媒体类型	18
5. 2. 1  RFC 822子类型	18
5. 2. 2  Partial子类型	18
5. 2. 2. 1报文分段和重组	19
5. 2. 2. 2  分割和重组实例	20
5. 2. 3  External-Body(外部主体)子类型	21
5. 2. 3. 1. 普通external-body(外部主体)参数	22
5. 2. 3. 2  'ftp' and 'tftp' Access-Types(访问类型)	22
5. 2. 3. 3  'anon(匿名)-ftp'访问类型	23
5. 2. 3. 4  'local-file(本地文件)'访问类型	23
5. 2. 3. 5  'mail-server(邮件服务)'访问类型	23
5. 2. 3. 6  External-body(外部主体)安全问题	24
5. 2. 3. 7  实例与深入说明	24
5. 2. 4 其他message(报文)子类型	26
7. 总结	26
8. 安全性考虑	26
9. 作者地址	26
附录A：语法集	27

1. 介绍
在这套文档的第一个文档RFC2045中,定义了许多报头域,包括
Content-Type.Content-Type域用来指定一个MIME实体中主体的数据类型,给出它的媒体类
型和子类型,并提供特定的媒体类型可能需要的辅助信息.报文头的余下部分只是一个参数
集,指定了一个属性/属性值符号.参数的次序是不重要的.
一般来说,顶层(top-level)媒体类型用来声明数据总的类型,而子类型指定了这一类型
的格式.因此,一个媒体类型“image/xyz"足以告诉用户数据是一幅图象,即使用户没有关于
特定的图象格式“xyz"的知识.例如,这些信息可以用来决定是否给用户看不被承认子类型
的原始数据—这个动作对于“text"的未被承认（unrecognized）的子类型可能是合理的，
但对于“image”或“audio"的未被承认(unrecognized)的子类型是不合理的。由于这个原
因，"text", "image", "audio", 和 "video"的注册子类型不应该包含其他类型的信息。这
种混合的格式应该使用"multipart"或"application"类型来表示。
参数是媒体子类型的修饰部分，不会从本质上影响内容的种类。这组有意义的参数依赖
于媒体类型和子类型。大多数参数和一种特定的子类型相关联。但是，一种给定的顶层媒体
类型可能定义一些参数，这些参数适用于这一类型的所有子类型。参数可能是定义的媒体类
型或子类型必选的，也可能是可选择的。MIME实现还必须忽略名字不被承认的所有参数。
MIME的Content-Type报头域和媒体类型机制可以很好的扩展，我们希望媒体类型/子
类型对和他们相关联参数集合可以随着时间显著增长。MIME的一些其他功能，如转换代码
和"message/external-body"访问类型随着时间发展很可能定义新的值，为了确保这套属性
值的发展有序，规范，风格一致，MIME建立了一个登记程序，他使用IANA（Internet Assigned 
Numbers Authority）作为MIME各个方面扩展的中心登记处。这个登记程序在RFC2048中进
行了描述。
本文档的余下部分将定义和描述最初的七个标准顶层媒体类型。
2．顶层媒体类型的定义
顶层媒体类型的定义包括：
（1）	类型名字和描述，包括这一类型下是否某一特定类型被限制的标准
（2）	参数名字和定义，这些参数为这一类型的所有子类型所定义（包括这些参数是否是
必需的还是可选的）
（3）	用户或网关如何处理这一类型的未知子类型
（4）	这一顶层类型的网关实体的总体考虑
（5）	这一顶层类型实体内容和编码转换（content-transfer-encodings）的所有限制
3．初始顶层媒体类型的概述
五种离散的顶层媒体类型是：
（1）	text—文本信息。特别地，子类型“plain”表示包含各种无格式命令和指令的纯文本。
纯文本显示出来是“as-is”。不需要专门的软件来获取文本的完整意思，对表示字符
集的支持除外。其他的子类型用来在形式上丰富文本，应用软件可以提升文本的外
观，但不需要为了获得内容的大体意思而使用这些软件。因此，可能“text”的子类
型包括任何可读的文字处理格式，而不需软件来理解信息。特殊的，使用内含二进
制格式信息的格式不被认为直接可读。一种非常简单和便携的子类型“richtext”在
RFC1341中有定义，更进一步的版本“enriched”在RFC1896中定义。
（2）	image—图象数据。“image”需要一个显示设备（如一台显示器，一台图形打印机，
或者一台传真机）来表现信息。初始的子类型定义为一种广泛使用图象格式JPEG。
这些子类型定义为两种广泛使用的图象格式jpeg和gif。
（3）	audio—音频数据。“Audio”需要一个音频输出设备（如一个扬声器或电话）来“显
示”内容。在这个文档里定义了初始的子类型“basic".
（4）	Video—视频数据。“Video”显示动态图象的能力，典型的包括专门的硬件和软件。
在这个文档里定义了初始的子类型“mpeg”。
（5）	Application—其他种类的数据，典型的是无法解释的二进制数据和需要应用程序处
理的信息。子类型“octet-stream”适用于无法解释的二进制数据场合，这种场合下
最简单的推荐动作是为用户把信息写到一个文件中。“PostScript”子类型适用于附言
材料。其他预想的子类型用于“应用”包括电子数据表格，基于邮件的时序系统数
据，“活性”（可计算的）消息语言，以及不能直接可读的文字处理格式。注意，一
些应用数据的类型可能存在安全性考虑，最显著的是“application/PostScript”和任
何形式的活性消息。稍后我们将讨论这些话题。
两种合成的顶层媒体类型是：
（1）	multipart—由多个独立的数据类型实体组成的数据。最初定义了四个子类型，包括
基本的“mixed”子类型―指定了各个部分的一般的混合集，“alternative”表示在多
重格式中的相同数据，“parallel”用于期望各个部分同时看到，“digest”用于多部分
实体，其中每个部分有一个默认的类型“message/rfc822”。
（2）	message—一种压缩的消息。媒体类型“message”的主体是它自己全部或者消息对
象一些种类的局部。这些对象不会反过来包含其他实体。当压缩的内容本身是
RFC822消息时使用“rfc822”子类型。“partial”定义针对部分RFC822消息，允许
太大的消息主体分段传输。另一个子类型“external-body”通过引用一个外部的数据
源来指定大的主体。
注意的是，上面列出的媒体类型值可能会扩张，通过扩张，子类型集合不断增长。
4．离散的媒体类型值
七个最初的媒体类型值中的五个是关于离散的主体。这些类型的内容一定可以用非MIME
机制解决。它们对MIME处理器是不透明的。
4. 1 文本（Text）媒体类型
“text”媒体类型的意图是发送主要是文本格式的数据。“charset”参数用来指出“text”
子类型的主体文本的字符集，典型的包括“text/plain”子类型，这是最普通的纯文本子类型。
纯文本不提供也不允许格式化命令，字体属性规范，处理指令，解释指令，或内容标记。纯
文本只被看作是字符的线性序列，可能仅仅被换行或换页打断。纯文本可能允许在文本中相
同位置上一些字符的堆叠。纯文本手稿就像阿拉伯语或西伯来语可能包括这样的特性，那就
是允许任意组合文本片断，甚至是相反的写字方向。
在纯文本之上，还有很多格式来表示“rich text”。许多这种表示的一个有趣的特征是它们不
需要解释软件就可以达到一定的可读性。在最高层上，有必要把它们和不可读的数据区别开
来，如图象，视频或以不可读形式表示的文本。在缺少适当的解释软件时，格式化的文本数
据应该以子类型“text”的形式展现给用户，对于大多数非文本数据是不合适的。
4. 1. 1 换行的表示
任何MIME“text”子类型的规范格式必须把换行表示成一个CRLF序列。同样地,在
MIME“text”中碰到CRLF就代表一个换行。在换行序列之外使用CR和LF是禁止的。
这条规则使用于所有情况，不管格式或者字符集。
注意：当主体依靠媒体类型来显示时换行要有适当的解释。特别的，当显示一个
“text/plain”主体时可以把换行看作是到新行的过渡，但是不适用于“text”的子类型
“text/enriched”【RFC－1896】。同样地，在显示时是否加入换行是媒体类型的一个功能。
没有必要加入所有的换行来正确显示“text/plain”，然而“text/plain”也需要适当加入换行。
注意：一些协议定义了一行的最大长度。例如，SMTP【RFC－821】允许一行最多998
个字节。使用这种协议传输的时候，包括很长的没有CRLF序列的片断的数据必须用一种合