我們簡單地比較一下SMTP和HTTP。這兩個(gè)協(xié)議都是用于從一臺(tái)主機(jī)向另一臺(tái)主機(jī)傳送文件;HTTP用于從web服務(wù)器向Web用戶代理(即瀏覽器)傳送文件(或?qū)ο?，SMTP用于從一個(gè)郵件服務(wù)器向另一個(gè)郵件服務(wù)器傳送文件(也就是電子郵件消息)。在傳送文件時(shí)，SMTP和持久HTTP都使用持久連接。可見，這兩個(gè)協(xié)議具有一些共同的特征，不過它們之間的差別也是顯著的。首先，HTTP基本上是一個(gè)內(nèi)拉式協(xié)議(pull protocol)——有人把信息上傳到web服務(wù)器中，用戶則在方便的時(shí)候使用HTTP把這些信息從服務(wù)器上拉過來。更確切地說，TCP連接是由想要接收文件的主機(jī)發(fā)起的。SMIP則基本上是一個(gè)外推式協(xié)議(pushProtoco1)——發(fā)送端郵件服務(wù)器把文件推送給接收端郵件服務(wù)器。更確切地說，TCP連接是由想要發(fā)送文件的主機(jī)發(fā)起的。

SMTP和HTTP的第二個(gè)重要差別是，SMTP要求包括信體部分在內(nèi)的每個(gè)郵件消息都是7位ASCII文本格式。另外，SMTP RFC還要求每個(gè)郵件消息的信體以僅由單個(gè)點(diǎn)號(hào)構(gòu)成的一行結(jié)束，改用ASCII字符名稱來說就是每個(gè)郵件消息的信體必須以“CRLF.CRLF“結(jié)尾，其中CR和LF分別代表回車符和換行符。這種方式下，當(dāng)從同一個(gè)SMTP客戶接收一系列郵件消息時(shí)，SMTP服務(wù)器可以通過在字節(jié)流中搜索“CRLF.CRLF”來分割每個(gè)消息。要是信體不是ASCII文本，而是二進(jìn)制數(shù)據(jù)(譬如說一幅JPEG圖像)，那么這些二進(jìn)制數(shù)據(jù)字節(jié)流中偶爾出現(xiàn)“CRLF.CRLF”這一模式是有可能的。這將導(dǎo)致SMTP服務(wù)器不正確地認(rèn)定當(dāng)前郵件消息已結(jié)束。為避免這樣的問題，二進(jìn)制數(shù)據(jù)應(yīng)以一定的方式先編碼成ASCII文本，保證其中不使用特定的ASCH字符(包括點(diǎn)號(hào))。HTTP無論是持久的還是非持久的都不需要預(yù)先把二進(jìn)制數(shù)據(jù)轉(zhuǎn)換成ASCII本。對(duì)于持久的HTTP，每個(gè)TCP連接只傳送一個(gè)對(duì)象:服務(wù)器關(guān)閉連接后，客戶就知道己接收到一個(gè)完整的響應(yīng)消息。對(duì)于非持久的HTTP，每個(gè)響應(yīng)消息中包含一個(gè)Content-length:頭部，使得客戶能夠確定每個(gè)響應(yīng)消息的邊界。

SMTP和HTTP的第三個(gè)重要差別涉及如何處理包含文本和圖像或其他媒體類型的文檔。HTTP是把每個(gè)對(duì)象封裝在各自的HTTP響應(yīng)消息中。SMTP(正如接下去要詳細(xì)討論的那樣)是把同一個(gè)郵件內(nèi)的各個(gè)對(duì)象置于同一個(gè)郵件消息中。

郵件消息格式和MIME

當(dāng)Alice給Bob發(fā)一封普通的郵政信件時(shí)，她把這封信裝入一個(gè)信封里，在信封上寫明Bob的地址和自己的回信地址，然后投入郵箱;郵政業(yè)務(wù)在遞送這封信的過程中，也會(huì)把表明時(shí)間和地點(diǎn)的郵戳蓋在信封上。類似地，當(dāng)電子郵件消息從一個(gè)人傳送到另——個(gè)人時(shí)，在信體之前會(huì)有一個(gè)含有這些外圍信息的信頭。這些信息實(shí)際上由一系列在RFC 822中定義的郵件消息頭部及其值構(gòu)成。郵件消息中構(gòu)成信頭的各個(gè)頭部和信體之間以一個(gè)空行(也就是CRLF)分割。RFC 822詳細(xì)說明了各個(gè)郵件消息頭部的格式和含義。與HTTP一樣，郵件消息的每個(gè)頭部都是直觀可讀的文本，由一個(gè)后跟冒號(hào)的關(guān)鍵字和相應(yīng)的值構(gòu)成。郵件消息的頭部有些是必須的，有些則是司選的。每個(gè)信頭必須有一個(gè)From:頭部和一個(gè)To:頭部.還可以有一個(gè)Subject:頭部和其他頭部。需注意的是，這些頭部和先前討論的SMTP命令不是一回事:SMTP命令是SMTP握手協(xié)議的一部分，郵件消息頭部則屬于郵件消息的一部分。

