邮件MIME详解

邮件MIME报文
MIME是通过标准化电子邮件报文的头部的附加领域而实现的。这些附加领域，描述新的报文类型的内容和组织形式。

MIME版本(MIME-Version)，这个头部领域在邮件消息的报文用一个版本号码来指明消息遵从的MIME规范的版本。目前版本是1.0。
在邮件中格式为：
MIME-Version: 1.0

内容类型(Content-Type)，这个头部领域用于指定消息的类型。一般以下面的形式出现。
Content-Type: [type]/[subtype]; parameter

type有下面的形式。
    * Text：用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的；
    * Multipart：用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的数据；
    * Application：用于传输应用程序数据或者二进制数据；
    * Message：用于包装一个E-mail消息；
    * Image：用于传输静态图片数据；
    * Audio：用于传输音频或者音声数据；
    * Video：用于传输动态影像数据，可以是与音频编辑在一起的视频数据格式。

subtype用于指定type的详细形式。content-type/subtype配对的集合和与此相关的参数，将随着时间而增长。为了确保这些值在一个有序而且公开的状态下开发，MIME使用Internet Assigned Numbers Authority (IANA)作为中心的注册机制来管理这些值。常用的subtype值如下所示：
    * text/plain（纯文本）
    * text/html（HTML文档）
    * application/xhtml+xml（XHTML文档）
    * image/gif（GIF图像）
    * image/jpeg（JPEG图像）
    * image/png（PNG图像）
    * video/mpeg（MPEG动画）
    * application/octet-stream（任意的二进制数据）
    * application/pdf（PDF文档）
    * application/msword （Microsoft Word文件）
    * message/rfc822（RFC 822形式）
    * multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
    * application/x-www-form-urlencoded（使用HTTP的POST方法提交的表单）
    * multipart/form-data（同上，但主要用于表单提交时伴随文件上传的场合）

此外，尚未被接受为正式数据类型的subtype，可以使用x-开始的独立名称（例如application/x-gzip）。vnd-开始的固有名称也可以使用（例：application/vnd.ms-excel）。parameter可以用来指定附加的信息，更多情况下是用于指定text/plain和text/htm等的文字编码方式的charset参数。

 MIME根据type制定了默认的subtype，当客户端不能确定消息的subtype的情况下，消息被看作默认的subtype进行处理。Text默认是text/plain，Application默认是application/octet-stream而Multipart默认情况下被看作 multipart/mixed。


内容传输编码(Content-Transfer-Encoding)，这个区域使指定ASCII以外的字符编码方式成为可能。形式如下：
Content-Transfer-Encoding: [mechanism]
其中，mechanism的值可以指定为“7bit”, “8bit”, “binary”, “quoted-printable”, “base64”。

由于每个ASCII码字符只占用一个字节（8个bit位），且最高bit位总为0，即ASCII码字符中的有真正意义的信息只是后面的7个低bit位，而传统的SMTP协议又是基于ASCII码字符设计的，因此，一些基于传统SMTP协议设计的SMTP服务器在处理邮件内容时只取出每个字节中的7个低 bit位进行处理，而将最高bit位忽略不计。显然，这样的SMTP服务器在处理包含有非ASCII码字符的邮件内容时，会出现严重的问题，这就限制了邮件中只能出现英文的ASCII码字符，而不能出现中文字符或二进制数据。
为了能够在邮件内容中包含中文、图像或声音等非ASCII字符的数据，人们想到了采用某种编码方式将非ASCII字符的数据转换成可打印的ASCII字符后再发送，邮件阅读程序则按照相应的解码方式从邮件中还原出原始数据即可，比较常用的两种邮件编码方式为BASE64和Quoted- printable。后来的扩展SMTP协议允许直接在邮件中传递二进制数据，而不用对它们进行邮件编码，人们将这种没有进行邮件编码的二进制数据的邮件内容称为8bit编码，为了与此相区别，人们将没有进行邮件编码的纯ASCII码字符的邮件称为7bit编码。
7Bit
指消息体内容全部是没有经过编码的ASCII字符。
8Bit
指消息体内容是没有经过编码的原始数据，且其中包含有非ASCII字符的数据。现在的邮件服务器基本上都支持8Bit编码，使用支持8Bit编码的邮件服务器可以简化邮件的处理过程。
BASE64
Base64是将二进制数据转换成可打印的ASCII字符的一种最常见的编码方式，它的基本原理是将一组连续的字节数据按6个bit位进行分组，然后对每组数据用一个ASCII字符来表示。6个bit位最多能表示26＝64个数值，因此可以使用64个ASCII字符来对应这64个数值，这64个ASCII字符为："ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
其中每个字符表示的数值就是该字符在上面的排列中的索引号，索引号从0开始编号。
Quoted-printable
uoted-printable也是一种将二进制数据转换成可打印的ASCII字符的编码方式，它对ASCII字符不进行转换，只对非ASCII字符的数据进行编码转化。每个非ASCII字符的字节数据，都被转换成一个"="号后跟这个字节的十六进制数据，例如，“ab中国”的Quoted- printable编码结果为“ab=d6=d0=b9= fa”。显然，由于"="号在Quoted-printable编码中具有的特殊意义，所以，原始数据中的"="号字符也需要进行编码转换，用“=3d” 表示。
对一大段数据进行 Quoted-printable编码时，可以在编码结果中的适当位置加入回车换行，在回车换行前需要额外再加入一个“=”字符，以表示后面的换行是因编码而造成的软回车，而非原始数据中原有的回车换行。例如，对于下面一段Quoted-printable编码后的数据：
=D5=E2=CA=C7=CD=A8=D0=C5=B5=C4=B3=CC=D0=

=F2, =C7=EB=D6=B8=BD=CC
在第一行末尾的“=”字符和换行，都是由于编码后生成的。
x-encodingname
这个值是预留的扩展。
完整的MIME邮件报文如下
Return-Path: <[e-mail]>
Delivered-To: [e-mail]
Received: by test.mailserver (Postfix, from userid 12346)
    id EAA852E47C0; Wed, 17 Dec 2008 17:25:52 +0800 (CST)
X-FILTER-VIRUS: nofind
Received: from 10.35.60.55 (localhost.localdomain [127.0.0.1])
    by test.mailserver (Postfix) with SMTP id C43EB2E47BD
    for <[e-mail]>; Wed, 17 Dec 2008 17:25:52 +0800 (CST)
From: 1 <[e-mail]>
To: <[e-mail]>
Subject:
Date: Wed, 17 Dec 2008 17:25:52 +0800 (CST)
Message-Id: [e-mail]
Sender: <[e-mail]>
MIME-Version: 1.0
X-Mailer:
X-Priority: 3
Content-Type: multipart/mixed;boundary="=====001_l3453245325====="

--=====001_l3453245325=====
Content-Type: multipart/alternative;boundary="=====003_l3453245325====="

--=====003_l3453245325=====
Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: base64

DQo=


--=====003_l3453245325=====
Content-Type: text/html;charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8Qk9EWSBzdHlsZT0iUEFERElORy1SSUdIVDogNnB4OyBQQURESU5HLUxFRlQ6IDZweDsgRk9O
VC1TSVpFOiAxMnB4OyBQQURESU5HLUJPVFRPTTogNnB4OyBQQURESU5HLVRPUDogNnB4Ij48L0JP
RFk+


--=====003_l3453245325=====--

--=====001_l3453245325=====--