此文章轉自他人，只是為了方便自己整理資料以及大家共同進步而發布。

轉自：http://www.cnblogs.com/likwo/archive/2011/08/15/2139903.html

信件的組成分為信封、信頭(標題)與信身，而且MIME(Multipurpose Internet Mail Extensions)的規格因為能傳送各種型態的資料與訊息，因此是目前最普方受歡迎的一種規範。底下我們將對MIME與Non-MINE的格式作說明。

信件標題
　　信件的標題欄位，在RFC 822中定義的非常地多，而我們最常用到的就是Dute：、Form：、To：、CC：、BCC：、Subject：，標題區與信件本文之間則是以一空白區隔，所以信頭(標題)各行欄位不應有空白行。
Date：寄件者寄信日期、時間。
From：寄件者的e-mail address。
To：收件者的e-mail address。
CC：副本收件者的e-mail位址。
BCC：密件副本收件者的e-mail位址。
Subject：主旨

MIME格式
?MIME格式宣告
　MIME格式必需在標題上有一個欄位宣告此信件為MIME格式，實際的作法就是在信頭上加上如下的一行欄位，宣告此文件是MIME的格式。
　MIME-Version:1.0

?Character Set(字元集)
　字元集是一個很重要的參數，它是代表著各種不同的語系，這個參數值會出現在標題或body part的字元集宣告。而在信頭區上，使用最多的就是Subject、From、To等欄位及信身本文的Conten-Type字元集宣告。其中最容易造成亂碼的就是Subject、From、To三個欄位的中文字串值，這些欄位本來在英語系國家使用上是沒有什麼問題，因為都在ASCII code(7bit)的標準顯示字元裡，但對雙位元組語系的國家，像我們使用中文字表達到Subject(主旨)、From(寄件者的Display name)、To(收件者的display name)上，如果Mail主機不支援8bit傳送，則會把第8位元濾掉，所以我們也必需要為這些字串做編碼，但是因為字串不比本文的文字那麼多，所在MIME裡就為這些在欄位裡使用的字串編碼特別定義了一組編碼表示式叫Encoded-word，也就是字串編碼表示式，如下：
=?<字集代碼>?<編碼方式>?<編碼>?<編碼後的值>?=

　　整個表示以”?=?”為開始而以”?=”為結束，其中的字集代碼在臺灣是big5、在中國大陸是bg2312，而編碼方式可分為QP(Quoted Printable)及Base64兩種，QP以”Q”表示，Base64則以”B”表示，字串經過編碼後則置於編碼方式之後的欄位。例如：
=?bit5?b?wcKq+Kn6?=

就是字串”謝長明”的Encoded word，經常表示於e-mail位址的Display name或者主旨欄位上。

　　Encode word表示式中的字集代碼就是用來表示此字串所使用的字集，這個代碼在英語系國家比較沒有什麼問題，但是在使用雙位元組的中國人來說，如果設定錯誤，就容易造成用戶端軟體如Outlook Express、Outlook 2000、Outlook 2002、Netscape communicator等，因為字元集的代碼不正確而顯示不正確的字元，也就是所謂的亂碼，這種現象尤其最容易發生在使用中文不完全相容的Mailer軟體，如Euodra英文版，預設的字元就是ISO-8859-1，而且在介面上無法更改它的字元集，因此當您使用MIME格式寄信時，如果Subject使用中文就會在標題區上的Subject、From、To之Encode Word上以ISO-8859-1字元集表示，這也就是造成Outlook 2002或Outlook Express、Netscape communicator等中文版相容軟體誤判的主因，這當然會造成亂碼了。當然了，如果你也是用Euodra、Pegaus等同類mailer軟體則不會有問題，不過目前這兩套mailer軟體，已有用心的人予以中文化，而且也將字元集更正為big5了，所以如果喜歡使用這兩套軟體的人，應使用中文化後的版本，較不會支援多國語系的mailer (Outlook 2000、Outlook Express、Netscape communicator)收件者看到主旨亂碼或者From(寄件者) 、To(收件者)欄位亂碼的問題。字元集的指定除了用在上面的例子外，另外就是在Content-Type上指定本文或附件所使用的字元集，我們將在下面有關Content-Type的說明中述及。

?Content-Transfer-Encoding(內容編碼)
　　編碼的方式分為7bit、8bit、binary、QP、Base64，而7bit、8bit、binary其實是沒有做編碼的處理，只是在傳送上的不同，而且7bit就是傳送7位元，而不將第8位元當成資料傳送，至於8bit則是會將第8位元當成資料的一部份傳送，但是並非所有的Mail系統都支援8bit，萬一沒有支援，那麼就不能使用8bit傳送，這種傳送會傳送CRLF換行字元，所以大部份應用在文字的傳送上，如主旨(Subject) 、寄件者(From) 、收件者(To)等欄位上的字串及信件的本文(text / plain)上。至於binary與8bit是很類似的，只不過它是以Stream的方式傳送，沒有CRLF。因此大部份是應用在執行檔及應用程式的編碼上。另外有關QP及Base64我們已經在前面說明過了，QP經常是用在本文及HTML的格式文件上。至於Base64則是各種型態的文件及媒體檔均會用上，也是使用在附件檔最多的一種編碼。而編碼的語法為：
Content-Transfer-Encoding:<編碼方式>
例如： Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: binary

