|
在RFC 2822文檔中定義了簡單的 ASCII編碼的Email的郵件格式，然而隨著Internet的發(fā)展,，Email郵件僅僅傳輸簡單的文本已經(jīng)滿足不了用戶的需求，為了在Email 中傳輸大量HTML,、 圖像,、聲音以及各種附件格式，一種新的擴展的郵件格式應(yīng)運而生——MIME,。由于在MIME郵件格式非常復(fù)雜,，大量的RFC文檔中對MIME郵件格式進(jìn)行 了定義與說明，比如RFC2045, RFC2046, RFC2047, RFC2049, RFC2231, RFC2387, RFC4288, RFC4289等,。因此,，MIME郵件格式為我們提供了極大的靈活性的同時也給我們解讀MIME格式的Email郵件帶來了極大的困難。以下就一封具體的 郵件原始信息對MIME郵件格式作出一個概要的介紹,。 解釋幾個常用且不易理解的Content-Type開頭的MIME首部： Received: from JSJ104 (unknown [202.204.96.147]) This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7118D.38E01920 MTIzMTIzMTIz ------=_NextPart_000_0003_01C7118D.38E01920 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv ------=_NextPart_000_0003_01C7118D.38E01920-- 這封Email具有一個郵件首部,，然后是郵件的主體部分，它包括一個文本和一個HTML類型,?？梢宰⒁獾竭@樣一行編碼 “boundary="----=_NextPart_000_0003_01C7118D.38E01920" ”，它是用來隔離MIME郵件的各個實體部分,。 在RFC2822中定義了MIME郵件首部的格式： field-name ":" [ field-body ] CRLF 最常見也用途最都的MIME首部是以Content-Type開頭的,，在RFC2046給出了它的定義，大致與如下內(nèi)容相似： Content-Type: multipart/mixed; boundary="----=_Part_3431_12384933.1139387792352"
2) Content-Type: multipart/alternative 3) Content-Type: multipart/related 郵件主體的編碼： 主要是包括quoted-printable與base64兩種類型的編碼。Base64和Quoted-Printable都屬于MIME（多用途部分,、多媒體電子郵件和 WWW 超文本）的一種編碼標(biāo)準(zhǔn),，用于傳送諸如圖形,、聲音和傳真等非文本數(shù)據(jù)）。
參考資料: http://biancheng./perl/251301.html
MIME的編碼介紹(由網(wǎng)上資料和實踐經(jīng)驗整合)
一、MIME: Multipurpose Internet Mail Extensions 英國帝國大學(xué)計算機在
線字典FOLDOC對MIME的解釋為:“多部分(multi-part),、多媒體電子郵件和WWW超文本的一種編碼標(biāo)準(zhǔn),，用于傳送諸如圖形、聲音和傳真
等非文本數(shù)據(jù),。MIME定義于RFC1341,，用MIMENCODE的方法將二進(jìn)制數(shù)據(jù)轉(zhuǎn)換成為一種被稱為BASE64的ASCII子集的字符的組合?！?br>
Internet上有專門討論MIME的新聞組: comp.mail.mime,。該新聞組的FAQ可以從下面的網(wǎng)點獲得：
http://www.cis./hypertext/faq/usenet/mail/mime-faq/mime0/faq.html MIMENCODE最早稱為MMENCODE，提出用MIMENCODE代替UUENCODE,，是因為UUENCODE使用了一些字符在一
些郵件網(wǎng)關(guān)（特別是那些轉(zhuǎn)換ASCII和EBCDIC碼的網(wǎng)關(guān)）中造成傳輸障礙,，（還有一些軟件不能對所有 UUENCODE
的算法進(jìn)行正確解碼而導(dǎo)致郵件的閱讀困難），因此 MIME 被設(shè)計用于替代UUENCODE,，但是結(jié)果是這些協(xié)議共存,。
在MIME出臺之前，使用RFC 822只能發(fā)送基本的ASCII碼文本信息,，郵件內(nèi)容如果要包括二進(jìn)制文件,、聲音和動畫等，實現(xiàn)起來非常困難,。
MIME提供了一種可以在郵件中附加多種不同編碼文件的方法,，彌補了原來的信息格式的不足,。實際上不僅僅是郵件編碼,，現(xiàn)在MIME經(jīng)成為HTTP協(xié)議標(biāo)準(zhǔn)的一個部分。 二,、MIME編碼方式簡介
對郵件進(jìn)行編碼最初的原因是因為 Internet 上的很多網(wǎng)關(guān)不能正確傳輸8bit內(nèi)碼的字符,，比如漢字等。編碼的原理就是把8bit的內(nèi)容轉(zhuǎn)換成7bit的形式以能正確傳輸,，在接收方收到之后,，再將其還原成8bit的內(nèi)容。
在MIME協(xié)議之前,，郵件的編碼曾經(jīng)有過UUENCODE等編碼方式
,，但是由于MIME協(xié)議算法簡單，并且易于擴展,，現(xiàn)在已經(jīng)成為郵件編碼方式的主流,，不僅是用來傳輸8bit的字符，也可以用來傳送二進(jìn)制的文件,，如郵件附
件中的圖像,、音頻等信息，而且擴展了很多基于MIME
的應(yīng)用,。從編碼方式來說,，MIME定義了兩種編碼方法Base64與QP(Quote-Printable),。
1.Base64編碼
Base64是一種通用的方法，其原理很簡單,，就是把三個Byte的數(shù)據(jù)用4個Byte表示,。在這四個Byte中，實際用到的都只有前面6bit,，這樣就不存在只能傳輸7bit的字符的問題了,。Base64的縮寫一般是“B”。
Base64將輸入的字符串或一段數(shù)據(jù)編碼成只含有{'A'-'Z', 'a'-'z', '0'-'9', '+', '/'}這64個字符的串,，'='用于填充,。
其編碼的方法是，將輸入數(shù)據(jù)流每次取6bit,，用此6bit的值(0-63)作為索引去查表,，輸出相應(yīng)字符。 這樣,，每3個字節(jié)將編碼為4個字符(3×8 → 4×6),；不滿4個字符的以'='填充。 有的場合,，以“=?charset?B?xxxxxxxx?=”表示xxxxxxxx是Base64編碼,，且原文的字符集是charset。在段體內(nèi)則直接編碼,，適當(dāng)時機換行,，MIME建議每行最多76個字符。 Base64的算法很簡單,，它將字符流順序放入一個24位的緩沖區(qū),，缺字符的地方補零。 然后將緩沖區(qū)截斷成為4個部分,，高位在先,，每個部分6位，用64個字符重新表示,。如果輸入只有一個或兩個字節(jié),，那么輸出將用等號“=”補足。這可以隔斷附加的信息造成編碼的混亂,。 2.QP編碼
另一種方法是QP(Quote-Printable)
方法,，通常縮寫為“Q”方法,，其原理是把一個8bit的字符用兩個16進(jìn)制數(shù)值表示,，然后在前面加“=”。所以我們看到經(jīng)過QP編碼后的文件通常是這個樣
子：=B3=C2=BF=A1=C7=E5=A3= AC=C4=FA=BA=C3=A3=A1。
Quoted -printable根據(jù)輸入的字符串或字節(jié)范圍進(jìn)行編碼,，若是不需編碼的字符,，直接輸出。若需要編碼,，則先輸出'=',，后面跟著以2個字符表示的十六進(jìn) 制字節(jié)值。有的場合,，以“=?charset?Q?xxxxxxxx?=”表示xxxxxxxx是Quoted-printable編碼,，且原文的字符集 是charset。在段體內(nèi)則直接編碼,，適當(dāng)時機換行,，換行前額外輸出一個'='。 三,、MIME的頭信息 郵件頭
在郵件頭中,，有很多從RFC 822沿用的域名，MIME也增加了一些,。常見的標(biāo)準(zhǔn)域名和含義如下:
域名 含義 添加者
Received 傳輸路徑 各級郵件服務(wù)器 Return-Path 回復(fù)地址 目標(biāo)郵件服務(wù)器 Delivered-To 發(fā)送地址 目標(biāo)郵件服務(wù)器 Reply-To 回復(fù)地址 郵件的創(chuàng)建者 From 發(fā)件人地址 郵件的創(chuàng)建者 To 收件人地址 郵件的創(chuàng)建者 Cc 抄送地址 郵件的創(chuàng)建者 Bcc 暗送地址 郵件的創(chuàng)建者 Date 日期和時間 郵件的創(chuàng)建者 Subject 主題 郵件的創(chuàng)建者 Message-ID 消息ID 郵件的創(chuàng)建者 MIME-Version MIME版本 郵件的創(chuàng)建者 Content-Type 內(nèi)容的類型 郵件的創(chuàng)建者 Content-Transfer-Encoding 內(nèi)容的傳輸編碼方式 郵件的創(chuàng)建者 非標(biāo)準(zhǔn)的,、自定義域名都以X-開頭，例如X-Mailer, X-MSMail-Priority等,，通常在接收和發(fā)送郵件的是同一程序時才能理解它們的意義,。
段頭
在段頭中，大致有如下一些域:
域名 含義
Content-Type 段體的類型 Content-Transfer-Encoding 段體的傳輸編碼方式 Content-Disposition 段體的安排方式 Content-ID 段體的ID Content-Location 段體的位置(路徑) Content-Base 段體的基位置 有的域除了值之外,，還帶有參數(shù),。值與參數(shù)、參數(shù)與參數(shù)之間以“;”分隔,。參數(shù)名與參數(shù)值之間以“=”分隔,。
1.MIME-Version
表示使用的MIME的版本號,，一般是1.0; 如: MIME-Version: 1.0 2.Content-Type
Content-Type定義了正文的類型,，我們實際上是通過這個標(biāo)識來知道正文內(nèi)是什么類型的文件。比如：text/plain
表示的是無格式的文本正文,，text/html 表示的 Html 文檔,，image/gif 表示的是 gif
格式的圖片等等。Content-Type都是“主類型/子類型”的形式,。主類型有text, image, audio, video,
application, multipart, message等,，分別表示文本、圖片,、音頻,、視頻、應(yīng)用、分段,、消息等,。每個主類型都可能有多個子類型，如text類型就包含plain, html, xml, css等子類型,。以X-開頭的主類型和子類型,，同樣表示自定義的類型，未向IANA正式注冊,，但大多已經(jīng)約定成俗了,。如application/x-zip-compressed是ZIP文件類型。在Windows中,，注冊表的“HKEY_CLASSES_ROOT\MIME\Database\Content Type”內(nèi)列舉了除multipart之外大部分已知的Content-Type,。
關(guān)于參數(shù)的形式，RFC里有很多補充規(guī)定,，有的允許帶幾個參數(shù),，較為常見的有:
主類型 參數(shù)名 含義
text charset 字符集 image name 名稱 application name 名稱 multipart boundary 邊界 multipart類型
郵件中常用到的復(fù)合類型:multipart。
multipart類型表示正文是由多個部分組成的,，后面的子類型說明的是這些部分之間的關(guān)系,。 郵件中用到的三個類型有: (1).multipart/alternative：表示正文由兩個部分組成，可以選擇其中的任意一個,。主要作用是在征文同時有text格式和html格式時,，可以在兩個正文中選擇一個來顯示，支持 html 格式的郵件客戶端軟件一般會顯示其 HTML 正文,，而不支持的則會顯示其Text正文,； (2).multipart/mixed：表示文檔的多個部分是混合的，指正文與附件的關(guān)系,。如果郵件的MIME類型是multipart/mixed,，即表示郵件帶有附件。 (3).multipart/related：表示文檔的多個部分是相關(guān)的,，一般用來描述 Html 正文與其相關(guān)的圖片,。 multipart類型，是MIME郵件的精髓,。郵件體被分為多個段,，每個段又包含段頭和段體兩部分，這兩部分之間也以空行分隔,。它們之間的層次關(guān)系可歸納為下圖所示：
+------------------------- multipart/mixed ----------------------------+
| | | +----------------- multipart/related ------------------+ | | | | | | | +----- multipart/alternative ------+ +----------+ | +------+ | | | | | | 內(nèi)嵌資源 | | | 附件 | | | | | +------------+ +------------+ | +----------+ | +------+ | | | | | 純文本正文 | | 超文本正文 | | | | | | | +------------+ +------------+ | +----------+ | +------+ | | | | | | 內(nèi)嵌資源 | | | 附件 | | | | +----------------------------------+ +----------+ | +------+ | | | | | | +------------------------------------------------------+ | | | +----------------------------------------------------------------------+ 可以看出,，如果在郵件中要添加附件，必須定義multipart/mixed段,；如果存在內(nèi)嵌資源,，至少要定義multipart/related段,；如 果純文本與超文本共存，至少要定義multipart/alternative段,。什么是“至少”,？舉個例子說，如果只有純文本與超文本正文,，那么在郵件 頭中將類型擴大化,，定義為multipart/related，甚至multipart/mixed,，都是允許的,。
multipart諸類型的共同特征是，在段頭指定“boundary”參數(shù)字符串,，段體內(nèi)的每個子段以此串定界,。所有的子段都以
“--”+boundary行開始，父段則以“--”+boundary+“--”行結(jié)束,。段與段之間也以空行分隔,。在郵件體是multipart類型的
情況下，郵件體的開始部分(第一個“--”
+boundary行之前)可以有一些附加的文本行,，相當(dāng)于注釋,，解碼時應(yīng)忽略。段間也可以有一些附加的文本行,，不會顯示出來,。
這些復(fù)合類型又是可以嵌套使用的，比如說一個帶有附件的郵件,，同時有html與text兩種格式的正文,，則郵件的結(jié)構(gòu)是：
Content-Type: multipart/mixed
部分一：
Content Type : multipart/alternative：
Text 正文；
Html 格式的正文
部分二：
附件
郵件結(jié)束符,；
由于復(fù)合類型由多個部分組成,，因此，需要一個分隔符來分隔這多個部分,，這就是上面的郵件源文件中的boundary所描述的,，對于每一個Contect type :multipart/* 的內(nèi)容，都會有這么一個說明,，表示多個部分之間的分隔,。
含有 MIME/BASE64編碼的郵件,，你查看它的源碼時一般都含有:“This is a multi-part message in MIME format.”這樣的句子,。也可以被絕大多數(shù)的email程序進(jìn)行解碼，包括Netscape,、MS Mail,、Eudora等,。這些程序可以正確識別郵件的正文，恢 MIME/BASE64 編碼的部分為正確的文字或夾帶的二進(jìn)制文件,。 3.Content-Transfer-Encoding
它表示了這個部分文檔的編碼方式,。只有識別了這個說明，才能用正確的解碼方式實現(xiàn)對其解碼,。
Content-Transfer-Encoding共有Base64, Quoted-printable, 7bit, 8bit, Binary等幾種,。 其中7bit是缺省的編碼方式。電子郵件源碼最初設(shè)計為全部是可打印的ASCII碼的形式,。 非ASCII碼的文本或數(shù)據(jù)要編碼成要求的格式,。 Base64, Quoted-Printable是在非英語國家使用最廣使的編碼方式。 Binary方式只具有象征意義,，而沒有任何實用價值,。 4.boundary
這個分隔符是正文中不可能出現(xiàn)的一串古字符的組合，在文檔中,，以"--"加上這個boundary
來表示一個部分的開始,，在文檔的結(jié)束，以"--"加boundary再在最后加上"--"來表示文檔的結(jié)束,。由于復(fù)合類型是可以嵌套使用的,，因此，郵件中
可能會多個boundary,。
|
|
|
