電子郵件格式說(shuō)明_第1頁(yè)
電子郵件格式說(shuō)明_第2頁(yè)
電子郵件格式說(shuō)明_第3頁(yè)
已閱讀5頁(yè),還剩3頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、電子郵件格式說(shuō)明郵件格式說(shuō)明郵件格式說(shuō)明 21概述 32主體結(jié)構(gòu) 32.1郵件頭 31)長(zhǎng)字段的斷行32)字段主要結(jié)構(gòu) 43)郵件頭構(gòu)造協(xié)議 44)重要參數(shù)字段 52.2Content-type 字段 Multipart 類(lèi)型說(shuō)明 72.3 Content-type字段 Message類(lèi)型說(shuō)明郵件格式說(shuō)明Mutiple Internet Mail ExtensionsRefer to Internet Official Protocol Standards RFC 8221 概述網(wǎng)絡(luò)間傳遞的電子郵件需要公共認(rèn)同的格式,以便于客戶(hù)端郵箱軟件識(shí)別 拆解其間的信息。郵件本身是由 ASCII 字符構(gòu)成

2、,總體上分為郵件頭郵件體兩 部分,其間允許字符編碼、附件、壓縮等等多樣化的格式。本文檔參考網(wǎng)絡(luò)官 方協(xié)議標(biāo)準(zhǔn)中 , 請(qǐng)求批注的郵件相關(guān)條款,總結(jié)了郵件結(jié)構(gòu)及其各部分的格式說(shuō) 明,給出部分字符編碼的相關(guān)解釋。RFC( Require for comment ) 是 Internet Official Protocol Standards 標(biāo)準(zhǔn)所提供的網(wǎng)絡(luò)協(xié)議標(biāo)準(zhǔn)系列。2 主體結(jié)構(gòu)郵件結(jié)構(gòu)包括郵件頭、郵件體(可無(wú)) ,郵件體實(shí)際上是一行行的 ASCII 字 符構(gòu)成的簡(jiǎn)單序列, 它和郵件頭是靠一個(gè)空行 (該行只有一個(gè)回車(chē)換行符 CRLF) 來(lái)區(qū)分開(kāi)的。2.1 郵件頭1) 長(zhǎng)字段的斷行郵件頭由許多頭字

3、段 (header fields) 組成,這些字段包括字段名 (field name)和字段值(field body);字段值(field body)可以分割成多行表述,叫做“可折疊”。斷行的規(guī)則是:在一行的線性空格處,可用CRLF(回車(chē)換行)之后至少跟一個(gè)LWSP-char(空格或TAB),把原來(lái)的單行變?yōu)槎嘈斜硎尽FC協(xié)議中推薦盡量把折疊的斷行放置在特定的空格分隔處,比如,地址字段里的多個(gè)郵件地址,折疊時(shí)盡量在各地址之間,及逗號(hào)之后斷行。2) 字段主要結(jié)構(gòu)包括字段名 (Field name) ,冒號(hào) (colon) ,字段值 (Field body) ,結(jié)束符 (CRLF);有些字段屬于

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

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

6、”“with ”等是記錄變量。“Return-Path ” : 該字段由信息的最后發(fā)送者添加 , 是關(guān)于信息原始來(lái)源 的地址和回朔路徑。 Reply-To 字段是有信息源添加用來(lái)直接回復(fù)(地址?) ,而 Return-Path 是一個(gè)到信息原始來(lái)源的回朔路徑。“Received ” : 由每個(gè)中繼服務(wù)站添加,用于幫助追蹤傳輸中出現(xiàn)的錯(cuò)誤。 字段內(nèi)容包括,發(fā)送、接收的主機(jī)和接收時(shí)間。參數(shù) via 用于記錄信息發(fā)送后 經(jīng)過(guò)的物理站點(diǎn),” with ”指示了使用的郵件、連接的協(xié)議。參數(shù)id用于標(biāo)識(shí)郵件。參數(shù) for 用于記錄發(fā)送者的分發(fā)的目的地址。? 信息源的字段 -Originator Field

7、“From/Resent-From ” : 與 sender 必須至少存在一個(gè)。“Sender/Resent- Sender”“Reply-To/Resent-Reply- To” 當(dāng)自動(dòng)生成回復(fù)信息的地址列表時(shí),應(yīng)當(dāng)注意:如果沒(méi)有” Sender” ,將會(huì) 使用” From” . 接收者在回復(fù)信息時(shí),郵件 sender 中的信息不會(huì)被自動(dòng)使用。 如果” Reply-To ”字段存在,將使用該字段信息,而不是”From”字段。如果有” From” 而沒(méi)有” 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) 重要參數(shù)字段a) “MIME-Version” : 所使用的網(wǎng)絡(luò)郵件格式標(biāo)準(zhǔn)版本b) “Content -type ”郵件內(nèi)容數(shù)據(jù)的類(lèi)型,包括類(lèi)型標(biāo)識(shí) (type) 和子類(lèi)型標(biāo)識(shí) (subtype) ,前者 類(lèi)型標(biāo)識(shí) (type) 聲明了數(shù)據(jù)的類(lèi)型,后者子類(lèi)型標(biāo)識(shí) (subtype) 為這種數(shù)據(jù)類(lèi)型 指定了特定的格式。比如 content-type:image/xyz; 說(shuō)明數(shù)據(jù)類(lèi)型是圖像型

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

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

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