?Content-Type
　　Content-Type是MIME定義本文及各個附件檔的內容型態最重要的一個參數，在RFC 2046裡共定義了5種個別的(text、image、audio、video、application)及2種合成(multipart、message)的Media type。
而這些Media type又分為各種的sub type，如表6-3、表6-4，宣告的語法為：
Content-Type: <Media-type / sub-type>; Charset=<字元集代碼>
例如： Content-type: text / plain; charseg=”big5”
Content-type: text / html; charset=”big5”

Text
此種media type是使用最多的一種，尤其是text / plain及text / html，一般的純文字本文或是附件檔，大部份是使用者text / plain，也就是沒有任何文字的格式(粗體、紅色文字……)，而至於text / html則是html格式表現。最常使用的編碼方式：7bit，若是中文且系統允許8bit傳送，則是Content-Trans Encoding: 8bit，而若是不允許8bit傳送，一般來說Outlook Express會要求以QP編碼也就是Content-Transfer-Encoding: quoted-printable，當然您也可以強制要求以base64來編碼。

Image
在RFC 1521定義了gif及jpeg和在RFC 1314定義了ief，而在RFC 1494則定義了g3fax等Message的sub-type。Gif及jpeg為使用最多的兩種image sub-type。一般是應用在圖檔。

Audio
在RFC 1521定義了sub-type basic，在RFC 2421、2422則定義了32Kadpcm，另外在RFC 2586定義L16。一般是應用在語音檔上。最常用的編碼方式為base64及binary。

Video
在RFC 1521定義了mpeg的sub-type。一般應用在影音檔上，而最常用的編碼方式為base64及binary。

Application
Application這個media-type是應用最為廣泛的，因為Application的成長快速，而每一家開發軟體的公司都可以依照RFC 2048的MIMI註冊程序向IANA(Internet Assigend Numbers Authority)註冊。一般若沒有註冊的格式，大部份會以application / octet-stream的Content-type表示之。最常用的編碼方式為base64及binary。

Multipart
Multipart這種Content-Type，一般是應用在含有多種型態的信件上，它的sub-type mixed及alternative是使用最多的兩種，mixed是指信身中含有各種型態的body part，而alternative則是應用在同一個body part而多種的表示格式，例如本文以content-type: text/plain及content-type: text/html表示，至於以合種型態呈現則是交由用戶端軟體(Outlook Express、Outlook xp、Netscape)自行判斷，以最好的方式表現之。
Multipart的宣告語法：
Content-Type: multipart / mized;
Boundary=”----=NextPart_000_00F9_01c10161.95F37360”

　　其中的Boundary字串則是為了區隔各body part而用，在每一個body part的開始均需以boundary字串在前端加上兩個”=”符號表示之，然後再最後的body part之底端也是以boundary字串符號及在字串的末端加上兩個”_”待號表示結束。

Content-Type: multipart/alternative;
Boundary=”----=_NetPart_001_00FA_01C10161.95F37360”

multipart / alternative的型態一般會與multipart / mixed一起使用，但它必需再為此body part定義一個boundary符號，當此body part結束後再回到原來的boundary符號。

Message
在RFC 1036裡定義news，RFC 1521定義了rfc822、partial、external-body等幾個Message / sub-type。在RFC 1894定義Delivery-status。在RFC 2068定義http，在RFC 2298定義Disposition-notification等message/sub-type。

Message/partial
其中message/partial則是定義了像在Outlook Express POP3/SMTP傳送大檔案時的分割傳送。它會將信件的內容分割成多份傳送，若對方也是利用Outlook Express的POP3接收時，那麼它會在所有被分割的多封信件自動組成一封完整的原信件，但若是使用Outlook 2002等MAPI-Base Client，則會出現一份一份的獨立信件。這種型態的每封信的信頭都會有Content-Type：message/partial的宣告，如圖6-004的樣式，而且也會隨著表明有多少份(total=3表示共有切割為三份)，然後有一id用來識別這些信件是同一份。

message/rfc822
至於message/rfc822的則是應用在以附件方式轉寄一份信件給他人時的常用的一種content-type，它在信件裡又包含了一封以rfc822定義的信件，內容一樣會包含有Date：、From：、To：等rfc822標準的信頭，也就是寄件中又包含另一封信件。如圖6-005，body part裡含有一封完整信的形式(通常以附件轉寄信件時所產生)。

總結

以上是生活随笔為你收集整理的Pop3得到的Email 信件格式介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。