当前位置：首页 > MIME协议详解
MIME协议分析
第1章 MIME概述
MIME, 全称为“Multipurpose Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。它是当前广泛应用的一种电子邮件技术规范，基本内容定义于RFC 2045-2049（注意RFC1521和RFC1522是它的过时版本）。
MIME试图在不改变SMTP协议和RFC822（邮件格式标准）的基础上，使得邮件可以传送任意二进制文件。为此，它在这些协议之上，采取了一些措施，这就是我们下面所要重点讲述的内容。
第2章 MIME详解 2.1 改进措施
一封邮件包括信封、邮件头和邮件体等三个部分。信封显然可以不含有二进制信息，而其它两部分则可能包含任意二进制序列，因此需要加以改进。MIME正是抓住了这两个地方来对他们加以改进。
1)新增了一些邮件头信息，用来协商MIME的一些参数。
2)定义了许多邮件内容的格式，对多媒体电子邮件的表示方法进行了标准化。 3)定义了传送编码，从而可以传送任意二进制文件。
在这里，我还是要不厌其烦地强调指出，所有的改进措施都是建立在不改变原来的SMTP协议和RFC822的基础上的。事实上，我们可以把这些改进措施，看成是在用SMTP等发送邮件前所采取的预处理。
2.2 一封简单邮件的源码
为了对MIME邮件有个直观的了解，先给出一封简单邮件的源码。源码中，行号和行号后的空格是为了分析方便而另外加的，“... ... ... ...”表示此处省略了大段编码。 1 From: \ 2 Reply-To: bhw98@sina.com 3 To:
2.3 邮件头 2.3.1邮件头的域
邮件头包含了发件人、收件人、主题、时间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域，由域名后加“: ”和信息内容构成，可以是一行，较长的也可以占用多行。域的首行必须“顶头”写，即左边不能有空白字符（空格和制表符）；续行则必须以空白字符打头，且第一个空白字符不是信息本身固有的，解码时要过滤掉。如例2的7-8行分别属于一个域。
表 1中给出了邮件头中常见的域，域的含义，和域值的添加者。
域名 Received Return-Path 含义 传输路径 回复地址 添加者 各级邮件服务器 目标邮件服务器 Delivered-To Reply-To From To Cc Bcc Date Subject Message-ID MIME-Version Content-Type Content-Transfer-Encoding 发送地址 回复地址 发件人地址 收件人地址 抄送地址 暗送地址 日期和时间 主题 消息ID MIME版本 内容的类型 内容的传输编码方式 目标邮件服务器 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 邮件的创建者 表 1 邮件头中常见的域 非标准的、自定义域名都以X-开头，例如X-Mailer, X-MSMail-Priority等，通常在接收和发送邮件的是同一程序时才能理解它们的意义。除了后面两个域外，其他的域的意思很明了，所以下面只对后两个域做解释。
2.3.2 Content-Type域
Content-Type域，即内容类型域，它用来说明传输的内容的类型。Cotent-Type域又由“主类型/子类型”构成，主类型有text, image, audio, video, application, multipart, message等，分别表示文本、图片、音频、视频、应用、分段、消息等。每个主类型都可能有多个子类型，如text类型就包含plain, html, xml, css等子类型。以X-开头的主类型和子类型，同样表示自定义的类型，未向IANA正式注册，但大多已经约定成俗了。如application/x-zip-compressed是ZIP文件类型。在Windows中，注册表的“HKEY_CLASSES_ROOT/MIME/Database/Content Type”内列举了除multipart之外大部分已知的Content-Type。
各种各种类型一般都可以带参数。至于参数的形式，RFC里有很多补充规定，有的允许带几个参数，较为常见的如表 2所示 主类型 text image application multipart 参数名 charset name name boundary 含义 字符集 名称 名称 边界 表 2 常见类型的参数
2.3.3 Content-Transfer-Encoding域
Content-Transfer-Encoding域即传送编码域，它用来说明后面传输的内容的编码方式。
Content-Transfer-Encoding共有Base64, Quoted-printable, 7bit, 8bit, Binary等几种。其中7bit是缺省的编码方式。电子邮件源码最初设计为全部是可打印的ASCII码的形式。非ASCII码的文本或数据要编码成要求的格式，如上面的三个例子。Base64, Quoted-Printable是在非英语国家使用最广使的编码方式。Binary方式只具有象征意义，而没有任何实用价值。关于Base64编码和Quoted-Printable编码请参考RFC文档或另外一篇文章《SMTP协议分析》。
近年来，国内多数邮件服务器已经支持8bit方式，因此只在国内传输的邮件，特别是在邮件头中，可直接使用8bit编码，对汉字不做处理。如果邮件要出国，还是老老实实地按Base64或Quoted-printable编码才行
2.4 邮件体
邮件体的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本)。
源码中出现的multipart类型，是MIME邮件的精髓。邮件体被分为多个段，每个段又包含段头和段体两部分，这两部分之间也以空行分隔。常见的multipart类型有三种：multipart/mixed, multipart/related和multipart/alternative。从它们的名称，不难推知这些类型各自的含义和用处。它们之间的层次关系可归纳为图 1所示
+------------------------- multipart/mixed ----------------------+
| +----------------- multipart/related -------------+ |
| | | | | | | | | | +----multipart/alternative ---+ +----------+ | +------+ | | | | | | 内嵌资源 | | | 附件 | | | | | +-----------+ +----------+ | +----------+ | +------+ | | | | | 纯文本正文| |超文本正文| | | | | | | +-----------+ +----------+ | +----------+ | +------+ | | | | | | 内嵌资源 | | | 附件 | | | | +-----------------------------+ +----------+ | +------+ |
| | |
| | +-------------------------------------------------+
本文作者：...共分享92篇相关文档
