郵件格式說明

Mutiple Internet Mail Extensions

Refer to Internet Official Protocol Standards RFC 822

1 概述

網絡間傳遞的電子郵件需要公共認同的格式，以便于客戶端郵箱軟件識別拆解其間的信息。郵件本身是由ASCII字符構成，總體上分為郵件頭郵件體兩部分，其間允許字符編碼、附件、壓縮等等多樣化的格式。本文檔參考網絡官方協議標準中,請求批注的郵件相關條款，總結了郵件結構及其各部分的格式說明，給出部分字符編碼的相關解釋。

RFC( Require for comment )是Internet Official Protocol Standards標準所提供的網絡協議標準系列。

2 主體結構

郵件結構包括郵件頭、郵件體（可無），郵件體實際上是一行行的ASCII字符構成的簡單序列，它和郵件頭是靠一個空行（該行只有一個回車換行符CRLF）來區分開的。

2.1 郵件頭

1) 長字段的斷行

郵件頭由許多頭字段(header fields)組成，這些字段包括字段名(field name)和字段值(field body)；字段值(field body)可以分割成多行表述，叫做“可折疊”。

斷行的規則是：在一行的線性空格處，可用CRLF（回車換行）之后至少跟一個LWSP-char(空格或TAB)，把原來的單行變為多行表示。

RFC協議中推薦盡量把折疊的斷行放置在特定的空格分隔處，比如，地址字段里的多個郵件地址，折疊時盡量在各地址之間，及逗號之后斷行。

2) 字段主要結構

包括字段名(Field name)，冒號(colon)，字段值(Field body)，結束符（CRLF）；

有些字段屬于結構化字段，比如日期(Date)，郵件地址(Address)，有著特定的表示格式，用于系統識別。而其他字段比如”Subject” “Comments”都被當作簡單的字符串處理。

字段表示：

field-name ":" [ field-body ] CRLF

字段值(Field body)可斷行（見1）），內容全部都是ASCII碼，元素包括句號，引用字符串，特殊token，或一般文本。字段的含義參見后文附錄。

3) 郵件頭構造協議

郵件頭字段不是必須按照特定的順序安排，僅僅是注意要把郵件體放在郵件頭之后。郵件協議中推薦的做法是在放置郵件字段時，郵件按照以下順序安排：”Return-Path”, “Received”, “Date”, “From”, “Subject”, “Sender”, “To”, “cc”,等等。

郵件協議中規定郵件由字段和郵件體正文組成，兩部分之間由一個空行（該行只有包含CRLF）分隔，也就是說，在遇見的第一個空行之后所有的內容都被當作郵件體。

? 轉發-Forwarding

一些系統允許接受者轉發信息，保留原有的郵件頭，僅添加些新的字段，這些字段以”Resent-”為前綴。及前綴”Resent-”的字段表示接受者轉發的原信息。

? 路徑字段-Trace Field

路徑信息用來追蹤信息的發送者，”via” “with”等是記錄變量。

“Return-Path” :該字段由信息的最后發送者添加,是關于信息原始來源的地址和回朔路徑。Reply-To字段是有信息源添加用來直接回復（地址？），而Return-Path是一個到信息原始來源的回朔路徑。

“Received” :由每個中繼服務站添加，用于幫助追蹤傳輸中出現的錯誤。字段內容包括，發送、接收的主機和接收時間。參數via用于記錄信息發送后經過的物理站點，”with”指示了使用的郵件、連接的協議。參數id用于標識郵件。參數for用于記錄發送者的分發的目的地址。

? 信息源的字段-Originator Field

“From/Resent-From” :與sender必須至少存在一個。

“Sender/Resent-Sender”

“Reply-To/Resent-Reply-To”

當自動生成回復信息的地址列表時，應當注意：如果沒有”Sender”，將會使用”From” .接收者在回復信息時，郵件sender中的信息不會被自動使用。如果”Reply-To”字段存在，將使用該字段信息，而不是”From”字段。如果有”From”而沒有”Reply-To”，將使用”From”。

