簡介

無規(guī)矩不成方圓，無標(biāo)準(zhǔn)不成網(wǎng)絡(luò)通信。正是在各種網(wǎng)絡(luò)協(xié)議和標(biāo)準(zhǔn)的基礎(chǔ)之上，才構(gòu)建了我們現(xiàn)在流行的互聯(lián)網(wǎng)。今天給大家介紹的就是一個(gè)網(wǎng)絡(luò)標(biāo)準(zhǔn)格式，叫做MIME，它的全稱是Multipurpose Internet Mail Extensions,翻譯過來就是多用途Internet郵件擴(kuò)展。

那么有小伙伴開始疑惑了，原來是一個(gè)郵件的擴(kuò)展協(xié)議，那么它跟我們使用的Internet網(wǎng)絡(luò)有什么關(guān)系呢?

不急，我們慢慢道來。

MIME詳解

在很久很久以前，計(jì)算機(jī)的一種流行的應(yīng)用就是發(fā)郵件，最開始的時(shí)候，計(jì)算機(jī)世界的編碼方式就只有ASCII一種，但是隨著時(shí)間的推移和各種應(yīng)用需求的激增，ASCII格式已經(jīng)不能滿足我們的需求了，格式多類型的同時(shí)也照成了互相通信之間的困難，于是一個(gè)統(tǒng)一的消息格式標(biāo)準(zhǔn)產(chǎn)生了，這個(gè)就是MIME。

MIME可以讓郵件不僅支持ASCII，還可以支持其他的編碼方式。同時(shí)支持圖片、音頻、視頻和應(yīng)用程序等多種附件。

消息體還可以支持多個(gè)part的集合，當(dāng)這樣的消息郵件使用MIME格式編碼之后，就可以通過標(biāo)準(zhǔn)的郵件協(xié)議，比如SMTP、POP、IMAP等進(jìn)行發(fā)送了。

因?yàn)镸IME是一個(gè)標(biāo)準(zhǔn)，所以只要符合這種標(biāo)準(zhǔn)的郵件都能夠被解析成功。

很快，MIME就在郵件世界被廣泛應(yīng)用，但是互聯(lián)網(wǎng)已經(jīng)發(fā)展到使用流行的HTTP協(xié)議來訪問萬維網(wǎng)的時(shí)候了，MIME中定義的各種content types很自然的也成了其他協(xié)議中使用的content標(biāo)準(zhǔn)。

這種content types是在MIME頭中定義的，應(yīng)用程序接收到content type之后，會(huì)根據(jù)類型中指定的消息類型，來采用對(duì)應(yīng)的應(yīng)用程序?qū)ο?nèi)容進(jìn)行解析。

MIME頭

MIME頭很重要，是應(yīng)用程序用來判斷消息格式的首要依據(jù)。MIME頭可以包含下面的字段。

MIME-Version

如果存在這個(gè)消息頭，說明這個(gè)消息是遵循的是MIME格式。它的值通常是1.0。

MIME-Version: 1.0

有細(xì)心的小伙伴可以能要問了，既然有1.0，那么有沒有1.1或者2.0呢?

很抱歉，答案是沒有。因?yàn)楦鶕?jù)MIME 共同創(chuàng)建者 Nathaniel Borenstein 的說法，雖然引入MIME版本號(hào)是為了在后續(xù)中對(duì)MIME進(jìn)行修改和升級(jí)。但是因?yàn)镸IME規(guī)范并沒有為未來MIME版本的升級(jí)進(jìn)行良好的設(shè)計(jì)，所以不同的人可能對(duì)MIME版本升級(jí)后的處理方式都是不一樣的。從而導(dǎo)致在MIME廣泛應(yīng)用的今天，很難對(duì)MIME規(guī)范進(jìn)行升級(jí)。

所以，就使用1.0吧。

Content-Type

如果屬性HTTP協(xié)議的同學(xué)，對(duì)這個(gè)頭應(yīng)該很熟悉了吧，這個(gè)頭表示的是消息體的類型，包含了類型和子類型，比如：

Content-Type: text/plain

我們常說的MIME type就是指這個(gè)標(biāo)簽。

下面是常用的MIME type：

Content-Disposition

Content-Disposition是在RFC 2183中添加的一個(gè)字段，表示的是消息的展示樣式。因?yàn)橹暗南⒅皇嵌x了它的消息格式，并沒有考慮消息是如何展示的問題，尤其是對(duì)于郵件來說。

比如郵件中插入了一個(gè)圖片，那么這個(gè)圖片是在我們讀消息的時(shí)候內(nèi)聯(lián)展示呢?還是以附件的形式，必須要用戶下載才能看到呢?

如果是在HTTP中，響應(yīng)頭字段Content-Disposition:attachment 通常用作提示客戶端將響應(yīng)正文呈現(xiàn)為可下載文件。通常，當(dāng)收到這樣的響應(yīng)時(shí)，Web瀏覽器會(huì)提示用戶將其內(nèi)容保存為文件，而不是將其顯示為瀏覽器窗口中的頁面。

Content-Transfer-Encoding

這個(gè)字段是做什么用的呢?

我們知道，隨著數(shù)據(jù)格式越來越多，傳統(tǒng)的ASCII已經(jīng)不能支持龐大的內(nèi)容表示形式，所以出現(xiàn)了超出ASCII范圍的內(nèi)容表示形式如Unicode。

但是對(duì)于SMTP服務(wù)器來說，能夠傳輸或者認(rèn)識(shí)的編碼是有限的，如果要傳輸二進(jìn)制內(nèi)容，則需要使用一定的transfer encodings方式對(duì)二進(jìn)制內(nèi)容進(jìn)行轉(zhuǎn)換。這就是Content-Transfer-Encoding的意義。

根據(jù)RFC和IANA的定義，有下面幾個(gè)transfer encodings方式：

具體transfer encodings的含義，可以參考我后續(xù)的文章，這里只做簡單的介紹。

對(duì)于普通的SMTP服務(wù)器來說，可以支持7bit、quoted-printable和base64這三種編碼方式。

對(duì)于8BITMIME SMTP extension的SMTP服務(wù)器來說，還支持8bit這種編碼方式。

對(duì)于支持BINARYMIME SMTP extension的SMTP服務(wù)器來說，還支持binary這種編碼方式。

Encoded-Word

根據(jù)RFC 2822，確認(rèn)消息頭中的字段名和值必須使用ASCII字符。如果消息中包含非ASCII字符，則需要進(jìn)行編碼。這個(gè)編碼就是encoded-word 。

編碼的格式如下：

"=?charset?encoding?encoded text?=".

charset表示的是原消息的編碼，encoding表示的是使用的編碼方式，encoded text是編碼后的消息。

Multipart messages

最后，介紹一下Multipart messages，我們知道一個(gè)消息是有對(duì)應(yīng)的消息類型：Content-Type的。

如果是復(fù)雜的消息，那么它里面的消息類型可能不止一種。所以這時(shí)候就需要用到Multipart messages，也就是將消息分為多個(gè)部分，每個(gè)部分都有一個(gè)Content-Type。

這種類型在郵件中比較常見。下面是一個(gè)Multipart messages的例子，在Content-Type中指定了一個(gè)消息的分割標(biāo)記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--