简介
无规矩不成方圆，无规范不成网络通信。正是在各种网络协议和规范的根底之上，才构建了咱们当初风行的互联网。明天给大家介绍的就是一个网络规范格局，叫做 MIME，它的全称是 Multipurpose Internet Mail Extensions, 翻译过去就是多用途 Internet 邮件扩大。
那么有小伙伴开始纳闷了，原来是一个邮件的扩大协定，那么它跟咱们应用的 Internet 网络有什么关系呢？
不急，咱们缓缓道来。
MIME 详解
在很久很久以前，计算机的一种风行的利用就是发邮件，最开始的时候，计算机世界的编码方式就只有 ASCII 一种，然而随着工夫的推移和各种利用需要的激增，ASCII 格局曾经不能满足咱们的需要了，格局多类型的同时也照成了相互通信之间的艰难，于是一个对立的音讯格局规范产生了，这个就是 MIME。
MIME 能够让邮件不仅反对 ASCII，还能够反对其余的编码方式。同时反对图片、音频、视频和应用程序等多种附件。
音讯体还能够反对多个 part 的汇合，当这样的音讯邮件应用 MIME 格局编码之后，就能够通过规范的邮件协定，比方 SMTP、POP、IMAP 等进行发送了。
因为 MIME 是一个规范，所以只有合乎这种规范的邮件都可能被解析胜利。
很快，MIME 就在邮件世界被广泛应用，然而互联网曾经倒退到应用风行的 HTTP 协定来拜访万维网的时候了，MIME 中定义的各种 content types 很天然的也成了其余协定中应用的 content 规范。
这种 content types 是在 MIME 头中定义的，应用程序接管到 content type 之后，会依据类型中指定的音讯类型，来采纳对应的应用程序对音讯内容进行解析。
MIME 头
MIME 头很重要，是应用程序用来判断音讯格局的首要根据。MIME 头能够蕴含上面的字段。
MIME-Version
如果存在这个音讯头，阐明这个音讯是遵循的是 MIME 格局。它的值通常是 1.0。
MIME-Version: 1.0有仔细的小伙伴能够能要问了，既然有 1.0，那么有没有 1.1 或者 2.0 呢？
很道歉，答案是没有。因为依据 MIME 独特创建者 Nathaniel Borenstein 的说法，尽管引入 MIME 版本号是为了在后续中对 MIME 进行批改和降级。然而因为 MIME 标准并没有为将来 MIME 版本的降级进行良好的设计，所以不同的人可能对 MIME 版本升级后的解决形式都是不一样的。从而导致在 MIME 广泛应用的明天，很难对 MIME 标准进行降级。
所以，就应用 1.0 吧。
Content-Type
如果属性 HTTP 协定的同学，对这个头应该很相熟了吧，这个头示意的是音讯体的类型，蕴含了类型和子类型，比方：
Content-Type: text/plain咱们常说的 MIME type 就是指这个标签。
上面是罕用的 MIME type：
| 阐明 | 后缀 | 类型 |
|---|---|---|
| 超文本标记语言文本 | .html | text/html |
| xml 文档 | .xml | text/xml |
| XHTML 文档 | .xhtml | application/xhtml+xml |
| 一般文本 | .txt | text/plain |
| RTF 文本 | .rtf | application/rtf |
| PDF 文档 | application/pdf | |
| Microsoft Word 文件 | .word | application/msword |
| PNG 图像 | .png | image/png |
| GIF 图形 | .gif | image/gif |
| JPEG 图形 | .jpeg,.jpg | image/jpeg |
| au 声音文件 | .au | audio/basic |
| MIDI 音乐文件 | mid,.midi | audio/midi,audio/x-midi |
| RealAudio 音乐文件 | .ra, .ram | audio/x-pn-realaudio |
| MPEG 文件 | .mpg,.mpeg | video/mpeg |
| AVI 文件 | .avi | video/x-msvideo |
| GZIP 文件 | .gz | application/x-gzip |
| TAR 文件 | .tar | application/x-tar |
| 任意的二进制数据 | application/octet-stream |
Content-Disposition
Content-Disposition 是在 RFC 2183 中增加的一个字段，示意的是音讯的展现款式。因为之前的音讯只是定义了它的音讯格局，并没有思考音讯是如何展现的问题，尤其是对于邮件来说。
比方邮件中插入了一个图片，那么这个图片是在咱们读音讯的时候内联展现呢？还是以附件的模式，必须要用户下载能力看到呢？
如果是在 HTTP 中，响应头字段 Content-Disposition:attachment 通常用作提醒客户端将响应注释出现为可下载文件。通常，当收到这样的响应时，Web 浏览器会提醒用户将其内容保留为文件，而不是将其显示为浏览器窗口中的页面。
Content-Transfer-Encoding
这个字段是做什么用的呢？
咱们晓得，随着数据格式越来越多，传统的 ASCII 曾经不能反对宏大的内容示意模式，所以呈现了超出 ASCII 范畴的内容示意模式如 Unicode。
然而对于 SMTP 服务器来说，可能传输或者意识的编码是无限的，如果要传输二进制内容，则须要应用肯定的 transfer encodings 形式对二进制内容进行转换。这就是 Content-Transfer-Encoding 的意义。
依据 RFC 和 IANA 的定义，有上面几个 transfer encodings 形式：
| Name | Reference |
|---|---|
| 7bit | [RFC2045] |
| 8bit | [RFC2045] |
| binary | [RFC2045] |
| quoted-printable | [RFC2045] |
| base64 | [RFC2045] |
具体 transfer encodings 的含意，能够参考我后续的文章，这里只做简略的介绍。
对于一般的 SMTP 服务器来说，能够反对 7bit、quoted-printable 和 base64 这三种编码方式。
对于 8BITMIME SMTP extension 的 SMTP 服务器来说，还反对 8bit 这种编码方式。
对于反对 BINARYMIME SMTP extension 的 SMTP 服务器来说，还反对 binary 这种编码方式。
Encoded-Word
依据 RFC 2822，确认音讯头中的字段名和值必须应用 ASCII 字符。如果音讯中蕴含非 ASCII 字符，则须要进行编码。这个编码就是 encoded-word。
编码的格局如下：
"=?charset?encoding?encoded text?=".charset 示意的是原音讯的编码，encoding 示意的是应用的编码方式，encoded text 是编码后的音讯。
Multipart messages
最初，介绍一下 Multipart messages，咱们晓得一个音讯是有对应的音讯类型：Content-Type 的。
如果是简单的音讯，那么它外面的音讯类型可能不止一种。所以这时候就须要用到 Multipart messages，也就是将音讯分为多个局部，每个局部都有一个 Content-Type。
这种类型在邮件中比拟常见。上面是一个 Multipart messages 的例子，在 Content-Type 中指定了一个音讯的宰割标记 boundary。
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier
This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--总结
以上就是 MIME 的根本介绍，在其中，咱们提到了几种 transfer encodings 办法，敬请期待后续文章。
本文已收录于 http://www.flydean.com/12-mime/
最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！
欢送关注我的公众号:「程序那些事」, 懂技术，更懂你！