? 接收者字段-Receiver Field

“To/Resent-To”

“Cc/Resent-Cc”

“Bcc/Resent-Bcc”

? 參考字段

“Message-ID/Resent-Message-ID”

“In-Reply-To”

“Reference”

“Keywords”

4) 重要參數字段

a) “MIME-Version” :所使用的網絡郵件格式標準版本

b) “Content-type”

郵件內容數據的類型，包括類型標識(type)和子類型標識(subtype)，前者類型標識(type)聲明了數據的類型，后者子類型標識(subtype)為這種數據類型指定了特定的格式。

比如content-type:image/xyz;說明數據類型是圖像型(image)的，圖像數據格式是xyz。

類型標識(type)與子類型標識(subtype)由斜杠”/”來分割。

類型之后是參數集合parameter。

郵件的數據類型分為七種，分別是:文本(Text)、多文檔(mulipart)、消息(Message)、圖像(Image)、音頻(audio)、視頻(Video)、應用(Application)。

文本(Text)—文字類信息，其基本的子類標識是”Plain”，即沒有格式的文本。除了需要支持指定的字符集，獲得文本信息不需要特殊的軟件。文本子類用于多信息文本，在其上應用文字處理軟件可以美化文本的外觀，但文本的內容及涵義無需任何軟件。因此子類型包括任何可讀得文字處理格式。

多文檔(mulipart) —包含具有獨立數據類型的多個部分。其中定義了4個最原始的子類型：mixed(基本類型), alternative(具有可供選擇的多個格式), parallel(同時閱覽的部分), digest(都是消息型的多部內容).

消息(Message) –未封裝的消息。該類型的消息體本身部分或全部都是RFC822格式。基本子類是” rfc822”。”partial”表示局部消息，允許郵件傳輸中可分塊進行。”External-body”表示擴展大郵件。

圖形(Image) –需要有現實設備。子類主要是兩種應用廣泛的圖形格式：jpeg, gif。

聲頻(audio) –基本子類”basic”,需要聲頻輸出設備。

視頻(Video) –基本子雷”mpeg”,需要視頻顯示設備。

應用(Application) –其他類型數據，無法解析的二進制數據。基本子類”octet-stream”，用于不可解析的二進制數據情況，為用戶提供將信息寫入文件的方法。”PostScript”表示傳輸腳本文檔。

Content-type類型默認為Content-type : text/plain; charset = us-ascii。如果content-type沒有明確制定，那么系統會默認為該類型。

當遇到未知的類型時，將會把未知類型當作”application/octet-stream”對待。

c) Content-Transfer-Encoding頭字段

許多郵件內容是以最原始的格式傳輸的，8位字符或二進制數據，但對于有些協議這種格式數據就不能正確傳輸了。例如RFC821限制messages必須為7位US-ASCII數據，而且每行不能超過1000個字符。

因此，有必要定義機制來把數據編碼成7位短行格式。編碼的目的就是用網絡可以傳輸的方式來表達郵件內容。

Content-Transfer-Encoding實際上就是在類型數據的本地表述和用7位郵件傳輸協議轉化的表述之間的一種映射，比如協議RFC821(SMTP)。該字段的值就是指定編碼類型的一種標識。

其值如下：

“7bit”,”8bit”, “quoted-printable”, “base64”, “binary”, “x-token”

標識不區分大小寫，如果沒有明確指定，該字段的默認值是”7bit”。

若值是”8bit”,”7bit”或”binary”時，表示沒有做任何編碼。（繼續翻譯）

2.2 Content-type字段Multipart類型說明

所有帶前綴”Content-”的字段對正文都定義有含義，而其他得頭字段一般都被郵件體部分忽略。