下面是一個(gè)典型的電子郵件信頭:

From:alice@crepes.fr

To:bob@hamburger.edu

Subject:this is a test

信頭之后空一行就是信體。整個(gè)消息以只含有一個(gè)點(diǎn)號(hào)的單獨(dú)行結(jié)束。

非ASCII數(shù)據(jù)的MlME擴(kuò)展

RFC 822中說明的郵件消息頭部盡管足以滿足發(fā)送普通ASCII文本郵件的要求，但是在多媒體消息(例如，包含圖像、音頻或視頻數(shù)據(jù)的消息)的描述和非ASCII文本格式(例如，非英語國家使用的文字)的承載上，卻顯然不夠。要發(fā)送非ASCII文本的郵件消息，必須由發(fā)送者的用戶代理在其中增添額外的頭部RFC 2045和RFC 2046定義了這些額外的頭部，它們是對(duì)RFC 822的多用途因特網(wǎng)郵件擴(kuò)展(Multipurpose Internet Mail Extensions，簡稱MIME)。

支持多媒體的兩個(gè)關(guān)鍵MIME頭部是Content-Type:和Content-Tansfer-Encoding:。Content-Type:頭部允許接收用戶代理對(duì)郵件消息采取合適的行動(dòng)。例如，通過指出信體內(nèi)容為一個(gè)JPG圖像，接收用戶代理可以把信仲定向到某個(gè)JNG解壓縮例程。我們已經(jīng)知道，為確保SMTP正常工作，非ASCII文本消息必須預(yù)先編碼成ASCH文本格式。

Content-Tansfer-Encoding:頭部用于告知接收用戶代理信體已被編碼咸ASCII格式，并指出具體編碼方式。這樣，當(dāng)某個(gè)用戶代理收到一個(gè)包含這兩個(gè)頭部的郵件消息時(shí)，它首先使用Content-Tansfer-Encoding:頭部的值把信體轉(zhuǎn)換成原始的非AscH文本形式，再使用Content-Type:頭部的值確定自己應(yīng)該對(duì)信體采取什么行動(dòng)。

下面看一個(gè)具體的例子。假設(shè)Alice想給Bob發(fā)送一個(gè)JPEG圖像，她為此調(diào)用自己的用戶代理，給出Bob的電子郵件地址和郵件消息的主題，并把這個(gè)JPG圖像插入這個(gè)郵件消息的信體中(這個(gè)圖像有可能是作為該郵件消息的“附件”插入的，具體取決于Alice所用的用戶代理)。Alice填寫完郵件消息后讓用戶代理把它發(fā)送出去。Alice的用戶代理生成一個(gè)大體如下的MIME消息:

From:alice@crepes.fr

To:bob@hamburger.edu

Subject:picture of mine

MIME-Version:1.0

Content-Transfer-Encoding:base64

Content-Type:image/jpeg

{...base64編碼數(shù)據(jù)...)

{...base64編碼數(shù)據(jù)...)

從中我們可以看到，alice的用戶代理采用base64編碼格式對(duì)這個(gè)JPEG圖像進(jìn)行編碼i而base64是在MIME中標(biāo)準(zhǔn)化的用于轉(zhuǎn)換成某種可接受的7位ASCII格式的編碼技術(shù)之一[RFC 2045]。另一種流行的內(nèi)容傳送編碼技術(shù)稱為帶轉(zhuǎn)義的可打印(叫quoted-printable)編碼格式，一般用于把普通的ASCII郵件消息轉(zhuǎn)換成不帶非期望字符串(例如由單個(gè)點(diǎn)號(hào)構(gòu)成的行)的ASCII文本。

