1、電子郵件格式說明郵件格式說明郵件格式說明 21概述 32主體結構 32.1郵件頭 31）長字段的斷行32）字段主要結構 43）郵件頭構造協議 44）重要參數字段 52.2Content-type 字段 Multipart 類型說明 72.3 Content-type字段 Message類型說明郵件格式說明Mutiple Internet Mail ExtensionsRefer to Internet Official Protocol Standards RFC 8221 概述網絡間傳遞的電子郵件需要公共認同的格式，以便于客戶端郵箱軟件識別 拆解其間的信息。郵件本身是由 ASCII 字符構成

2、，總體上分為郵件頭郵件體兩 部分，其間允許字符編碼、附件、壓縮等等多樣化的格式。本文檔參考網絡官 方協議標準中 , 請求批注的郵件相關條款，總結了郵件結構及其各部分的格式說 明，給出部分字符編碼的相關解釋。RFC( Require for comment ) 是 Internet Official Protocol Standards 標準所提供的網絡協議標準系列。2 主體結構郵件結構包括郵件頭、郵件體(可無) ，郵件體實際上是一行行的 ASCII 字 符構成的簡單序列， 它和郵件頭是靠一個空行 (該行只有一個回車換行符 CRLF) 來區分開的。2.1 郵件頭1) 長字段的斷行郵件頭由許多頭字

3、段 (header fields) 組成，這些字段包括字段名 (field name)和字段值(field body);字段值(field body)可以分割成多行表述，叫做“可折疊”。斷行的規則是：在一行的線性空格處，可用CRLF(回車換行)之后至少跟一個LWSP-char(空格或TAB)，把原來的單行變為多行表示。RFC協議中推薦盡量把折疊的斷行放置在特定的空格分隔處，比如，地址字段里的多個郵件地址，折疊時盡量在各地址之間，及逗號之后斷行。2) 字段主要結構包括字段名 (Field name) ，冒號 (colon) ，字段值 (Field body) ，結束符 (CRLF)；有些字段屬于

4、結構化字段，比如日期 (Date) ，郵件地址 (Address) ，有著特 定的表示格式，用于系統識別。而其他字段比如” Subject ” “ Comment”s 都 被當作簡單的字符串處理。字段表示：field-name : field-body CRLF字段值(Field body)可斷行(見1),內容全部都是ASCII碼，元素包括句 號，引用字符串，特殊 token ，或一般文本。字段的含義參見后文附錄。3) 郵件頭構造協議郵件頭字段不是必須按照特定的順序安排，僅僅是注意要把郵件體放在郵 件頭之后。郵件協議中推薦的做法是在放置郵件字段時，郵件按照以下順序安 排：” Retur n-P

5、ath ”， “ Received ”， “ Date”， “ From”， “ Subject ”， “ Sen der ”， “ To” ，“ cc” ， 等等。郵件協議中規定郵件由字段和郵件體正文組成， 兩部分之間由一個空行 (該 行只有包含CRLF分隔，也就是說，在遇見的第一個空行之后所有的內容都被 當作郵件體。? 轉發 -Forwarding一些系統允許接受者轉發信息，保留原有的郵件頭，僅添加些新的字段， 這些字段以” Resent- ”為前綴。及前綴” Resent- ”的字段表示接受者轉發的 原信息。? 路徑字段 -Trace Field路徑信息用來追蹤信息的發送者，” via

6、”“with ”等是記錄變量。“Return-Path ” : 該字段由信息的最后發送者添加 ， 是關于信息原始來源 的地址和回朔路徑。 Reply-To 字段是有信息源添加用來直接回復(地址？) ，而 Return-Path 是一個到信息原始來源的回朔路徑。“Received ” : 由每個中繼服務站添加，用于幫助追蹤傳輸中出現的錯誤。 字段內容包括，發送、接收的主機和接收時間。參數 via 用于記錄信息發送后 經過的物理站點，” with ”指示了使用的郵件、連接的協議。參數id用于標識郵件。參數 for 用于記錄發送者的分發的目的地址。? 信息源的字段 -Originator Field

7、“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/Resen

8、t- Cc”“Bcc/Resent- Bcc”rpZL? 參考字段“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; 說明數據類型是圖像型

9、 (image) 的，圖像數 據格式是 xyz 。類型標識 (type) 與子類型標識 (subtype) 由斜杠” / ”來分割。類型之后是參數集合 parameter 。郵件的數據類型分為七種，分別是：文本(Text)、多文檔(mulipart)、消息 (Message)、圖像(Image)、音頻(audio)、視頻(Video)、應用(Application)。文本 (Text) 文字類信息，其基本的子類標識是” Plain ”，即沒有格式的 文本。除了需要支持指定的字符集，獲得文本信息不需要特殊的軟件。文本子 類用于多信息文本，在其上應用文字處理軟件可以美化文本的外觀，但文本的 內容及

10、涵義無需任何軟件。因此子類型包括任何可讀得文字處理格式。多文檔 (mulipart) 包含具有獨立數據類型的多個部分。其中定義了 4 個 最原始的子類型： mixed( 基本類型 ), alternative( 具有可供選擇的多個格式 ), parallel( 同時閱覽的部分 ), digest( 都是消息型的多部內容 ).消息(Message)-未封裝的消息。該類型的消息體本身部分或全部都是RFC822格式。基本子類是”rfc822 ”。” partial ”表示局部消息，允許郵件傳輸中可分塊進行。” External-body ”表示擴展大郵件。圖形(Image)-需要有現實設備。子類主要

11、是兩種應用廣泛的圖形格式：jpeg, gif 。聲頻(audio)-基本子類” basic ” ,需要聲頻輸出設備。視頻(Video)-基本子雷” mpeg ,需要視頻顯示設備。應用(Application)-其他類型數據，無法解析的二進制數據。基本子類”octet-stream ”，用于不可解析的二進制數據情況，為用戶提供將信息寫入文件 的方法。” PostScript ”表示傳輸腳本文檔。Content-type 類 型 默 認 為 Content-type : text/plain; charset = us-ascii 。如果 content-type 沒有明確制定，那么系統會默認為該

12、類型。當遇到未知的類型時，將會把未知類型當作” application/octet-stream ” 對待。c) Content-Transfer-Encoding 頭字段許多郵件內容是以最原始的格式傳輸的， 8位字符或二進制數據， 但對于有 些協議這種格式數據就不能正確傳輸了。例如 RFC821限制messages必須為7 位 US-ASCII 數據，而且每行不能超過 1 000個字符。因此，有必要定義機制來把數據編碼成 7 位短行格式。編碼的目的就是用 網絡可以傳輸的方式來表達郵件內容。Content-Transfer-Encoding 實際上就是在類型數據的本地表述和用 7位郵 件傳輸協

