多用途網際網路郵件擴充套件

多用途網際網路郵件擴充套件（，縮寫：MIME）是一個網際網路標準，它擴充套件了電子郵件標準，使其能夠支援：

非 ASCII 字元文字；
非文字格式附件（二進位制、聲音、圖片等）；
由多部分（multiple parts）組成的訊息體；
包含非 ASCII 字元的標頭資訊（Header information）。這個標準被定義於 RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049 等 RFC 中。

MIME 改善了由 RFC 822 轉變而來的 RFC 2822 ，這些舊標準規定電子郵件標準並不允許在郵件訊息中使用 7 位 ASCII 字元集以外的字元。正因如此，一些非英語字元訊息和二進位制檔案，影像，聲音等非文字訊息原本都不能在電子郵件中傳輸（MIME 可以）。MIME 規定了用於表示各種各樣的資料型別的符號化方法。此外，在全球資訊網中使用的 HTTP 協定中也使用了 MIME 的框架，標準被擴充套件為網際網路媒體形式。

MIME headers

MIME 是透過標準化電子郵件報文的頭部的附加域（fields）而實現的；這些頭部的附加域，描述新的報文型別的內容和組織形式。

1.1 MIME 版本

MIME 版本（MIME-Version），這個標頭區域在郵件訊息的報文用一個版本號碼來指明訊息遵從的 MIME 規範版本。目前版本是 1.0。

MIME-Version: 1.0

1.2 內容型別

內容型別（Content-Type），這個標頭區域用於指定資訊的型別。一般以下面的形式呈現。

Content-Type: type/subtype; parameter

type 有以下的形式：

Text：用於標準化地表示的文字訊息，文字訊息可以是多種字元集和或者多種格式的；
Multipart：用於連線訊息體的多個部分構成一個訊息，這些部分可以是不同型別的資料；
Application：用於傳輸應用程式資料或者二進位資料；
Message：用於包裝一個 E-mail 訊息；
Image：用於傳輸靜態圖片資料；
Audio：用於傳輸音訊或者音聲資料；
Video：用於傳輸動態影像資料，可以是與音訊編輯在一起的視訊資料格式；
Font：用於傳輸字型檔案；
Model：用於傳輸 3D 模型檔案。

subtype 用於指定 type 的詳細形式。content-type/subtype 配對的集合和與此相關的引數，將隨著時間而增長。為了確保這些值在一個有序而且公開的狀態下開發，MIME 使用 Internet Assigned Numbers Authority (IANA) 作為中心的註冊機制來管理這些值。常用的 subtype 值如下所示：

text/plain（純文字）
text/html（HTML 檔案）
application/xhtml+xml（XHTML 檔案）
image/gif（GIF 圖片）
image/jpeg（JPEG 圖片）【PHP 中為：image/pjpeg】
image/png（PNG 圖片）【PHP 中為：image/x-png】
audio/mpeg（MP3 音訊）
audio/aac（AAC 音訊）
video/mpeg（MPEG 影片）
video/mp4（MPEG-4 影片）
application/octet-stream（任意的二進位資料）
application/pdf（PDF 檔案）
application/msword（Microsoft Word 檔案）
application/vnd.openxmlformats-officedocument.wordprocessingml.document（Microsoft Word 2007 檔案）
application/vnd.wap.xhtml+xml (wap1.0+)
application/xhtml+xml (wap2.0+)
message/rfc822（RFC 822 形式）
multipart/alternative（HTML 郵件的 HTML 形式和純文字形式，相同內容使用不同形式表示）
application/x-www-form-urlencoded（使用 HTTP 的 POST 方法送出的表單）
multipart/form-data（同上，但主要用於表單送出時伴隨檔案上傳的場合）

此外，尚未被接受為正式資料型別的 subtype，可以使用 x - 開始的獨立名稱（例如 application/x-gzip）。vnd - 開始的固有名稱也可以使用（例：application/vnd.ms-excel）。

parameter 可以用來指定附加的資訊，更多情況下是用於指定 text/plain 和 text/htm 等的文字編碼方式的 charset 引數。MIME 根據 type 制定了預設的 subtype，當客戶端不能確定訊息的 subtype 的情況下，訊息被看作預設的 subtype 進行處理。Text 預設是 text/plain，Application 預設是 application/octet-stream 而 Multipart 預設情況下被看作 multipart/mixed。

1.3 內容配置

內容配置（Content-Disposition），原始的 MIME 只描述郵件內容的結構，並不會處理表現型別的問題。內容配置（Content-Disposition）在 RFC 2183 中被新增，用來指明 MIME 的表現型別。MIME 的每一部分可以新增下列配置。

inline 新增此配置後客戶端應自動展示資訊。
attachment 新增此配置後客戶端在接受到資訊後不自動展示，需要使用者自己選擇相應的方法處理資訊。

Content-Disposition 欄位也提供了一些引數。如檔名，檔案的建立日期和修改日期等，使郵件客戶端可以儲存附件。

以下是一個示例。

Content-Disposition: attachment; filename=genome.jpeg;

modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

儘管有些郵件客戶端僅在 Content-Type 的引數中添加了檔名來通訊，但這是不推薦的。正確的做法是在 Content-Disposition 中指定 filename 或是同時在 Content-Type 和 Content-Disposition 中指定 name 和 filename 的引數。在 HTTP 中 Content-Disposition: attachment 通常用來提示客戶端將響應體作為下載檔案，而不是在頁面中展示它。filename 引數是預設的下載檔名。

1.4 內容傳輸編碼

內容傳輸編碼（Content-Transfer-Encoding），這個區域使指定 ASCII 以外的文字編碼方式成為可能。形式如下：

Content-Transfer-Encoding: mechanism

其中，mechanism 的值可以指定為 “7bit”，“8bit”，“binary”，“quoted-printable”，“base64”。

1.4.1 7bit

7 位元 ASCII 碼。

1.4.2 8bit

8 位元 ASCII 碼。

1.4.3 binary

Not only may non-ASCII characters be present but the lines

are not necessarily short enough for SMTP transport.

1.4.4 quoted-printable

因為歐洲的一些文字和 ASCII 字元集中的某些字元有部分相同。如果郵件訊息使用的是這些語言的話，與 ASCII 重疊的那些字元可以原樣使用，ASCII 字元集中不存在的字符采用形如 “=??” 的方法編碼。這裡 “??” 需要用將字元編碼後的 16 進位制數字來指定。採用 quoted-printable 編碼的訊息，長度不會變得太長，而且大部分都是 ASCII 中的字元，即使不透過解碼也大致可以讀懂訊息的內容。

1.4.5 base64

base64 是一種將二進位的 01 序列轉化成 ASCII 字元的編碼方式。編碼後的文字或者二進位訊息，就可以運用 SMTP 等只支援 ASCII 字元的協定傳送了。Base64 一般被認為會平均增加 33% 的報文長度，而且，經過編碼的訊息對於人類來說是不可讀的。

1.4.6 x-encodingname

這個值是預留的擴充套件。

1.5 內容識別符號（可選）

1.6 內容描述（可選）