"好，如何創(chuàng)建符合MIME的信息呢？"
　　通過(guò)上面的一般性的描述，讓我們現(xiàn)在看一下所謂的MIME信息到底是什么！

最簡(jiǎn)單的MIME信息
　　這個(gè)信息沒(méi)有任何段，也就是，沒(méi)有附件。然而，因?yàn)樗且粋€(gè)MIME消息，它必須有必要的頭。

From: php@php.net
To: 'Alex (the Great)' <alex@greece.net>
Subject: Bucephalus
MIME-Version: 1.0

Hello Alexander,

How's Bucephalus doing?

　　這里面沒(méi)有什么，它只是一個(gè)簡(jiǎn)單的擁有MIME頭的符合RFC-822 的信息（文本郵件）。注意，如果沒(méi)有
指定Content-Type頭，則假設(shè)為Content-Type: text/plain;charset='us-ascii'!當(dāng)然，它有些簡(jiǎn)單，復(fù)雜
一些的如下：

From: 'Alex (the Great)' <alex@greece.net>
To: php@php.net
Subject: re: Bucephalus
MIME-Version: 1.0
Content-Type: image/jpg;
name='buce.jpg'
Content-Transfer-Encoding: base64
Content-Description: Take a look at him yourself

<.....base64 encoded jpg image of Bucephalus...>

　　"嗨，但是我想發(fā)送一個(gè)word文檔和一張我的小狗的圖片在同一封郵件中... ！"一個(gè)用戶說(shuō)！如果是真
的，上面的那個(gè)例子就太簡(jiǎn)單了，并且它沒(méi)有足夠的內(nèi)容來(lái)支持愛(ài)好者和現(xiàn)代郵件處理方面的需要。實(shí)際上，
許多的郵件客戶端軟件甚至不能顯示描述字段！

　　這就是我們所面臨的"多部分信息"。

多部分信息（Multipart Messages）
　　這個(gè)概念允許在一封郵件中發(fā)送多條項(xiàng)目。例如，假設(shè)Alexander想要給php@php.net發(fā)送一封他的馬的
照片的郵件，同時(shí)還附帶有馬的家族圖譜及精彩的說(shuō)明！這樣一個(gè)簡(jiǎn)單的要求沒(méi)有多部分消息的概念是無(wú)法
被滿足的。在這種情況下，我們創(chuàng)建了一個(gè)使用Content-Type的信息頭的封裝來(lái)支持郵件的不同部分，以便
收信人得到圖片，家族圖譜和精彩的說(shuō)明！

　　Content-Type 頭現(xiàn)在擁有一個(gè)"multipart"的值，它表示這是一個(gè)完整的郵件信息并且這個(gè)頭只封裝了
信息。而且它還有一個(gè)"mixed"的子類型（畢竟圖片，家族圖譜和7bit文本信息是不同的類型，對(duì)嗎？）。

　　讓我們看一下整個(gè)圖片看上去象：

From: 'Alex (the Great)' <alex@greece.net>
To: php@php.net
Subject: re: Bucephalus
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="XX-1234DED00099A";
Content-Transfer-Encoding: 7bit

This is a MIME Encoded Message

--XX-1234DED00099A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi PHP,

Attached you will find my horse, Bucephalus', pedigree chart and photo.

Alex

--XX-1234DED00099A
Content-Type: image/jpg;
name="buce.jpg";
Content-Transfer-Encoding: base64
Content-Description: "A photo of Bucephalus"

<.....base64 encoded jpg image of Bucephalus...>

--XX-1234DED00099A
Content-Type: application/octet-stream;
name="pedigree.doc"
Content-Transfer-Encoding: base64
Content-Description: "Pedigree Chart of the great horse"

<.....base64 encoded doc (pedigree.doc) of Bucephalus...>

--XX-1234DED00099A--

　　喲，看上去很復(fù)雜，不是嗎？不管怎樣，讓我們?yōu)g覽一遍細(xì)節(jié)吧：

如果你注意到了在MIME信息頭中的Content-Transfer-Encoding，為"7bit"。因?yàn)镃ontent-Type為
multipart/mixed，編碼應(yīng)該是7bit，8bit或二進(jìn)制中的一種，7bit是一種廣泛使用的格式。
象這樣一條信息包含了多種信息?？蛻舫绦蚴侨绾沃繨PG圖片，文檔和普通文本之間的區(qū)別呢？你會(huì)
注意到在Content-Type后面有一個(gè)boundary="XX-1234DED00099A"參數(shù)。這個(gè)值用來(lái)分離郵件中的不同
部分。它叫做MIME邊界標(biāo)記。邊界標(biāo)記的值必須盡可能的唯一，以免在超出郵件范圍時(shí)發(fā)生混亂。
"警告"信息（譯者：指"This is a MIME Encoded Message"）在那里是為了讓不符合MIME的客戶程序
能夠把它顯示給用戶，否則他們就不理解一個(gè)空白郵件是什么意思。
現(xiàn)在，回到邊界標(biāo)記。如果你觀察這個(gè)簡(jiǎn)單的郵件，會(huì)發(fā)現(xiàn)邊界標(biāo)記（XX-1234DED00099A在每一個(gè)分
都出現(xiàn)了，也就是，在每部分之間都使用了一個(gè)邊界標(biāo)記，然而，每個(gè)邊界標(biāo)記都以兩個(gè)連接符開(kāi)始。
很重要的一點(diǎn)需要注意的就是在最后一個(gè)MIME段的后面，邊界標(biāo)記不僅僅以那兩個(gè)邊接符作為開(kāi)始，
同時(shí)也以它倆作為結(jié)束。這一點(diǎn)一定不能忘記，因?yàn)樗x了郵件的范圍。
讓我們看一下前兩個(gè)MIME段：
第一段是普通文本信息，因此Content-Type為text/plain，并且編碼為7bit（我們也可以省略它，
因?yàn)槿绻恢该魉矔?huì)默認(rèn)為如此）。
第二個(gè)就是JPEG圖片。相應(yīng)的表示為Content-Type: image/jpg。name="buce.jpg"（出現(xiàn)在
Content-Type的后面，稱之為參數(shù)），指出了文件的名字；它就是可以在客戶程序中看到的附件
的名字。如果不給出name="buce.jpg" ，描述字段（如果給出）將作為附件的名字顯示出來(lái)（然
而，在所有客戶程序中它不是統(tǒng)一的做法）。
注意JPEG 圖片可以在郵件件中被顯示出來(lái)，如果客戶程序可以顯示行內(nèi)附件?；蛘?，你可以向客戶程
指明你想如何顯示附件。例如，如果存在

Content-Disposition: attachment

頭，JPEG圖片將被顯示為一個(gè)附件圖標(biāo)。