MIME 标准头字段

本部分是公共 MIME 头的摘要,可以用作快速参考。它不是 MIME 的明确规范。 在某些情况下,MIME 解析器允许根据标准文档不是严格有效的情况。例如,它不坚持要求具有 MIME 版头。所有标准 MIME 头字段都只需按其在 MIME 文档中的显示写入到逻辑树。MIME 解析器仅记录 Content-Type 头字段的特殊注释。

所有 MIME 头可以包含用圆括号括起来的注释(如 MIME-Version 头示例中所示)。

MIME 头字段

MIME-Version

示例:

MIME-version: 1.0(由 my-application 1.2 生成)

要使 MIME 文档符合 RFC 2045,需要此字段在顶级头中值为 1.0。不能在单独部分指定 MIME-Version。

Content-Type

对于文档,Content-Type 无须符合 RFC 2045,但是 MIME 解析器需要顶级 Content-Type。Content-Type 的缺省值为 text/plains。Content-Type 在每个部分中将数据定义为类型/子类型。MIME 解析器接受大多数 Content-Type 值,并将它们简单存储在逻辑树中。唯一的例外是:

  • MIME 解析器拒绝任何“类型 = 消息”的 Content-Type 值
  • MIME 解析器假定“类型 = 多段式”的 Content-Type 值引入多段式 MIME 文档,并拒绝不包含有效边界参数的值。边界参数的值定义多段式消息中的消息部分之间的分隔符。在嵌套的多段式消息中,对于每个嵌套级别,需要唯一的边界值。

语法:

Content-Type:类型/子类型;参数

其中类型和子类型定义 Content-Type 和任何由分号分隔的可选参数。

示例 1:

Content-Type: multipart/related;type=text/xml

在示例 1 中,Content-Type 被定义为 multipart/related,并且具有可选的参数定义(type=text/xml)。虽然这在语句构成上是正确的,但是因为没有有效的边界参数,此消息将被拒绝。

示例 2:

Content-Type: multipart/related;boundary=Boundary;type=text/xml 

示例 2 显示一个在语法和语义上都有效的 Content-Type 定义。边界值可以用引号括起来(可选)。当它显示在 MIME 主体中时,值以序列“--”开始,并且必须注意生成的值(在此例中为 Boundary)不能显示在消息主体中。如果消息数据编码为 quoted-printable,则应该具有包含序列(如 “=_”)的边界(不能显示在 quoted-printable 主体中)。

某些公共 Content-Type 值如下所示。允许任何其他值并将它们简单存储在逻辑树中。

Content-Type 描述
text/plain 通常用于典型的邮件和新闻消息。text/richtext 也是公共的。
text/xml 通常与 SwA(带附件的 SOAP)一起使用
application/octet-stream 当消息是未知类型和包含任何字节数据时使用。
application/xml 用于应用程序特定 xml 数据
x-type 用于非标准内容类型。它必须以 x- 开始
image/jpeg 用于图像。image/jpeg 和 image/gif 是使用的公共图像格式
multipart/related 用于消息中多个相关部分。具体地讲,与 SwA(具有附件的 SOAP)一起使用。
multipart/signed 用于消息中多个相关部分(包括签名)。具体的讲,与 S/MIME 一起使用
multipart/mixed 用于消息中多个独立部分。
Content-Transfer-Encoding

可选。很多 Content-Type 表示为 8 位字符或二进制数据。这其中可以包括 XML,它通常使用 UTF-8 或 UTF-16 编码。这种类型的数据不能在某些传输协议上传送,并可以编码为 7 位。

Content-Transfer-Encoding 头字段用于表示变换类型,这种变换将此种类型数据编码为 7 位格式。

WS-I Basic Profile 仅允许的值是:

  • 7 位 - 缺省值
  • 8 位
  • binary
  • base64
  • quoted-printable

7 位、8 位和二进制值都意味着没有编码。可能 MIME conformant 邮件网关会使用此值来控制其如何处理消息。例如,在将其通过 SMTP 路由传递前,将它编码为 7 位。

base64 编码和 quoted-printable 值意味着内容已经编码。quoted-printable 值意味着原文件中只对非 7 位字符编码,仍将生成可读文档。绝大多数情况下,此设置与 Content-Type:text/plain 结合使用。

内容标识

可选。这使得可以对部分标签,并从消息的其他部分引用该部分。这些部分通常从消息的部分 0(第一个)引用。

内容描述

可选。这启用部分描述。

MIME 编码

下面提供对 base64 和 quoted-printable 编码的基本指南。有关 MIME 编码的明确规范,请参考 RFC 1521。

base64

原始数据被分为 3 个八位元的组。然后每个组被视为 4 个连接的 6 位组,其中每个转换为 base64 字母表中一个数字。基本 64 位(base 64)字母表是A-Z,a-z,0-9 和/ ( A=0 和 /=63)。

图 1. 基本 64 位(base 64)数据变换8 位数据如何分为 6 位编码的数据。

如果数据的末端少于 24 位,编码数据将使用“=”字符填充。编码数据中的最大行长度是 76,解码时将忽略换行符(以及其他不属于上述字母表中的字符)。

示例:

Input Output
一些 base64 编码的数据。 U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
brian 生存期 bGlmZSBvZiBicmlhbg==\012
what d2hhdA==
quoted-printable

此编码仅在数据大多数是可打印字符时适用。具体地讲,范围为 33-60 和 62-126 的字符通常由相应的 ASCII 字符表示。控制字符和 8 位数据必须以后跟十六进制数字对的“=”序列来表示。

标准 ASCII 空格 <SP> 和水平制表符 <HT> 表示自身,除非它们在编码行的末端出现(没有软换行符),在这种情况下,必须使用等价的十六进制格式(分别是 =09 和 =20)。

数据中的换行符以 RFC 822 换行符序列 <CR><LF> 表示,并且如果正在编码二进制数据,应编码为“ =0D=0A”。

对于基本 base64 而言,编码数据中的最大行长度是 76 个字符。编码行的末端(“软”换行符)的“=”标记用于告诉解码器该行待续。

相关概念
消息建模
消息模型
相关任务
开发消息模型
使用消息模型对象
相关参考
消息模型引用信息
消息模型对象属性
附加的 MRM 域信息
MIME 域的其他信息
相关信息
RFC 1521: MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
RFC 822:ARPA 因特网文本消息的格式标准
声明 | 商标 | 下载 | 书库 | 支持 | 反馈
Copyright IBM Corporation 1999, 2006 最后一次更新时间:2006/08/14
ad30590_