Mime头信息拓展：Mime-Version、Content-Type、Content-Transfer-Encoding、boundary

前文回顾：Mime头信息（段头&邮件头）

1.Mime-Version
　　表示使用的MIME的版本号，一般是1.0;
     如:
     MIME-Version: 1.0

2.Content-Type
    Content-Type定义了正文的类型，我们实际上是通过这个标识来知道正文内是什么类型的文件。比如：text/plain 表示的是无格式的文本正文，text/html 表示的 Html 文档，image/gif 表示的是 gif 格式的图片等等。Content-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里有很多补充规定，有的允许带几个参数，较为常见的有:
    主类型           参数名           含义
    text            charset         字符集
    image           name            名称
    application     name            名称
    multipart       boundary        边界
   multipart类型
   邮件中常用到的复合类型:multipart。
   multipart类型表示正文是由多个部分组成的，后面的子类型说明的是这些部分之间的关系。

   邮件中用到的三个类型有:
   (1).multipart/alternative：表示正文由两个部分组成，可以选择其中的任意一个。主要作用是在征文同时有text格式和html格式时，可以在两个正文中选择一个来显示，支持 html 格式的邮件客户端软件一般会显示其 HTML 正文，而不支持的则会显示其Text正文；
   (2).multipart/mixed：表示文档的多个部分是混合的，指正文与附件的关系。如果邮件的MIME类型是multipart/mixed，即表示邮件带有附件。
   (3).multipart/related：表示文档的多个部分是相关的，一般用来描述 Html 正文与其相关的图片。
   multipart类型，是MIME邮件的精髓。邮件体被分为多个段，每个段又包含段头和段体两部分，这两部分之间也以空行分隔。它们之间的层次关系可归纳为下图所示：
      +------------------------- multipart/mixed ----------------------------+
      |                                                                       |
      |   +----------------- multipart/related ------------------+             |
      |   |                                                       |             |
      |   |   +----- multipart/alternative ------+   +----------+   |   +------+   |
      |   |   |                                   |   | 内嵌资源   |   |   | 附件 |   |
      |   |   |   +------------+   +------------+   |   +----------+   |   +------+   |
      |   |   |   | 纯文本正文 |   | 超文本正文 |   |                 |              |
      |   |   |   +------------+   +------------+   |   +----------+   |   +------+   |
      |   |   |                                   |   | 内嵌资源   |   |   | 附件 |   |
      |   |   +----------------------------------+   +----------+   |   +------+   |
      |   |                                                       |             |
      |   +------------------------------------------------------+             |
      |                                                                       |
      +----------------------------------------------------------------------+

    可以看出，如果在邮件中要添加附件，必须定义multipart/mixed段；如果存在内嵌资源，至少要定义multipart/related段；如果纯文本与超文本共存，至少要定义multipart/alternative段。什么是“至少”？举个例子说，如果只有纯文本与超文本正文，那么在邮件头中将类型扩大化，定义为multipart/related，甚至multipart/mixed，都是允许的。
    multipart诸类型的共同特征是，在段头指定“boundary”参数字符串，段体内的每个子段以此串定界。所有的子段都以“--”+boundary行开始，父段则以“--”+boundary+“--”行结束。段与段之间也以空行分隔。在邮件体是multipart类型的情况下，邮件体的开始部分(第一个“--” +boundary行之前)可以有一些附加的文本行，相当于注释，解码时应忽略。段间也可以有一些附加的文本行，不会显示出来。
　　这些复合类型又是可以嵌套使用的，比如说一个带有附件的邮件，同时有html与text两种格式的正文，则邮件的结构是：
　　Content-Type: multipart/mixed
　　部分一：
　　Content Type : multipart/alternative：
　　Text 正文；
　　Html 格式的正文　
　　部分二：
　　附件
　　邮件结束符；
　　由于复合类型由多个部分组成，因此，需要一个分隔符来分隔这多个部分，这就是上面的邮件源文件中的boundary所描述的，对于每一个Contect type :multipart/* 的内容，都会有这么一个说明，表示多个部分之间的分隔。
　　含有 MIME/BASE64编码的邮件，你查看它的源码时一般都含有:“This is a multi-part message in MIME format.”这样的句子。也可以被绝大多数的email程序进行解码，包括Netscape、MS Mail、Eudora等。这些程序可以正确识别邮件的正文，恢 MIME/BASE64 编码的部分为正确的文字或夹带的二进制文件。

3.Content-Transfer-Encoding
   它表示了这个部分文档的编码方式。只有识别了这个说明，才能用正确的解码方式实现对其解码。
   Content-Transfer-Encoding共有Base64, Quoted-printable, 7bit, 8bit, Binary等几种。
   其中7bit是缺省的编码方式。电子邮件源码最初设计为全部是可打印的ASCII码的形式。
   非ASCII码的文本或数据要编码成要求的格式。
   Base64, Quoted-Printable是在非英语国家使用最广使的编码方式。
   Binary方式只具有象征意义，而没有任何实用价值。

4.boundary
   这个分隔符是正文中不可能出现的一串古字符的组合，在文档中，以"--"加上这个boundary 来表示一个部分的开始，在文档的结束，以"--"加boundary再在最后加上"--"来表示文档的结束。由于复合类型是可以嵌套使用的，因此，邮件中可能会多个boundary。