| MIME文件在郵件中傳送多種文件格式的文件 因爲在現實中存在了許多文件格式，本文主要說明如何使用電子郵件傳送多種文件，傳送的方法就是使用MIME的方法。這裏我們先說明一下URI，它是存在於HTML或其它文件中的一個參照標記，它在文件中指出這個地方是引用另外一個對象（比如文件，圖象）。在傳送這類電子郵件時，也應該把這些東西一起傳送出去。另外一種方法是，只傳送這些URI，當用戶打開時，要求用戶使用HTTP查看相應的對象，本文不討論這種方法。 這種包括許多種對象的文件我們稱爲集成文件。在集成文件中的一些對象可以連接到第一個對象，在傳送這些文件時，轉發機制不會覺得這和平常的郵件有什麼區別，它甚至可以爲非IP連接的用戶傳送WWW文檔。而接收程序則有所不同，有些接收程序可以直接顯示，有些則需要把這種文件送給瀏覽器顯示。 前面不是說過了嗎，在這些集成文件中有一些URI參考，因此需要定義兩個內容頭：Content-Location和Content-Base。我們目前只討論URL這一種類型，其它類型在日後也可以加以支持，這些頭的格式如下：
content-location ::= "Content-Location:" ( absoluteURI | relativeURI )
content-base ::= "Content-Base:" absoluteURI
這裏，我們把URI看成是一個嚴格定義的URL就可以了。Content-Base給定一個基，這個基必須是一個絕對URI。下面是幾個例子：
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo2*[email protected] //Content-Base頭不能放在這裏，因爲這是一個多部分（multipart）MIME對象；
--boundary-example-1
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo2*[email protected]>
Content-Location: http://www.aaa.net/images/foo1.bar1 //這個Content-Location必須是一個絕對URI，因爲沒有指定基，所以不能使用相對地址；
--boundary-example-1
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo4*[email protected]>
Content-Location: foo1.bar1 //這裏使用了相對地址，因爲下一句指定了基點的位置，foo1.bar1就在這個基下的東西；
Content-Base: http://www.aaa.net/images/ --boundary-example-1--
Content-Location是一個位置量，它可以是一個相對量，也可以是一個絕對量，當它是相對量的時候一定有基存在，不然它相對誰呀。這裏使用任何的URI機制都可以，標準不標準都行，但是如果採用不標準的有時候會有麻煩，一定要小心。有時候Content-Location可以指示數據發送方在這個URI下是可以取得的，這時候一定要確定這個地址是標準的，可用的，不然會出錯。相對URI是通過MIME內的基URI來解析的，有下面幾種方法可以解析基URI，一種是通過HTML提供的命令來支持，而另一種是使用Content-Base頭來進行，也可以使用MIME對象體內的Content-Location當作基來使用。 有時候，發送的郵件內可能不包括連接的對象（如圖象，聲音等），這時郵件可以用Text/HTML形式發送。這樣的文件中包括的連接對於用戶來說就只能通過上網取得，而有些是根本無法取得的，如一個公司的內部網絡，這樣的網絡對外人是不可進入的，即使用戶可以上網訪問，也要注意，用戶可以根本不可能上互聯網，這樣就不得不考慮使用這種方法的可行性了。雖然如此，仍然有許多用戶採用這種方法。 如果郵件內的內容包括了需要參照的對象（這時文件內可能包括許多種對象，HTML文檔，圖象，聲音等），這時就只能採用multipart/related形式發送了。這時文件的根部分應該是參照其它對象的部分，如一個HTML文檔，它就可以使用超級鏈接參照文件的其它部分。通常，我們把這樣的根部分放在文件的最前面，也就是根部分是第一個部分，如果不是，則應該使用Content-ID進行指示。如果在HTML文件中包括一些URI（也就是URL）指向的是一些不可知的程序，最好要發送前對它進行得寫。 一個對象體部分，如text/HTML，可以包括一些超級鏈接，這些鏈接指向的可能是本消息內的部分，當然也可能是網絡上的某種資源。無論是什麼東西，反正是要在用戶在線閱讀時顯示出的東西。爲了顯示這些對象，需要知道這些對象的位置，我們知道MIME文件是由許多對象部分組成的，如果鏈接的對象就在此消息內，這些被鏈接的對象應該是一個獨立的對象部分，每個這樣的部分都應該有Content-Location頭或Content-ID頭。接收方的郵件程序也應該支持這種文件內的鏈接方式。 當文件中有Content-Base頭時，應該先對它進行解析，然後再對HTML中的URL進行解析。在文件中如果使用了Content-ID頭，那麼Content-Location就不怎麼起作用了，因此下面兩句是同一個意思：
Content-ID: [email protected]
Content-Location: CID: [email protected]
下面我們來看一些例子，第一個例子中只包括HTML對象而沒有包括其它對象，如聲音，圖象等，這個文件中也有超級鏈接，但是如果想取和 級鏈接的東西就必須上網取得，在這個文件內是沒有需要的東西的。 From: [email protected]
To: [email protected]
Subject: A simple example
Mime-Version: 1.0
Content-Type: Text/HTML; charset=US-ASCII
<HTML>
<head></head>
<body>
<h1>Hi there!</h1>
An example of an HTML message.<p>
Try clicking <a href="http://www.resnova.com/">here.</a><p>
</body></HTML>
這個例子是文件中包括了一個GIF圖象，這個圖象使用的絕對地址；
From: [email protected]
To: [email protected]
Subject: A simple example
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo3*[email protected]
--boundary-example-1
Content-Type: Text/HTML;charset=US-ASCII
Content-ID: <foo3*[email protected]>
... 這裏可能是一個HTML文件，其中包括了下面的超級鏈接：
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif" ALT="IETF logo">
--boundary-example-1
Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
//上面是圖象的內容；
--boundary-example-1--
下面這個例子和上面的一樣，只不過使用了相對地址：
From: [email protected]
To: [email protected]
Subject: A simple example
Mime-Version: 1.0
Content-Base: http://www.ietf.cnri.reston.va.us
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
--boundary-example-1
Content-Type: Text/HTML; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
... 這裏可能是一個HTML文件，其中包括了下面的超級鏈接：
<IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
--boundary-example-1
Content-Location: /images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
//上面是圖象的內容；
--boundary-example-1--
下面的例子中使用了Content-ID頭：
From: [email protected]
To: [email protected]
Subject: A simple example
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1"; type=Text/HTML
--boundary-example-1
Content-Type: Text/HTML; charset=US-ASCII
... 這裏可能是一個HTML文件，其中包括了下面的超級鏈接：
<IMG SRC="cid:foo4*[email protected]" ALT="IETF logo">
--boundary-example-1
Content-ID: <foo4*[email protected]>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
//上面是圖象的內容；
--boundary-example-1--
在網絡上一定要考慮安全問題，這裏要考慮的安全問題主要是發送來的URI是不是真正代表一個通過HTTP協議訪問到的對象，在這方面沒有保證。我們在使用HTTP協議或FTP協議時，通常會緩存一些數據，這些數據保證下次再次訪問這個對象時不用從網絡上取得，而直接可以從本機上獲得，但是對於MIME文件來說，卻不能夠這樣做，因爲你無法保證這裏看到的東西和通過HTTP或FTP得到的對象是一致的。在發送HTML文件時，還有一些安全問題要考慮了，因爲在這些文件中可能有一些運行於服務器的代碼，這些代碼如果傳播出去可能造成的後果是無法想象的。而有一些HTML文件把口令和其它一些關鍵數據保存在裏面，如果不加處理直接發送，我想後果不用我多嘴你也能夠想得出來了。 | 