13、議轉化的表述之間的一種映射，比如協議 RFC821(SMTP)該字段的值 就是指定編碼類型的一種標識。其值如下：7bit“7bit ” , ” 8bit ” , “quoted -printable ” , “base64” , “binary ” , “x- token ”標識不區分大小寫，如果沒有明確指定，該字段的默認值是”若值是” 8bit ”, ” 7bit ”或” binary ”時，表示沒有做任何編碼。 （繼續 翻譯）2.2 Content-type 字段 Multipart 類型說明所有帶前綴” Content- ”的字段對正文都定義有含義，而其他得頭字段一 般都被郵件體部分忽略

14、。協議中指出，在 multipart 的情況下 , 即多個不同的數據集合合并在同一郵 件體內，此時頭字段中” multipart ”參數值必須存在。這時郵件體必定存在一 個或多個子部分，每一個子部分都會由邊界 （boundary） 封裝, 而且最后一個子部 分后面必須跟一個結尾邊界。每一部分都會由邊界開始，然后包含著郵件子體 的頭信息（ header ），空行，然后是郵件正文。如果沒有填寫 content-type 的頭字段，那就是暗示相應的郵件體時 US-ASCII 的普通 text/plain 文本。Boundary 在作為邊界值封裝郵件時，其使用方法是值前加兩個” - ”。在一 些特殊情

15、況下，這種用法也不一定適用。封裝部分的結尾， boundary 和前面的使用格式一樣的情況下，后面再加兩 個” - ”的形式表示。Content-type 字段參數的語法是把 boundaries 的值包含在引號之中。 也可 以沒有引號，但又引號是最保險的。有一些非法字符會出現在 boundary 值中， 如果不加引號會引起錯誤。注意封裝邊界必須在行的開始，后面是回車換行 CRLF幵頭的CRLF會被當 作邊界的一部分，而不是上一塊內容的一部分。邊界后面跟一個CRLF和下一部分的郵件頭字段，或者，兩個 CRLF這種情況下不會有細一部分的郵件頭。在邊界之間（子部分頭一個 boundary 和上一部

16、分結尾 boundary 之間或者 正文第一個邊界之前郵件頭之后） ，會有一些可添加額外信息的空白空間，這些 空間郵件解析時會略過。Multipart 子類型的簡要介紹：Mixed: 表示個子部間互相獨立，需要以特定的順序排列。Alternative: 每一子部分的是相同信息的不同版本，各部分排序，最優的 排在最后，但優先使用。Digest:將子部分默認成message來處理。Parallel: 同時顯示多個子部2.3 Content-type 字段 Message 類型說明在發送郵件時，該類型會頻繁使用來封裝子 mail 郵件。通常的子類型是 message/rfc822 ，該類型下沒有必須

17、添加的參數。 額外的子類型” partial ”和” External-body ”，需要必要的參數。編碼方面，該類型只允許” 7bit ”“8bit 或” binary ”。message的頭字段 通 常 是 US_ASCII 的 ， message 體 內 可 以 按 照 其 自 身 的 content-transfer-encoding 字段值進行編碼。1) message/rfc822該類型是rfc822協議的message但不必和最外層的rfc822 message那樣 有 from, subject, 以及目的字段。 該類型可以由高版本的郵件替換， 及兼容 MIME message

18、。2) message/partial有些郵件發送機構限制郵件發送的大小，這樣，大的郵件對象( vedio 等) 必須分成多部分發送。 “ message/partial ”說明該郵件體包含了一個大郵件的 一段。該類型需要 3 個參數：Id, 盡可能保持唯一性，為了把各部組合到一起。Number該部分在整體序列中的編號。Total, 所分部分的總數，該參數一般在最后一部分出現。發送大郵件諸如 vedio 文件時，由于文件太大，超出單次發送限制，需要 把文件分割成多個部分。基本過程是，把vedio類型的message,分割成多個單獨的 vedio 類型的 message,每個部分再由” message/partial ” 類型的 message 封裝起來，并添加分段信息。當接收方收到該message時，各段落會 根據分割信息重