RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：阮健（ruanjian rj79@sina.com）
译文发布时间：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序列的片断的数据必须用一种合
适的转换机制进行编码。
4. 1. 2 字符集参数
“text/plain”数据的Content-Type域指定了一个重要的参数－字符集。下面是一个例子：
Content-type: text/plain; charset=iso-8859-1
不像一些其他参数值，字符集参数值是不区分大小写的。默认的字符集是US－ASCII。
“text”未来子类型的规范必须指定是否利用“charset”参数，是否限制它的值。对于“text”
中“text/plain”之外的其他子类型，“charset”参数的语义应该和在“text/plain”定义的一样，
例如，主体完全由给定的字符集中的字符组成。特别的，未来“text”子类型的定义者应该
密切关注多字节字符集的含义。
“text”的子类型的字符集参数给出了字符集的名称，就像RFC 2045中定义的“character
set”一样。前面详细定义的换行规范必须严格遵守，不符合这些规范的字符集不能使用在
MIME“text”子类型中。
最初确定的字符集名称列表可以在这一节最后看到。额外的字符集应当通过IANA注
册。
其他的媒体类型选择采用这里定义的字符集参数，除了CRLF/换行限制。因此，所有遵守
RFC2045中“character set”常规定义的字符集都可以注册供MIME使用。
注意，如果指定的字符集包括8比特字符使用在主体中，为了通过一些邮件传输协议（如
SMTP【RFC821】）传输主体，需要内容/编码转换域和相应的数据编码。
默认的字符集US－ASCII在以前是很混乱和模糊的。不仅在定义中有含糊，而且在应
用中有很多变种。为了消除这种二义性，强烈推荐用户在Content-Type报头域中明确指定
字符集参数。"US-ASCII"不表示一个任意的7比特字符集，但是指定主体中的所有字节必须
根据"US-ASCII"字符集翻译。ISO 646 [ISO-646]面向应用版本通常不同于US－ASCII。字
符集名称“US-ASCII”明确引用定义在ANSI X3.4-1986 [US- ASCII]中的字符集。ISO646
新的国际参考版（IRV）和US-ASCII是一样的。字符集名称“ASCII”保留但禁止用于任何
目的。
注：RFC821明确规定了“ASCII”，并参考了较早的美国标准版。指定媒体类型和字符
集的一个目的是允许接收者毫无二义性的解释数据。假定不是“strict ASCII”作为默认字符
集，将冒改变正在传输的消息语义的危险。这也意味着包含依据ISO其他版本（非US-ASCII
和1991 IRV版）编码的字符的消息必须使用相应的字符集规范来和MIME保持一致。
完整的US-ASCII字符集列在ANSI X3.4- 1986。值得注意的是，除了合成的CRLF代表
换行，包括DEL在内的控制字符没有详细的意义。下面的两个字符在广泛使用中有实际意义：
FF经常表示“在新页的开头开始后续的文本”；TAB或HT经常表示“把光标后移，移动的列
数是8的倍数”。除了这些惯例，任何对控制字符的使用必须是下面两种情形之一：
（1） 由于非“plan”的文本子类型明确分配了一些附加意义，或者
（2） 发送者和接受者之间有一个私人的协定，这种协定是令人泄气的应该用文档中的其
他功能代替。
注：在US-ASCII之外有许多庞大的字符集。大量部分或全部重叠的字符集并不是一件好事
情。可以广泛使用的但是可以表示时间上所有语言的单一的字符集是首选的。不幸的是，几
个委员会还将继续使用多种字符集。因此，在本文当中定义了一小部分标准字符集。
定义的字符集是：
（1） US-ASCII――定义在ANSI X3.4-1986 [US-ASCII]。
（2） ISO-8859-X――ISO646字符集已经被8859代替，8859成为Internet邮件指定的字
符集。本文档出版时，“X”的合理的值是从1到10。
范围在128－159之间的字符在ISO-8859-X中没有指定意义。ISO-8859-X中值在128以下
的字符和它们在US-ASCII中有一样的意思。
ISO8859第六部分（拉丁/阿拉伯字母）和第8部分（拉丁/西伯来字母）包括了从右至
左和从左至右两种字符，但是没有定义一种规范的次序来表示双方向文本。"ISO-8859-6" 和
"ISO-8859-8"字符集指定使用形象的方法【RFC-1556】。
所有这些字符集都是纯7比特或8比特集，没有“shift”和“escape”功能。“shift”和
“escape”序列的含义也没有在这些字符集中定义。
上面定义的字符集在MIME中都是没有争议的。本文档没有认可特殊的非US-ASCII
字符集，并且承认字符集未来的发展是未知的。
注意，使用的任何非US-ASCII字符集必须在Content-Type域中具体指定。
上面定义的字符集之外的、没有正式发行和IANA注册的字符集，或者私人约定的字符集，
这种情况下字符集名称必须以“X－”开始。
实现者不要定义新的字符集除非绝对需要。
“charset”参数主要定义用于文本数据，在这节中进行了描述。但是，有可能非文本数据也
希望指定字符集属性值，这种情况下应该使用相同的句法和属性值。
一般来说，合成软件应该总是使用“最低级的通用命名”字符集。例如，如果一个主体只包
括US-ASCII字符，应该标记成US-ASCII字符集，而不是ISO-8859-1。更普遍的情况，如
果一个字符集是另一个字符集的子集，而主体只包含子集中的字符，那么应该标记那个子集。
这将增加接受方正确看到结果的可能性。
4. 1. 3. Plain(纯文本)子类型
最简单、最重要的“text(文本)”子类型是“plain(纯文本)”。这表明纯文
本不包含任何的命令格式或符号。纯文本是有意被保持原样的显示，就是说，正确
的显示纯文本不需要进行命令格式、字体属性、特殊符号、处理结构、目录或段落
标志的处理。缺省的使用格式“text/plain;charset=us-ascii”常用于因特网实践
中现有的电子邮件。在RFC 822中由关于这个子类型的详细的定义。
在这个文件中并没有其他的文本子类型的定义。
4. 1. 4.Unrecognized（未被承认的）子类型
Unrecognized（未被承认的）子类型被当作“plain”纯文本子类
型，只要MIME知道怎样处理字符集。如果它的字符集是未被承认的，就被当作
“application/octet-stream”处理。
4. 2. Image Media Type（ 图象类型）
“image”（图像）类型的主体部分包含一幅图像，它的子类型命名这幅特殊图像
的格式。这些命名不区分大小写。初始的子类型是JPEG格式的“jpeg”类型，它
使用JFIF编码[JPEG]。
这里列出的“image”图像子类型即不是唯一的，也不是详细的，如果想要了
解更多的在IANA注册过的子类型，可参考RFC 2048。
Unrecognized（未被承认的）图像子类型一般被当作“application/octet
-stream”处理。当它们没有被标注为安全而只是普通的图像浏览应用时，执行器
可能随意的选择可用的图像子类型代替，如果那个子类型可用的话。
注意：用这种方法把应用程序支持的大部分的危险的图像子类型处理成普通目的
图像浏览应用可能会遗留下来一些安全性问题。
4. 3. Audio Media Type（音频类型）
"audio"（音频）类型的主体部分包含音频数据。虽然目前还没有一致的理想的
音频格式用于电脑，但有一些压缩格式能提供共同操作的能力。[Page 11]
最初的子类型"basic"（基本的）通过提供一个绝对的最小公分母音频格式
满足这种需要。在以后的文件中可能定义更丰富的格式，它具有更高品质和更低
带宽的音频。
"audio/basic" 子类型采用单道8bit ISDN mu-law[PCM]编码，采样频率为8000
Hz.
未被承认的音频子类型有时被当作"application/octet-stream"类型处理。执行
器可能随意的选择一个可用的音频子类型，选择的这个子类型不是确定的一个，可有
多个选择，来满足应用程序的多方面的需要，只要该应用是可行的。
4. 4. Video Media Type（视频类型）
"video"（视频）类型的主体部分是一个随时间变化的运动图像，可能带有颜色和
同步的声音。术语"video"（视频）这里是从最一般的角度来说的，而不是特指某一个
技术或格式。也不排除动态图像编码。"mpeg"子类型指的是一种用MPEG标准编码的视频
类型。
应该注意虽然这个文档不提倡在单一的主体部分有多种媒体类型的混合，事实
上已经有许多所谓的有同步描述的视频格式， "video"（视频）类型支持这种格式。
未被承认的视频子类型有时被当作"application/octet-stream"类型处理。执行
器可能随意的选择一个可用的视频子类型，选择的这个子类型不是确定的一个，可有
多个选择，来满足应用程序的多方面的需要，只要该应用是可行的。
4. 5. Application Media Type（ 应用类型）
"application"（应用）类型用于不连续的、离散的数据，这些数据不适合其他的
类型，但作为一种数据必须被应用程序处理。这种信息必须被应用程序在用户看见和
使用前处理。 "application"（应用）类型的其他的用途包括文件传输、电子数据表、
有时序的电子邮件数据和计算语法。（后者，特别地，能引起安全性问题，故被实现
者重视，在"application/PostScript"类型中有关这方面详细的讨论。） [Page 12]
例如，一个会议的时间安排可能定义一个标准的关于被提议的会议日期信息的
描述，一个聪明的用户代理会使用这些信息管理一个用户的对话，然后可能发送关于
那个对话的额外的材料，更一般地，已经开发出几个活性的消息语言，它们可用来编
写一些特殊的程序被发送到一个远程接口位置并且自动地在接受者环境中运行。
那样的程序可能被定义为"application"类型。这个文档定义了两个子类型：
octet-stream,（8bit流） and PostScript（标记）.
"application"（应用）的子类型不是应用的名字和它的一部分名字，在这个应用中
数据是已定义的。这不是意味着，然而，任何一个应用程序的名字会作为一个
"application"的子类型。
4. 5. 1. Octet-Stream Subtype（8bit子节流子类型）
Octet-Stream（8bit子节流）子类型的主体部分包括任意的二进制数据。当前的设置
的参数定义为:
(1)PYTE--普通的类型或二进制数据。这是有意作为人类可接受的信息形式而不是其他
的任何一个机械的处理。
（2）PADDING--由二进制流组成的填补的比特数量是根据实际的内容产生附加的的8bit
子节数据。这在当总的比特数不是8的倍数时是有用的。
这两个是可选的。
另外的参数，"CONVERSIONS"，在RFC 1341 中定义，但是已经不用了。RFC 1431也定
义了"NAME"参数的用法。它表示一个用来写数据的文件的文件名。在后来的RFC文档中反对
在分开的内容中使用该头域。
推荐的为一个执行接收"application/octet-stream"的实体的使用方法是简单的把数据
放到一个文件中，如使用Content-Transfer-Encoding（内容传输编码），或使用它作为一
个用户定义的进程的输入。 [Page 13]
为了减少传输抵赖，它强烈建议执行中不用机械地路径搜索，在那里武断地命名一个程
序的参数作为输入。
扫一扫
429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
