简介
无规矩不成方圆，无标准不成网络通信。正是在各种网络协议和标准的基础之上，才构建了我们现在流行的互联网。今天给大家介绍的就是一个网络标准格式，叫做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文档 .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/
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
