转载:http://blog.sina.com.cn/s/blog_759444350100vx8u.html
MIME邮件格式
在RFC 2822文档中定义了简单的 ASCII编码的Email的邮件格式,然而随着Internet的发展,Email邮件仅仅传输简单的文本已经满足不了用户的需求,为了在Email 中传输大量HTML、图像、声音以及各种附件格式,一种新的扩展的邮件格式应运而生——MIME。由于在MIME邮件格式非常复杂,大量的RFC文档中对 MIME邮件格式进行了定义与说明,比如RFC2045, RFC2046, RFC2047, RFC2049, RFC2231, RFC2387, RFC4288, RFC4289等。因此,MIME邮件格式为我们提供了极大的灵活性的同时也给我们解读MIME格式的Email邮件带来了极大的困难。以下就一封具体的邮件原始信息对MIME邮件格式作出一个概要的介绍。
解释几个常用且不易理解的Content-Type开头的MIME首部:
Received: from JSJ104 (unknown [202.204.96.147])
Message-ID:< 000601c7114a$2fd50450$9360ccca@JSJ104>
From: <ctp_41023@163.com>
To: <ctp_41023@163.com>
Subject: =?gb2312?B?MTIzMTIzxOO6wzEyMzEyMw==?=
Date: Sun, 26 Nov 2006 19:01:04 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
This is a multi-part message in MIME format.
------=_NextPart_000_0003_01C7118D.38E01920
Content-Type: text/plain;
Content-Transfer-Encoding: base64
MTIzMTIzMTIz
------=_NextPart_000_0003_01C7118D.38E01920
Content-Type: text/html;
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVC
L0VOIj4NCjxIVE1MPjxIRUFE
dD0idGV4dC9odG1sOyBjaGFy
MC4yOTAwLjI5OTUiIG5hbWU9
Qk9EWSBiZ0NvbG9yPSNmZmZm
PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==
------=_NextPart_000_0003_01C7118D.38E01920--
这封Email具有一个邮件首部,然后是邮件的主体部分,它包括一个文本和一个HTML类型。可以注意到这样一行编码 “boundary="----=_NextPart_000_0003_01C7118D.38E01920" ”,它是用来隔离MIME邮件的各个实体部分。
在RFC2822中定义了MIME邮件首部的格式:
field-name ":" [ field-body ] CRLF
例如:
MIME-Version: 1.0
Content-Type: multipart/alternative;
Content-Type: text/plain;
Content-Transfer-Encoding: base64
最常见也用途最都的MIME首部是以Content-Type开头的,在RFC2046给出了它的定义,大致与如下内容相似:
Content-Type: text/plain;
Content-Type: text/plain; charset=ISO-8859-1
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=utf-8
Content-Type: text/html;
Content-Type: text/html; charset=ISO-8859-1
Content-Type: text/css
Content-Type: image/gif; name=image004.gif
Content-Type: image/jpeg; name="image005.jpg"
Content-Type: message/delivery-status
Content-Type: message/rfc822
Content-Type: audio/x-mpeg
Content-Type: video/mpeg-2
Content-Type: application/msword
Content-Type: application/mspowerpoint
Content-Type: application/zip
Content-Type: multipart/mixed;
Content-Type: multipart/alternative; boundary="----=_Part_4088_29304219.1115463798628"
Content-Type: multipart/related;
Content-Type: multipart/digest;
Content-Type: multipart/report; report-type=delivery-status;
Content-Type: multipart/parallel
1) Content-Type: multipart/mixed
它表明这封Email邮件中包含各种格式的MIME实体但没有具体给出每个实体的类型。
2) Content-Type: multipart/alternative
如果同一封Email邮件既以文本格式又以HTML格式发送,那么要使用Content-Type: multipart/alternative。这两种邮件格式实际上是显示同样的内容但是具有不同的编码。
3) Content-Type: multipart/related
用于在同一封邮件中发送HTML文本和图像或者是其他类似类型。
邮件主体的编码:
主要是包括quoted-printable与base64两种类型的编码。Base64和Quoted-Printable都属于MIME(多用途部分、多媒体电子邮件和 WWW 超文本)的一种编码标准,用于传送诸如图形、声音和传真等非文本数据)。
一.Base64
Base64是现今在互联网上应用最多的一种编码,绝大多数的电子邮件软件头把它作为默认的二进制编码,比如我们常用的Outlook。
Base64内容传输编码被设计用于以人无法可读的方式来表述八位组的任意序列。编码与解码算法很简单,但是编码数据总是比非编码数据长33%。这种编码实际上类似于RFC1421中定义的在增强保密邮件(PEM)应用程序中使用的编码方式。
编码程序将字符流顺序放入一个 24 位的缓冲区,缺字符的地方补零。从左到右,一个24位输入组通过级联3个八位输入组组成。随后这24位截断成为 4 个部分,每个部分 6 位,分别被翻译为base64字母表中的一个单独数字。当通过Base64编码一个位流时,位流必须假设为以最高有效位优先的顺序排列。也就是说,流中的第一位将是第一字节中的高端位,而第八位则位第一字节中的低端字节位。
如果输入数据不足24个字符,即只有一个或两个字节时,则需要经过特殊处理——在数据末尾填充"="字符,这可以隔断附加的信息造成编码的混乱。
在Base64编码数据中,任何在Base64字母表之外的字符将被忽略。Base64编码中的非法字符序列也将被忽略,例如"=====".
二.Quoted-Printable