協議中指出，在multipart的情況下,即多個不同的數據集合合并在同一郵件體內，此時頭字段中”multipart”參數值必須存在。這時郵件體必定存在一個或多個子部分，每一個子部分都會由邊界(boundary)封裝,而且最后一個子部分后面必須跟一個結尾邊界。每一部分都會由邊界開始，然后包含著郵件子體的頭信息（header），空行，然后是郵件正文。

如果沒有填寫content-type的頭字段，那就是暗示相應的郵件體時US-ASCII的普通text/plain文本。

Boundary在作為邊界值封裝郵件時，其使用方法是值前加兩個”-”。在一些特殊情況下，這種用法也不一定適用。

封裝部分的結尾，boundary和前面的使用格式一樣的情況下，后面再加兩個”-”的形式表示。

Content-type字段參數的語法是把boundaries的值包含在引號之中。也可以沒有引號，但又引號是最保險的。有一些非法字符會出現在boundary值中，如果不加引號會引起錯誤。

注意封裝邊界必須在行的開始，后面是回車換行CRLF,開頭的CRLF會被當作邊界的一部分，而不是上一塊內容的一部分。邊界后面跟一個CRLF和下一部分的郵件頭字段，或者，兩個CRLF，這種情況下不會有細一部分的郵件頭。

在邊界之間（子部分頭一個boundary和上一部分結尾boundary之間或者正文第一個邊界之前郵件頭之后），會有一些可添加額外信息的空白空間，這些空間郵件解析時會略過。

Multipart子類型的簡要介紹：

Mixed:表示個子部間互相獨立，需要以特定的順序排列。

Alternative:每一子部分的是相同信息的不同版本，各部分排序，最優的排在最后，但優先使用。

Digest:將子部分默認成message來處理。

Parallel:同時顯示多個子部

2.3 Content-type字段Message類型說明

在發送郵件時，該類型會頻繁使用來封裝子mail郵件。通常的子類型是message/rfc822，該類型下沒有必須添加的參數。額外的子類型”partial”和”External-body ”，需要必要的參數。

編碼方面，該類型只允許”7bit” “8bit”或”binary”。message的頭字段通常是US_ASCII的，message體內可以按照其自身的content-transfer-encoding字段值進行編碼。

1）message/rfc822

該類型是rfc822協議的message。但不必和最外層的rfc822 message那樣有from, subject,以及目的字段。該類型可以由高版本的郵件替換，及兼容MIME message。

2）message/partial

有些郵件發送機構限制郵件發送的大小，這樣，大的郵件對象（vedio等）必須分成多部分發送。“message/partial”說明該郵件體包含了一個大郵件的一段。該類型需要3個參數：

Id,盡可能保持唯一性，為了把各部組合到一起。

Number,該部分在整體序列中的編號。

Total,所分部分的總數，該參數一般在最后一部分出現。

發送大郵件諸如vedio文件時，由于文件太大，超出單次發送限制，需要把文件分割成多個部分。基本過程是，把vedio類型的message,分割成多個單獨的vedio類型的message,每個部分再由”message/partial”類型的message封裝起來，并添加分段信息。

當接收方收到該message時，各段落會`根據分割信息重新組合起來，新的信息僅是vedio類型，即去掉了外層的”message”類型封裝。

組合原則：

(1) 拷貝第一部分的外層” message/partial”的頭信息，除了”content-”，”message-id”，”Encrypted”，”MIME-Version”，其它為必拷貝信息

(2) 把內層的封裝信息的”content-”，”message-id”，“Encrypted”，“MIME-Version”的頭信息全部拷貝到新message中。

(3) 第二部分和以后部分的頭信息全部忽略。

名詞解釋（Word Description）

RFC: Request For Common(Internet Official Protocol Standard)

CRLF:Carriage-return/Line-feed

總結

以上是生活随笔為你收集整理的MIME格式说明，电子邮件格式(转载)的全部內容，希望文章能夠幫你解決所遇到的問題。

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