本部分是公共 MIME 头的摘要,可以用作快速参考。它不是 MIME 的明确规范。 在某些情况下,MIME 解析器允许根据标准文档不是严格有效的情况。例如,它不坚持要求具有 MIME 版头。所有标准 MIME 头字段都只需按其在 MIME 文档中的显示写入到逻辑树。MIME 解析器仅记录 Content-Type 头字段的特殊注释。
所有 MIME 头可以包含用圆括号括起来的注释(如 MIME-Version 头示例中所示)。
示例:
MIME-version: 1.0(由 my-application 1.2 生成)
要使 MIME 文档符合 RFC 2045,需要此字段在顶级头中值为 1.0。不能在单独部分指定 MIME-Version。
对于文档,Content-Type 无须符合 RFC 2045,但是 MIME 解析器需要顶级 Content-Type。Content-Type 的缺省值为 text/plains。Content-Type 在每个部分中将数据定义为类型/子类型。MIME 解析器接受大多数 Content-Type 值,并将它们简单存储在逻辑树中。唯一的例外是:
语法:
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-Type 表示为 8 位字符或二进制数据。这其中可以包括 XML,它通常使用 UTF-8 或 UTF-16 编码。这种类型的数据不能在某些传输协议上传送,并可以编码为 7 位。
Content-Transfer-Encoding 头字段用于表示变换类型,这种变换将此种类型数据编码为 7 位格式。
WS-I Basic Profile 仅允许的值是:
7 位、8 位和二进制值都意味着没有编码。可能 MIME conformant 邮件网关会使用此值来控制其如何处理消息。例如,在将其通过 SMTP 路由传递前,将它编码为 7 位。
base64 编码和 quoted-printable 值意味着内容已经编码。quoted-printable 值意味着原文件中只对非 7 位字符编码,仍将生成可读文档。绝大多数情况下,此设置与 Content-Type:text/plain 结合使用。
可选。这使得可以对部分标签,并从消息的其他部分引用该部分。这些部分通常从消息的部分 0(第一个)引用。
可选。这启用部分描述。
下面提供对 base64 和 quoted-printable 编码的基本指南。有关 MIME 编码的明确规范,请参考 RFC 1521。
原始数据被分为 3 个八位元的组。然后每个组被视为 4 个连接的 6 位组,其中每个转换为 base64 字母表中一个数字。基本 64 位(base 64)字母表是A-Z,a-z,0-9 和/ ( A=0 和 /=63)。
如果数据的末端少于 24 位,编码数据将使用“=”字符填充。编码数据中的最大行长度是 76,解码时将忽略换行符(以及其他不属于上述字母表中的字符)。
示例:
Input | Output |
---|---|
一些 base64 编码的数据。 | U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg== |
brian 生存期 | bGlmZSBvZiBicmlhbg==\012 |
what | d2hhdA== |
此编码仅在数据大多数是可打印字符时适用。具体地讲,范围为 33-60 和 62-126 的字符通常由相应的 ASCII 字符表示。控制字符和 8 位数据必须以后跟十六进制数字对的“=”序列来表示。
标准 ASCII 空格 <SP> 和水平制表符 <HT> 表示自身,除非它们在编码行的末端出现(没有软换行符),在这种情况下,必须使用等价的十六进制格式(分别是 =09 和 =20)。
数据中的换行符以 RFC 822 换行符序列 <CR><LF> 表示,并且如果正在编码二进制数据,应编码为“ =0D=0A”。
对于基本 base64 而言,编码数据中的最大行长度是 76 个字符。编码行的末端(“软”换行符)的“=”标记用于告诉解码器该行待续。