Bob閱讀郵件時(shí)，其用戶代理所操作的是同一個(gè)MIME消息。該用戶代理看到值為base64的Content-Transfer-Encoding:頭部后，知道該郵件消息中還有一個(gè)值為image/jpeg的Content-Type:頭部，它告知Bob的用戶代理應(yīng)該對(duì)信體進(jìn)行JPEG解壓縮。該郵件消息中的MIME-Version:頭部自然是在指示本消息所用的MIME版本。需注意的是，郵件消息的其余部分仍然遵循標(biāo)準(zhǔn)的RFC 922/SMTP格式。具體地說，在信頭之后有一個(gè)空行，接著是信體:在信體結(jié)束處是一個(gè)僅由單個(gè)點(diǎn)號(hào)構(gòu)成的行。

我們接下去深入討論一下Content-Type;頭部。該頭部按照MIME規(guī)范[RFC 2046]有如下的格式;

Content-Type: type/subtype; parameters

其中parameters(以及其前面的分號(hào))是可選的。通過在Content-Type:頭部給出媒體類型名和子類型名，MIME消息信體中數(shù)據(jù)的性質(zhì)得以說明。類型名和子類型名之后的其余部分是一組參數(shù)。總的說來，頂級(jí)類型名用于聲明數(shù)據(jù)的一般類型，子類型名用于指明這類數(shù)據(jù)中的某種具體格式。參數(shù)是對(duì)于類型的修飾說明，具體取決于類型和子類型本身，基本上不影響內(nèi)容性質(zhì)的指定。MIME是按照可擴(kuò)展這一目標(biāo)仔細(xì)地設(shè)計(jì)的，并預(yù)期媒體類型/子類型以及它們的相關(guān)參數(shù)會(huì)隨時(shí)間顯著增長。為確保以有秩序的文檔完備公開的方式開發(fā)這些類型/子類型，MIME建立了一套注冊(cè)程式，把因特網(wǎng)已分配數(shù)值權(quán)威(Internet Asigned Numbers Authority，簡稱IANA)作為MIME各個(gè)可擴(kuò)展域的中心注冊(cè)處。BFC 2048具體說明了這些可擴(kuò)展域的注冊(cè)程式。

當(dāng)前已定義的MIME頂級(jí)類型共有7個(gè)，每個(gè)類型關(guān)聯(lián)一組子類型，其數(shù)量在逐年增長。下面是其中的5個(gè)類型;

●text;text類型用于向接收者的用戶代理指出消息體為文本。該類型極為普遍的一個(gè)類型/子類型對(duì)為text/plain。子類型plain指定不含任何格式定義信息的普通文本。plain文本應(yīng)該不加任何解釋地按照原樣顯示，不需要特殊的軟件，能支持給定的字符集就行。在實(shí)際的郵件消息中經(jīng)常能看到值為比text/plain;charset=gb2312或text/plain;charset="ISO—8859—1"的Content-Type:頭部，其中的參數(shù)指出用于產(chǎn)生相應(yīng)消息的字符集。另一個(gè)變得越來越普遍的類型/子類型對(duì)是text/html。子類型html指示接收用戶代理解釋嵌埋在消息體中的html標(biāo)記，從而像Web頁面那樣顯示信件內(nèi)容，其中有可能包含各種字體的文本、超鏈接、Java小應(yīng)用程序，等等。

●image:image類型用于向接收用戶代理指出消息體為圖像。該類型較為流行的兩個(gè)類型/子類型對(duì)為iamge/gif和image/jpeg，接收用戶代理碰到這樣的類型時(shí)，就知道該把消息體作為GIF圖像或JPEG圖像解碼并顯示。

●audio:audio類型需要音頻輸出設(shè)備(例如揚(yáng)聲器或電話)來表達(dá)內(nèi)容。這類型中常見的已標(biāo)準(zhǔn)化子類型包括basic(基本8位u-law編碼)和32kadpcm(RFC 1911中定義的一種32Kbps格式)。

●video:video類型的子類型包括mpeg和quicktime。

●application:application類型適用于不適合歸為其他類別的數(shù)據(jù)，通常用在必須由某個(gè)應(yīng)用程序預(yù)先處理才能為用戶所見或所用的數(shù)據(jù)上。例如.當(dāng)用戶在某個(gè)電子郵件消息中附帶一個(gè)微軟word文檔時(shí)，其用戶代理一般把它的類型子類型對(duì)指定為application/msword;這將導(dǎo)致接收用戶代理啟動(dòng)微軟word應(yīng)用程序，并把該MIME消息的信體傳遞給它處理。這類型極為重要的一個(gè)子類型是octet-stream，它用于指示信體含有任意的二進(jìn)制數(shù)據(jù)。收到內(nèi)容類型為application/octet-stream的郵件消息后，接收用戶代理會(huì)提示用戶是否把信體保存到硬盤中，以便稍后處理。