多用途互連網郵件擴充MIME

 

多用途互連網郵件擴充（MIME，Multipurpose Internet Mail Extensions）

在MIME出台之前，使用RFC 822隻能發送基本的ASCII碼文本資訊，郵件內容如果要包括二進位檔案、聲音和動畫等，實現起來非常困難。MIME提供了一種可以在郵件中附加多種不同編碼檔案的方法，彌補了原來的資訊格式的不足。實際上不僅僅是郵件編碼，現在MIME經成為HTTP協議標準的一個部分。

最早的HTTP協議中，並沒有附加的資料類型資訊，所有傳送的資料都被客戶程式解釋為超文字標記語言 (HTML)HTML 文檔，而為了支援多媒體資料類型，HTTP協議中也使用了附加在文檔之前的MIME資料類型資訊來標識資料類型。 在把輸出結果傳送到瀏覽器上的時候，瀏覽器通過文檔中的MIME類型來啟動適當的應用程式來處理這個輸出文檔。在HTTP中，MIME類型被定義在Content-Type header中。

 

總體來說，MIME訊息由訊息頭和訊息體兩大部分組成。現在我們關注的是MIME郵件，因此在以下的討論中姑且稱“訊息”為“郵件”。

 

一 MIME headers

MIME格式的郵件標頭包含了寄件者、收件者、主題、時間、MIME版本、郵件內容的類型等重要訊息。每條資訊稱為一個域，由網域名稱後加“: ”和資訊內容構成，可以是一行，較長的也可以佔用多行。域的首行必須“頂頭”寫，即左邊不能有空白字元（空格和定位字元）；續行則必須以空白字元打頭，且第一個空白字元不是資訊本身固有的，解碼時要過濾掉。

1）常見的域有：

網域名稱 含義 添加者 
Received       傳輸路徑 各級郵件伺服器 
Return-Path   回複地址 目標郵件伺服器 
Delivered-To  發送地址 目標郵件伺服器 
Reply-To        回複地址 郵件的建立者 
From             寄件者地址 郵件的建立者 
To                 收件者地址 郵件的建立者 
Cc                 抄送地址 郵件的建立者 
Bcc                暗送地址 郵件的建立者 
Date              日期和時間 郵件的建立者 
Subject                             主題 郵件的建立者 
Message-ID                       訊息ID 郵件的建立者 
MIME-Version                    MIME版本 郵件的建立者 
Content-Type                    內容的類型 郵件的建立者 
Content-Transfer-Encoding 內容的傳輸編碼方式 郵件的建立者 

 

2）內容類型（Content-Type），這個頭部領域用於指定訊息的類型。一般以下面的形式出現。Content-Type: [type]/[subtype]; parameter

type有下面的形式。

• Text：用於標準化地表示的文本資訊，簡訊可以是多種字元集和或者多種格式的；
• Multipart：用於串連訊息體的多個部分構成一個訊息，這些部分可以是不同類型的資料；
• Application：用於傳輸應用程式資料或者位元據；
• Message：用於封裝一個E-mail訊息；
• Image：用於傳輸靜態圖片資料；
• Audio：用於傳輸音頻或者音聲資料；
• Video：用於傳輸動態影像資料，可以是與音頻編輯在一起的視頻資料格式。

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】
• video/mpeg（MPEG動畫）
• application/octet-stream（任意的位元據）
• application/pdf（PDF文檔）
• application/msword（Microsoft Word檔案）
• 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。

 

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

  Content-Transfer-Encoding: [mechanism]

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

 

7bit這裡指的是7位的ASCII編碼方式。

8位元ASCII碼。

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

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

x-encodingname這個值是預留的擴充。

 

二 MIME body

1) 郵件中常見的簡單類型有text/plain(純文字)和text/html(超文本)。

2) 當郵件的MIME類型為multipart類型時，

郵件體被分為多個段，每個段又包含段頭和段體兩部分，這兩部分之間也以空行分隔。常見的multipart類型有三種：multipart/mixed, multipart/related和multipart/alternative。從它們的名稱，不難推知這些類型各自的含義和用處。它們之間的層次關係可歸納為所示：

+------------------------- multipart/mixed ----------------------------+|                                                                      ||  +----------------- multipart/related ------------------+            ||  |                                                      |            ||  |  +----- multipart/alternative ------+  +----------+  |  +------+  ||  |  |                                  |  | 內嵌資源 |  |  | 附件 |  ||  |  |  +------------+  +------------+  |  +----------+  |  +------+  ||  |  |  | 純文字本文 |  | 超文本本文 |  |                |            ||  |  |  +------------+  +------------+  |  +----------+  |  +------+  ||  |  |                                  |  | 內嵌資源 |  |  | 附件 |  ||  |  +----------------------------------+  +----------+  |  +------+  ||  |                                                      |            ||  +------------------------------------------------------+            ||                                                                      |+----------------------------------------------------------------------+

可以看出，如果在郵件中要添加附件，必須定義multipart/mixed段；如果存在內嵌資源，至少要定義multipart/related段；如果純文字與超文本共存，至少要定義multipart/alternative段。什麼是“至少”？舉個例子說，如果只有純文字與超文本本文，那麼在郵件標頭中將類型擴大化，定義為multipart/related，甚至multipart/mixed，都是允許的。

multipart諸類型的共同特徵是，在段頭指定“boundary”參數字串，段體內的每個子段以此串定界。所有的子段都以“--”+boundary行開始，父段則以“--”+boundary+“--”行結束。段與段之間也以空行分隔。在郵件體是multipart類型的情況下，郵件體的開始部分(第一個“--”+boundary行之前)可以有一些附加的文本行，相當於注釋，解碼時應忽略。

 

參考：

http://dev.csdn.net/htmls/18/18448.html

http://zh.wikipedia.org/zh/MIME

http://www.w3schools.com/media/media_mimeref.asp

 

完！