12、類(lèi)型。當(dāng)遇到未知的類(lèi)型時(shí),將會(huì)把未知類(lèi)型當(dāng)作” application/octet-stream ” 對(duì)待。c) Content-Transfer-Encoding 頭字段許多郵件內(nèi)容是以最原始的格式傳輸?shù)模?8位字符或二進(jìn)制數(shù)據(jù), 但對(duì)于有 些協(xié)議這種格式數(shù)據(jù)就不能正確傳輸了。例如 RFC821限制messages必須為7 位 US-ASCII 數(shù)據(jù),而且每行不能超過(guò) 1 000個(gè)字符。因此,有必要定義機(jī)制來(lái)把數(shù)據(jù)編碼成 7 位短行格式。編碼的目的就是用 網(wǎng)絡(luò)可以傳輸?shù)姆绞絹?lái)表達(dá)郵件內(nèi)容。Content-Transfer-Encoding 實(shí)際上就是在類(lèi)型數(shù)據(jù)的本地表述和用 7位郵 件傳輸協(xié)

13、議轉(zhuǎn)化的表述之間的一種映射,比如協(xié)議 RFC821(SMTP)該字段的值 就是指定編碼類(lèi)型的一種標(biāo)識(shí)。其值如下:7bit“7bit ” , ” 8bit ” , “quoted -printable ” , “base64” , “binary ” , “x- token ”標(biāo)識(shí)不區(qū)分大小寫(xiě),如果沒(méi)有明確指定,該字段的默認(rèn)值是”若值是” 8bit ”, ” 7bit ”或” binary ”時(shí),表示沒(méi)有做任何編碼。 (繼續(xù) 翻譯)2.2 Content-type 字段 Multipart 類(lèi)型說(shuō)明所有帶前綴” Content- ”的字段對(duì)正文都定義有含義,而其他得頭字段一 般都被郵件體部分忽略

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

15、況下,這種用法也不一定適用。封裝部分的結(jié)尾, boundary 和前面的使用格式一樣的情況下,后面再加兩 個(gè)” - ”的形式表示。Content-type 字段參數(shù)的語(yǔ)法是把 boundaries 的值包含在引號(hào)之中。 也可 以沒(méi)有引號(hào),但又引號(hào)是最保險(xiǎn)的。有一些非法字符會(huì)出現(xiàn)在 boundary 值中, 如果不加引號(hào)會(huì)引起錯(cuò)誤。注意封裝邊界必須在行的開(kāi)始,后面是回車(chē)換行 CRLF幵頭的CRLF會(huì)被當(dāng) 作邊界的一部分,而不是上一塊內(nèi)容的一部分。邊界后面跟一個(gè)CRLF和下一部分的郵件頭字段,或者,兩個(gè) CRLF這種情況下不會(huì)有細(xì)一部分的郵件頭。在邊界之間(子部分頭一個(gè) boundary 和上一部

16、分結(jié)尾 boundary 之間或者 正文第一個(gè)邊界之前郵件頭之后) ,會(huì)有一些可添加額外信息的空白空間,這些 空間郵件解析時(shí)會(huì)略過(guò)。Multipart 子類(lèi)型的簡(jiǎn)要介紹:Mixed: 表示個(gè)子部間互相獨(dú)立,需要以特定的順序排列。Alternative: 每一子部分的是相同信息的不同版本,各部分排序,最優(yōu)的 排在最后,但優(yōu)先使用。Digest:將子部分默認(rèn)成message來(lái)處理。Parallel: 同時(shí)顯示多個(gè)子部2.3 Content-type 字段 Message 類(lèi)型說(shuō)明在發(fā)送郵件時(shí),該類(lèi)型會(huì)頻繁使用來(lái)封裝子 mail 郵件。通常的子類(lèi)型是 message/rfc822 ,該類(lèi)型下沒(méi)有必須

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

18、。2) message/partial有些郵件發(fā)送機(jī)構(gòu)限制郵件發(fā)送的大小,這樣,大的郵件對(duì)象( vedio 等) 必須分成多部分發(fā)送。 “ message/partial ”說(shuō)明該郵件體包含了一個(gè)大郵件的 一段。該類(lèi)型需要 3 個(gè)參數(shù):Id, 盡可能保持唯一性,為了把各部組合到一起。Number該部分在整體序列中的編號(hào)。Total, 所分部分的總數(shù),該參數(shù)一般在最后一部分出現(xiàn)。發(fā)送大郵件諸如 vedio 文件時(shí),由于文件太大,超出單次發(fā)送限制,需要 把文件分割成多個(gè)部分。基本過(guò)程是,把vedio類(lèi)型的message,分割成多個(gè)單獨(dú)的 vedio 類(lèi)型的 message,每個(gè)部分再由” message/partial ” 類(lèi)型的 message 封裝起來(lái),并添加分段信息。當(dāng)接收方收到該message時(shí),各段落會(huì) 根據(jù)分割信息重

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論