本備忘錄的狀態
本文檔描述了用于Internet交流的Internet標準路徑協議的規范,還需要討論和建議來改
進.請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程度和狀態。
本備忘錄的發布不受任何限制。
摘要
STD11,RFC882定義了一種信息表示協議,該協議規定了US-ASCII格式信息頭的具體細
節,但是信息內容或者信息體仍是flatUS-ASCIItext.本文檔和其他一系列文檔一起稱為
MIME,重新定義了答應的信息格式.
(1)非US-ASCII的字符集的文本報文主體
(2)非文本報文主體的不同格式的擴展集
(3)多部分報文主體
(4)除了US-ASCII的字符集的文本報頭信息
這一整套文檔基于更早的文檔RFC934和RFC1049,但對它們進行了擴展和修正.由于
RFC822對報文主體涉及太少,所以這些文檔大多數和RFC822是沒有關系的.
RFC2045是這套文檔中的最初的文檔,它規定了用于描述MIME消息結構的多種報頭.
第二個文檔定義了MIME媒體類型系統的總體結構并且定義了媒體類型的初始集.第三個文
檔是RFC2047,它擴展了RFC822,答應在Internet郵件頭域中有非US-ASCII文本.第四個文檔
RFC2048說明了與MIME相關設備的多種注冊程序.第五個也是最后一個文檔RFC2049描述了
MIME一致性標準,同時提供了一些關于ＭＩＭＥ消息格式的說明性的例子,還有感謝和參考
數目.
這些文檔都是RFC1521和RFC1522的修正版,RFC1521和1522又是RFC1341和1342
的修訂版.在RFC2049中的附錄描述了和以前版本的不同和變化.


目錄
1.介紹 3
2．頂層媒體類型的定義 3
3．初始頂層媒體類型的概述 3
4．離散的媒體類型值 4
4.1文本（Text）媒體類型 4
4.1.1換行的表示 5
4.1.2字符集參數 5
4.1.3.Plain(純文本)子類型 7
4.1.4.Unrecognized（未被承認的）子類型 7
4.2.ImageMediaType（圖象類型） 7
4.3.AudioMediaType（音頻類型） 7
4.4.VideoMediaType（視頻類型） 8
4.5.applicationMediaType（應用類型） 8
4.5.1.Octet-StreamSuBType（8bit子節流子類型） 8
4.5.2.PostScriptSubtype（標注類型） 9
4.5.3.其它application的子類型 10
5.CompositeMediaTypeValues（復合類型值） 10
5.1.MultipartMediaType（多部分類型） 10
5.1.1.CommonSyntax（共同語法） 11
5.1.2處理嵌套的報文和multiparts（多部分） 14
5.1.3Mixed子類型 15
5.1.4alternative子類型 15
5.1.5Digest子類型 16
5.1.6.Parallel子類型 17
5.1.7其他的Multipart子類型 18
5.2.報文媒體類型 18
5.2.1RFC822子類型 18
5.2.2Partial子類型 18
5.2.2.1報文分段和重組 19
5.2.2.2分割和重組實例 20
5.2.3External-Body(外部主體)子類型 21
5.2.3.1.普通external-body(外部主體)參數 22
5.2.3.2'FTP'and'tftp'access-Types(訪問類型) 22
5.2.3.3'anon(匿名)-ftp'訪問類型 23
5.2.3.4'local-file(本地文件)'訪問類型 23
5.2.3.5'mail-server(郵件服務)'訪問類型 23
5.2.3.6External-body(外部主體)安全問題 24
5.2.3.7實例與深入說明 24
5.2.4其他message(報文)子類型 26
7.總結 26
8.安全性考慮 26
9.作者地址 26
附錄A：語法集 27

1.介紹
在這套文檔的第一個文檔RFC2045中,定義了許多報頭域,包括
Content-Type.Content-Type域用來指定一個MIME實體中主體的數據類型,給出它的媒體類
型和子類型,并提供特定的媒體類型可能需要的輔助信息.報文頭的余下部分只是一個參數
集,指定了一個屬性/屬性值符號.參數的次序是不重要的.
一般來說,頂層(top-level)媒體類型用來聲明數據總的類型,而子類型指定了這一類型
的格式.因此,一個媒體類型“image/xyz"足以告訴用戶數據是一幅圖象,即使用戶沒有關于
特定的圖象格式“xyz"的知識.例如,這些信息可以用來決定是否給用戶看不被承認子類型
的原始數據—這個動作對于“text"的未被承認（unrecognized）的子類型可能是合理的，
但對于“image”或“audio"的未被承認(unrecognized)的子類型是不合理的。由于這個原
因，"text","image","audio",和"video"的注冊子類型不應該包含其他類型的信息。這
種混合的格式應該使用"multipart"或"application"類型來表示。
參數是媒體子類型的修飾部分，不會從本質上影響內容的種類。這組有意義的參數依靠
于媒體類型和子類型。大多數參數和一種特定的子類型相關聯。但是，一種給定的頂層媒體
類型可能定義一些參數，這些參數適用于這一類型的所有子類型。參數可能是定義的媒體類
型或子類型必選的，也可能是可選擇的。MIME實現還必須忽略名字不被承認的所有參數。
MIME的Content-Type報頭域和媒體類型機制可以很好的擴展，我們希望媒體類型/子
類型對和他們相關聯參數集合可以隨著時間顯著增長。MIME的一些其他功能，如轉換代碼
和"message/external-body"訪問類型隨著時間發展很可能定義新的值，為了確保這套屬性
值的發展有序，規范，風格一致，MIME建立了一個登記程序，他使用IANA（InternetAssigned
NumbersAuthority）作為MIME各個方面擴展的中心登記處。這個登記程序在RFC2048中進
行了描述。
本文檔的余下部分將定義和描述最初的七個標準頂層媒體類型。
2．頂層媒體類型的定義
頂層媒體類型的定義包括：
（1） 類型名字和描述，包括這一類型下是否某一特定類型被限制的標準
（2） 參數名字和定義，這些參數為這一類型的所有子類型所定義（包括這些參數是否是
必需的還是可選的）
（3） 用戶或網關如何處理這一類型的未知子類型
（4） 這一頂層類型的網關實體的總體考慮
（5） 這一頂層類型實體內容和編碼轉換（content-transfer-encodings）的所有限制
3．初始頂層媒體類型的概述
五種離散的頂層媒體類型是：
（1） text—文本信息。非凡地，子類型“plain”表示包含各種無格式命令和指令的純文本。
純文本顯示出來是“as-is”。不需要專門的軟件來獲取文本的完整意思，對表示字符
集的支持除外。其他的子類型用來在形式上豐富文本，應用軟件可以提升文本的外
觀，但不需要為了獲得內容的大體意思而使用這些軟件。因此，可能“text”的子類
型包括任何可讀的文字處理格式，而不需軟件來理解信息。非凡的，使用內含二進
制格式信息的格式不被認為直接可讀。一種非常簡單和便攜的子類型“richtext”在
RFC1341中有定義，更進一步的版本“enriched”在RFC1896中定義。
（2） image—圖象數據。“image”需要一個顯示設備（如一臺顯示器，一臺圖形打印機，
或者一臺傳真機）來表現信息。初始的子類型定義為一種廣泛使用圖象格式JPEG。
這些子類型定義為兩種廣泛使用的圖象格式jpeg和gif。
（3） audio—音頻數據。“Audio”需要一個音頻輸出設備（如一個揚聲器或電話）來“顯
示”內容。在這個文檔里定義了初始的子類型“basic".
（4） Video—視頻數據。“Video”顯示動態圖象的能力，典型的包括專門的硬件和軟件。
在這個文檔里定義了初始的子類型“mpeg”。
（5） Application—其他種類的數據，典型的是無法解釋的二進制數據和需要應用程序處
理的信息。子類型“octet-stream”適用于無法解釋的二進制數據場合，這種場合下
最簡單的推薦動作是為用戶把信息寫到一個文件中。“PostScript”子類型適用于附言
材料。其他預想的子類型用于“應用”包括電子數據表格，基于郵件的時序系統數
據，“活性”（可計算的）消息語言，以及不能直接可讀的文字處理格式。注重，一
些應用數據的類型可能存在安全性考慮，最顯著的是“application/PostScript”和任
何形式的活性消息。稍后我們將討論這些話題。
兩種合成的頂層媒體類型是：
（1） multipart—由多個獨立的數據類型實體組成的數據。最初定義了四個子類型，包括
基本的“mixed”子類型―指定了各個部分的一般的混合集，“alternative”表示在多
重格式中的相同數據，“parallel”用于期望各個部分同時看到，“digest”用于多部分
實體，其中每個部分有一個默認的類型“message/rfc822”。
（2） message—一種壓縮的消息。媒體類型“message”的主體是它自己全部或者消息對
象一些種類的局部。這些對象不會反過來包含其他實體。當壓縮的內容本身是
RFC822消息時使用“rfc822”子類型。“partial”定義針對部分RFC822消息，答應
太大的消息主體分段傳輸。另一個子類型“external-body”通過引用一個外部的數據
源來指定大的主體。
注重的是，上面列出的媒體類型值可能會擴張，通過擴張，子類型集合不斷增長。
4．離散的媒體類型值
七個最初的媒體類型值中的五個是關于離散的主體。這些類型的內容一定可以用非MIME
機制解決。它們對MIME處理器是不透明的。
4.1文本（Text）媒體類型
“text”媒體類型的意圖是發送主要是文本格式的數據。“charset”參數用來指出“text”
子類型的主體文本的字符集，典型的包括“text/plain”子類型，這是最普通的純文本子類型。
純文本不提供也不答應格式化命令，字體屬性規范，處理指令，解釋指令，或內容標記。純
文本只被看作是字符的線性序列，可能僅僅被換行或換頁打斷。純文本可能答應在文本中相
同位置上一些字符的堆疊。純文本手稿就像阿拉伯語或西伯來語可能包括這樣的特性，那就
是答應任意組合文本片斷，甚至是相反的寫字方向。
在純文本之上，還有很多格式來表示“richtext”。許多這種表示的一個有趣的特征是它們不
需要解釋軟件就可以達到一定的可讀性。在最高層上，有必要把它們和不可讀的數據區別開
來，如圖象，視頻或以不可讀形式表示的文本。在缺少適當的解釋軟件時，格式化的文本數
據應該以子類型“text”的形式展現給用戶，對于大多數非文本數據是不合適的。
4.1.1換行的表示
任何MIME“text”子類型的規范格式必須把換行表示成一個CRLF序列。同樣地,在
MIME“text”中碰到CRLF就代表一個換行。在換行序列之外使用CR和LF是禁止的。
這條規則使用于所有情況，不管格式或者字符集。
注重：當主體依靠媒體類型來顯示時換行要有適當的解釋。非凡的，當顯示一個
“text/plain”主體時可以把換行看作是到新行的過渡，但是不適用于“text”的子類型
“text/enriched”【RFC－1896】。同樣地，在顯示時是否加入換行是媒體類型的一個功能。
沒有必要加入所有的換行來正確顯示“text/plain”，然而“text/plain”也需要適當加入換行。
注重：一些協議定義了一行的最大長度。例如，SMTP【RFC－821】答應一行最多998
個字節。使用這種協議傳輸的時候，包括很長的沒有CRLF序列的片斷的數據必須用一種合
適的轉換機制進行編碼。
4.1.2字符集參數
“text/plain”數據的Content-Type域指定了一個重要的參數－字符集。下面是一個例子：

Content-type:text/plain;charset=iso-8859-1

不像一些其他參數值，字符集參數值是不區分大小寫的。默認的字符集是US－ASCII。
“text”未來子類型的規范必須指定是否利用“charset”參數，是否限制它的值。對于“text”
中“text/plain”之外的其他子類型，“charset”參數的語義應該和在“text/plain”定義的一樣，
例如，主體完全由給定的字符集中的字符組成。非凡的，未來“text”子類型的定義者應該
密切關注多字節字符集的含義。
“text”的子類型的字符集參數給出了字符集的名稱，就像RFC2045中定義的“character
set”一樣。前面具體定義的換行規范必須嚴格遵守，不符合這些規范的字符集不能使用在
MIME“text”子類型中。
最初確定的字符集名稱列表可以在這一節最后看到。額外的字符集應當通過IANA注
冊。
其他的媒體類型選擇采用這里定義的字符集參數，除了CRLF/換行限制。因此，所有遵守
RFC2045中“characterset”常規定義的字符集都可以注冊供MIME使用。
注重，假如指定的字符集包括8比特字符使用在主體中，為了通過一些郵件傳輸協議（如
SMTP【RFC821】）傳輸主體，需要內容/編碼轉換域和相應的數據編碼。
默認的字符集US－ASCII在以前是很混亂和模糊的。不僅在定義中有含糊，而且在應
用中有很多變種。為了消除這種二義性，強烈推薦用戶在Content-Type報頭域中明確指定
字符集參數。"US-ASCII"不表示一個任意的7比特字符集，但是指定主體中的所有字節必須
根據"US-ASCII"字符集翻譯。ISO646[ISO-646]面向應用版本通常不同于US－ASCII。字
符集名稱“US-ASCII”明確引用定義在ANSIX3.4-1986[US-ASCII]中的字符集。ISO646
新的國際參考版（IRV）和US-ASCII是一樣的。字符集名稱“ASCII”保留但禁止用于任何
目的。
注：RFC821明確規定了“ASCII”，并參考了較早的美國標準版。指定媒體類型和字符
集的一個目的是答應接收者毫無二義性的解釋數據。假定不是“strictASCII”作為默認字符
集，將冒改變正在傳輸的消息語義的危險。這也意味著包含依據ISO其他版本（非US-ASCII
和1991IRV版）編碼的字符的消息必須使用相應的字符集規范來和MIME保持一致。
完整的US-ASCII字符集列在ANSIX3.4-1986。值得注重的是，除了合成的CRLF代表
換行，包括DEL在內的控制字符沒有具體的意義。下面的兩個字符在廣泛使用中有實際意義：
FF經常表示“在新頁的開頭開始后續的文本”；TAB或HT經常表示“把光標后移，移動的列
數是8的倍數”。除了這些慣例，任何對控制字符的使用必須是下面兩種情形之一：
（1） 由于非“plan”的文本子類型明確分配了一些附加意義，或者
（2） 發送者和接受者之間有一個私人的協定，這種協定是令人泄氣的應該用文檔中的其
他功能代替。
注：在US-ASCII之外有許多龐大的字符集。大量部分或全部重疊的字符集并不是一件好事
情。可以廣泛使用的但是可以表示時間上所有語言的單一的字符集是首選的。不幸的是，幾
個委員會還將繼續使用多種字符集。因此，在本文當中定義了一小部分標準字符集。
定義的字符集是：
（1） US-ASCII――定義在ANSIX3.4-1986[US-ASCII]。
（2） ISO-8859-X――ISO646字符集已經被8859代替，8859成為Internet郵件指定的字
符集。本文檔出版時，“X”的合理的值是從1到10。
范圍在128－159之間的字符在ISO-8859-X中沒有指定意義。ISO-8859-X中值在128以下
的字符和它們在US-ASCII中有一樣的意思。
ISO8859第六部分（拉丁/阿拉伯字母）和第8部分（拉丁/西伯來字母）包括了從右至
左和從左至右兩種字符，但是沒有定義一種規范的次序來表示雙方向文本。"ISO-8859-6"和
"ISO-8859-8"字符集指定使用形象的方法【RFC-1556】。
所有這些字符集都是純7比特或8比特集，沒有“shift”和“escape”功能。“shift”和
“escape”序列的含義也沒有在這些字符集中定義。
上面定義的字符集在MIME中都是沒有爭議的。本文檔沒有認可非凡的非US-ASCII
字符集，并且承認字符集未來的發展是未知的。
注重，使用的任何非US-ASCII字符集必須在Content-Type域中具體指定。
上面定義的字符集之外的、沒有正式發行和IANA注冊的字符集，或者私人約定的字符集，
這種情況下字符集名稱必須以“X－”開始。
實現者不要定義新的字符集除非絕對需要。
“charset”參數主要定義用于文本數據，在這節中進行了描述。但是，有可能非文本數據也
希望指定字符集屬性值，這種情況下應該使用相同的句法和屬性值。
一般來說，合成軟件應該總是使用“最低級的通用命名”字符集。例如，假如一個主體只包
括US-ASCII字符，應該標記成US-ASCII字符集，而不是ISO-8859-1。更普遍的情況，如
果一個字符集是另一個字符集的子集，而主體只包含子集中的字符，那么應該標記那個子集。
這將增加接受方正確看到結果的可能性。
4.1.3.Plain(純文本)子類型
最簡單、最重要的“text(文本)”子類型是“plain(純文本)”。這表明純文
本不包含任何的命令格式或符號。純文本是有意被保持原樣的顯示，就是說，正確
的顯示純文本不需要進行命令格式、字體屬性、非凡符號、處理結構、目錄或段落
標志的處理。缺省的使用格式“text/plain;charset=us-ascii”常用于因特網實踐
中現有的電子郵件。在RFC822中由關于這個子類型的具體的定義。
在這個文件中并沒有其他的文本子類型的定義。
4.1.4.Unrecognized（未被承認的）子類型
Unrecognized（未被承認的）子類型被當作“plain”純文本子類
型，只要MIME知道怎樣處理字符集。假如它的字符集是未被承認的，就被當作
“application/octet-stream”處理。
4.2.ImageMediaType（圖象類型）
“image”（圖像）類型的主體部分包含一幅圖像，它的子類型命名這幅非凡圖像
的格式。這些命名不區分大小寫。初始的子類型是JPEG格式的“jpeg”類型，它
使用JFIF編碼[JPEG]。
這里列出的“image”圖像子類型即不是唯一的，也不是具體的，假如想要了
解更多的在IANA注冊過的子類型，可參考RFC2048。
Unrecognized（未被承認的）圖像子類型一般被當作“application/octet
-stream”處理。當它們沒有被標注為安全而只是普通的圖像瀏覽應用時，執行器
可能隨意的選擇可用的圖像子類型代替，假如那個子類型可用的話。
注重：用這種方法把應用程序支持的大部分的危險的圖像子類型處理成普通目的
圖像瀏覽應用可能會遺留下來一些安全性問題。
4.3.AudioMediaType（音頻類型）
"audio"（音頻）類型的主體部分包含音頻數據。雖然目前還沒有一致的理想的
音頻格式用于電腦，但有一些壓縮格式能提供共同操作的能力。[Page11]
最初的子類型"basic"（基本的）通過提供一個絕對的最小公分母音頻格式
滿足這種需要。在以后的文件中可能定義更豐富的格式，它具有更高品質和更低
帶寬的音頻。
"audio/basic"子類型采用單道8bitISDNmu-law[PCM]編碼，采樣頻率為8000
Hz.
未被承認的音頻子類型有時被當作"application/octet-stream"類型處理。執行
器可能隨意的選擇一個可用的音頻子類型，選擇的這個子類型不是確定的一個，可有
多個選擇，來滿足應用程序的多方面的需要，只要該應用是可行的。
4.4.VideoMediaType（視頻類型）
"video"（視頻）類型的主體部分是一個隨時間變化的運動圖像，可能帶有顏色和
同步的聲音。術語"video"（視頻）這里是從最一般的角度來說的，而不是特指某一個
技術或格式。也不排除動態圖像編碼。"mpeg"子類型指的是一種用MPEG標準編碼的視頻
類型。
應該注重雖然這個文檔不提倡在單一的主體部分有多種媒體類型的混合，事實
上已經有許多所謂的有同步描述的視頻格式，"video"（視頻）類型支持這種格式。
未被承認的視頻子類型有時被當作"application/octet-stream"類型處理。執行
器可能隨意的選擇一個可用的視頻子類型，選擇的這個子類型不是確定的一個，可有
多個選擇，來滿足應用程序的多方面的需要，只要該應用是可行的。
4.5.ApplicationMediaType（應用類型）
"application"（應用）類型用于不連續的、離散的數據，這些數據不適合其他的
類型，但作為一種數據必須被應用程序處理。這種信息必須被應用程序在用戶看見和
使用前處理。"application"（應用）類型的其他的用途包括文件傳輸、電子數據表、
有時序的電子郵件數據和計算語法。（后者，非凡地，能引起安全性問題，故被實現
者重視，在"application/PostScript"類型中有關這方面具體的討論。）[Page12]
例如，一個會議的時間安排可能定義一個標準的關于被提議的會議日期信息的
描述，一個聰明的用戶代理會使用這些信息治理一個用戶的對話，然后可能發送關于
那個對話的額外的材料，更一般地，已經開發出幾個活性的消息語言，它們可用來編
寫一些非凡的程序被發送到一個遠程接口位置并且自動地在接受者環境中運行。
那樣的程序可能被定義為"application"類型。這個文檔定義了兩個子類型：
octet-stream,（8bit流）andPostScript（標記）.
"application"（應用）的子類型不是應用的名字和它的一部分名字，在這個應用中
數據是已定義的。這不是意味著，然而，任何一個應用程序的名字會作為一個
"application"的子類型。
4.5.1.Octet-StreamSubtype（8bit子節流子類型）
Octet-Stream（8bit子節流）子類型的主體部分包括任意的二進制數據。當前的設置
的參數定義為:
(1)PYTE--普通的類型或二進制數據。這是有意作為人類可接受的信息形式而不是其他
的任何一個機械的處理。
（2）PADDING--由二進制流組成的填補的比特數量是根據實際的內容產生附加的的8bit
子節數據。這在當總的比特數不是8的倍數時是有用的。
這兩個是可選的。
另外的參數，"CONVERSIONS"，在RFC1341中定義，但是已經不用了。RFC1431也定
義了"NAME"參數的用法。它表示一個用來寫數據的文件的文件名。在后來的RFC文檔中反對
在分開的內容中使用該頭域。
推薦的為一個執行接收"application/octet-stream"的實體的使用方法是簡單的把數據
放到一個文件中，如使用Content-Transfer-Encoding（內容傳輸編碼），或使用它作為一
個用戶定義的進程的輸入。[Page13]
為了減少傳輸抵賴，它強烈建議執行中不用機械地路徑搜索，在那里武斷地命名一個程
序的參數作為輸入。
4.5.2.PostScriptSubtype（標注類型）
"application/postscript"的類型顯示一個有標注的程序。通常答應兩個不同的標注
語言；起始的標注1變量在[POSTSCRIPT]中描繪，另外一個標注變量在[POSTSCRIPT2]描繪。
標注是一個Adobe體系公司的一個注冊商標，MIME類型的使用
"application/postscript"意味著商標的所有的權利。
標注語言定義提供了設施，為了內部的非凡的語言特征定義，用在程序中使用。這種
非凡語言的標號特征叫做標注文檔結構規范或DSC。DSC是非常普通和充分的用于常規的信
息系統中。不管有沒有要求，它被強烈的推薦使用，作為一個互用性的輔助。缺乏常規的習
慣性的結構的文檔不能讓人相信會在一個給定的環境下工作。同樣地，一些系統可能設定最
壞的情況并拒絕處理無結構的文檔。
普通目的的執行標注細節是有嚴重的安全性隱患，實現者會氣餒于發送一些帶標注體
"off-the-shelf"的翻譯。然而它通常是安全的，在發送標注給一個打印機時，在那里通過
一個典型的打印環境潛在的傷害是很大的，執行者應該考慮所有的下面個情況，在他們增加
交互式的顯示標注體給他們的MIME讀者的時候。
下面是這部分的一些概要，雖然可能不全，和在標注實體傳輸中的可能出現的問題。
（1）PostScript語言危險的操作包括，但不是限制，"deletefile","renamefile",
"filenameforall",和"file"."File"只在一些費標準的輸入輸出應用中是危險的。執行可
能定義非標準的文件操作；這些可能產生對安全的危險。"Filenameforall"文件搜索操作
通配符，在第一次出現時無危險的。
然而，這種操作潛在的暴露有用的信息，這種信息可能本身是敏感的。
消息發送者應該避免使用有潛在危險的文件操作符，既然這些操作符是十分可能引發安全
問題。消息接受和顯示軟件應該消除所有的安全隱患的文件操作符或采取非凡的方法。當
PostScript解釋器處理文件時，這些操作符應該被當作外部的代理。那樣的話，使and/or
檢查應該在到達解釋語言本身之前完成。注重確保沒有enablingfull函數方法存在。

(2)PostScript語言給現有的標準的解釋器提供工具或服務等。外部環境的改變，
通常保留在文件里，有時也會存于輕易丟失的內存中。與解釋器相關的操作和文件有潛在的
接口。然而，無限制地使用會導致拒絕服務。PostScript解釋器的操作包括exitserver操
作和startjob操作。消息發送和接收軟件不應該生成PostScript，而是讓解釋器來完成，
既然退出的能力可能是難以獲得的，在PostScript安全執行時。消息發送和接收軟件應該
完全不能有能力來保留PostScript環境的改變，通過排除或禁止"startjob"和
"exitserver"操作。假如這些操作不能排除或完全的禁止和他們相關聯的密碼，就應該設
置一個hard-to-guess值。
（3)PostScript提供操作來設置system-wide和device-specific參數。這些參數設
置可能保留交叉的工作也可能對解釋器正確操作造成危險。PostScript設置系統和設備
參數的操作包括，但不僅限于，"setsystemparams"和"setdevparams"操作。消息發
送軟件不應該產生依靠系統和設備參數設置能正確操作的PostScript。設置這些參數的能
力可能在安全的PostScript執行中被禁止。消息發送和顯示軟件有能力禁用系統和設備參
數的設置。假如這些操作不能完全禁用和他們有關的密碼，至少應該設置一個
hard-to-guess值。
（4）一些PostScript的執行器提供了非標準的工具來直接登陸和執行機器代碼。
那樣的工具是十分下輕易找的，以至于濫芋充數。消息發送軟件不應該提供那樣的功能。
包括hardware-specific在內，它們可能在PostScript安全執行器中不可用的。消息
接收和顯示軟件不應該答應那樣的操作，假如它們存在的話
（5）PostScript是一種擴展語言，它的許多執行器提供了各自的擴展。本文檔不
討論這些有不確定因素的擴展。消息發送軟件不應該使用非標準的擴展；因為它們可能
在一些執行器中丟失。消息發送和顯示軟件應該保證非標準的PostScript操作是安全的、
不會產生任何的危險。
（6）寫一個消耗大量的系統資源的PostScript是可能的。寫一個循環執行的
PostScript也是可能的。假如把這兩種類型的程序大送給信任的收件人，可能引起
破壞。消息發送軟件應該避免解釋和分發那樣的程序，因為它是反社會的。消息接收和
顯示軟件應該提供適當的機制，當合理數量的時間消逝后作中斷處理。另外，PostScript
解釋器應該被限制只使用合理數目的系統資源。
（7）在PostScript里面可能包括各種形式的原始的二進制數據。在因特網郵件上
不推薦這樣使用。其一是因為不是所有PostScript解釋器支持這種數據格式，其二是因為
這樣會使MIMEContent-Tansfer-Encoding(內容傳送編碼)變得復雜。（沒有那樣的二進制
數據，PostScript可能是把數據當作line-oriented數據，假如把二進制數據和
line-oriented數據數據混合在單一的Postscript數據流里面，PostScript把數據當作
CRLF處理，結果非常會出現問題。）
（8）最后，某些PostScript解釋器可能存在bug，在接受者的系統里可能引發未被
授權的問題。有些我們沒有辦法對付，有些可以采取適當的方法糾正。
4.5.3.其它application的子類型
將來有可能定義許多其它的application的子類型。MIME執行器必須最低限度把
任何不可識別的子類型當作"application/octet-stream"類處理。
5.CompositeMediaTypeValues（復合類型值）
七個內容類型中復合類型占了兩個。復合實體可以被MIME機制處理--一個MIME處理
器代表性地直接處理主體部分。
5.1.MultipartMediaType（多部分類型）
在multipartentity(多部分實體)的例子中，一個或多個不同的數據集合并在一
個單一的body(體)中，一個"multipart"（多部分）類型field的（域）必須出現在實
體的header(頭域)。body（體）必須包括一個或多個bodypart（體部分)，每一個位
于boundary（邊界）定界符線之前，最后一個則跟著一個結束邊界定界符線。在它的
邊界定界符線后，每一個體部分由頭域、空行、體組成。因此一個體部分在語法上類
似于RFC822中的message(消息)，但是在意義上是不同的。
一個體部分是一個實體，因此實際上不會被當作RFC822中的消息來解釋。首先，
在體部分中實際上不需要頭域。因此，一個以空行開始的體部分是答應的，它被解釋
成缺省值的頭域。在這樣的一個例子中，Content-Type（內容類型）被解釋成
"text/plain;charset=US-ASCII".
唯一有意義的體部分頭域是以那些以"Content-"開始的名字。在體部分中所有其它
的頭域可能被忽視。雖然它們通常很有可能被保留下來，必要時可以被網關丟棄。其它的域
被答應出現在體部分中但不受支持。以"X-"開始的域可能實驗或私人目的被創建，它們包含
的這些信息被識別出來后，可能會被某些網關丟棄。
注重：RFC822消息和體部分的區別是微妙的、不重要的。一個因特網和X.400郵件的
網關，舉個例子說，必須能識別一個包含圖像的體部分和一個包含壓縮消息的體部分，
這個壓縮的消息是一幅JPEG圖像。為了描繪后者，體部分必須有"Content-Type:
message/rfc822"，并且它的體（空行之后）必須是壓縮的消息，它自己的體頭域是
"Content-Type:image/jpeg"。相似的語法便于消息到體部分的轉化，反之亦然，
但是它們兩個的區別必須被實現程序理解。（因為在非凡的情況下，體部分實際上是消
息，也可以定義為"digest"子類型。）
正如前面所說，每一個體部分是在包含邊界定界符的邊界定界符線之前。邊界
定界符不能出現在任何的壓縮部分里面、本身的行上、任何行的前綴。這表明在至關
重要的一點是應該選一個結構代理和指定一個統一的邊界參數值，在多部分的內部
不要包含邊界參數值。
所有目前和將來出現的多部分子類型必須使用同樣的語法。在它們的語義上子類
型可能不同，并在語法上強加于另外的限制，但是必須使多部分必要的語法一致。
這種必要確保所有用戶代理至少能夠識別和區分多部分實體的體部分，即使是那些
未被公認的子類型。
正如在內容傳送編碼[RFC2045]中規定的，除了"7bit","8bit",和"binary"
外多部分實體不答應其它的編碼。多部分邊界定界符和頭域在所有的例子中總是描
述成7bitUS-ASCII（雖然頭域可能編碼成非US-ASCII的正文，參見RFC2047），體
部分的數據被編碼成相應的內容傳送編碼。[Page18]
5.1.1.CommonSyntax（共同語法）
這部分定義多部分子類型的共同的語法。所有的多部分子類型必須使用該語法。
一個簡單的例子會在這部分的后面出現。在RFC2049給出了一個更復雜的多部分消息
的例子。
多部分實體的內容類型域需要一個邊界參數"boundary"。邊界定界符線定義為
由兩個連字符（"-",十進制值是45）和緊跟著從內容類型頭域取來的"boundary"邊界
參數值組成，空格和CRLF分隔符可選。
注重：連字符在早期的RFC934中的壓縮消息不兼容，搜索邊界符然后執行是輕易的。
然而，應該提醒多部分的消息不完全和RFC934RFC934中的壓縮消息兼容；非凡地，
它們不服從RFC934規定的內含連字符開頭的行引用。這種機制后來不用了，因為后者
引用了前一級的引用。這種合并使連字符在這種情況下不合適。
設計實現程序的警告：關于內容類型的語法參數設置邊界參數值經常是必要的，邊界
參數值要被后面引用。雖然不一定是必需的，但不會有危害。實現者必須仔細的學習
語法以免產生無效的內容類型域。因此，一個多部分的內容類型頭域可能像下面的樣
子：
Content-Type:multipart/mixed;boundary=gc0p4Jq0M2Yt08j34c0p
但是下面是無效的:
Content-Type:multipart/mixed;boundary=gc0pJq0M:08jU534c0p
（由于冒號）必須改為：
Content-Type:multipart/mixed;boundary="gc0pJq0M:08jU534c0p"
這個內容類型值表明內容有一個或多個部分組成，每一個部分相互獨立，語法結構
相同是RFC822中的消息，頭域答應空，體部分在邊界線
--gc0pJq0M:08jU534c0p前。
邊界線必須出現在行的開始，i.e.緊跟著CRLF分隔符，邊界定界符線被認
為緊接著初始的CRLF，而不是前面部分的一部分。分界符可能跟著0或多個空格
。然后被另一個CRLF分隔符終止。開始下一個體部分的頭域或兩個CRLF分隔符
（即空行）。假如內容類型域沒有則表示它使用缺省的"multipart/digest"每個
體部分的子類型為"message/rfc822"，或是"text/plain"類型。
注重：位于邊界定界符線之前的CRLF概念性地依附于邊界符，因此它可能不以
CRLF結束（空行）。體部分必須被認為以空行結束，因此在邊界定界符行之前
需要兩個CRLF，第一個是前面體部分地一部分，后一個是壓縮邊界的一部分。
編界定界符不能出現在壓縮的原文里面，并且不能大于70個字符，不計算
前面的連字符。
最后一個體部分的邊界定界符行是非凡的，在它之后沒有其它的體部分了。
該邊界定界符行與前面的邊界定界符行一樣，只是在定界符值后多了兩個連字符。
如--gc0pJq0M:08jU534c0p--
設計實現程序注重：邊界字符串和邊界值對照，在每一個候選行的開始處。一個
確切的匹配整個候選行不是必需的；但有充分的理由讓邊界出現在所有CRLF結束
后。
在第一個定界符行和最后一個定界符行之間應留出一些空間給附加的信息。
這個區域通常有一些空白在左邊，執行器必須忽略在第一個和最后一個邊界行之
間的空白。
注重："處理這些區域時這部分缺乏適當的類型和清楚的語義，非凡在X.400網關。然而，
去掉preamble部分空白后，許多MIME執行器發現這是一個便利的地方，
可以插入一些解釋性的注釋給收件人看，他可以用pre-MIME軟件讀取這部分消息，
既然它們被MIME軟件忽略。
注重：因為邊界定界符不能出現在體部分，用戶代理必須小心翼翼的選擇一個一致的
邊界符參數值。在上面的例子中邊界符參數值是由一個設計的運算器產生的，
這個值必須幾乎不可能和現存的壓縮數據重合，且不要事先掃描數據。改變運算
規則導致更多的易讀的邊界定界符輕易被一個老的用戶代理接收，但是要更多注重
可能該邊界定界符會出現在一些數據行中。最簡單的邊界行是"---"，相應的結束
邊界行是"-----"。作為一個最簡單的例子，下面的多部分消息有兩部分，它們都是純
文本，一個明確的指明類型，另一個則不指明：
From:NathanielBorenstein<nsb@bellcore.com>
To:NedFreed<ned@innosoft.com>
Date:Sun,21Mar199323:56:48-0800(PST)
Subject:Samplemessage
MIME-Version:1.0
Content-type:multipart/mixed;boundary="simpleboundary"

Thisisthepreamble.Itistobeignored,thoughit
isahandyplaceforcompositionagentstoincludean
eXPlanatorynotetonon-MIMEconformantreaders.

--simpleboundary

ThisisimplicitlytypedplainUS-ASCIItext.
ItdoesNOTendwithalinebreak.
--simpleboundary
Content-type:text/plain;charset=us-ascii

ThisisexplicitlytypedplainUS-ASCIItext.
ItDOESendwithalinebreak.

--simpleboundary--

這里的結尾通常被忽略。

在另一個multipart實體內的主體部分multipart媒體類型的使用是明確答應的。在這種
情況下很明顯：我們必須確保嵌套的multipart實體使用不同的邊界分隔符。看RFC2049的
一個嵌套multipart實體的例子。
只有單個主體的multipart媒體類型的使用可能在確定的上下文中是有用的，并且是明
確答應的。
NOTE：經驗表明單主體的multipart媒體類型對發送非文本的各媒體類型是有用的。它
有提供了序言的優點，在其中包括了解碼指令。而且，許多SMTP（簡單郵件傳輸協議）網
關移動或移除了MIME(多用途的網際郵件擴充協議)的首部字段，一種智能的MIME譯碼器
甚至能在沒有Content-Type（內容類型）頭的情況下對multipart(多部分)的邊界進行很好的
猜測，從而成功地對報文解碼。
對multipart媒體類型來說，唯一的強制性的全局參數是邊界參數，它由一個字符集的1
至70個字符組成，這個字符集能健壯的通過郵件網關，不會以whitespace（空白段）結束。
(若邊界分隔線以空白段結束，這空白段必定被認為是由網關添加的，必須刪除。)它在下面
的BNF中正式地進行了規定：
boundary:=0*69<bchars>bcharsnospace
bchars:=bcharsnospace/""
bcharsnospace:=DIGIT/ALPHA/"'"/"("/")"/
"+"/"_"/","/"-"/"."/
"/"/":"/"="/"?"
總之，multipart實體的主體可以規定如下：
dash-boundary:="--"boundary
；邊界取決于Content-Typefield字段的邊界參數的值。
multipart-body:=[preambleCRLF]
dash-boundarytransport-paddingCRLF
body-part*encapsulation
close-delimitertransport-padding
[CRLFepilogue]
transport-padding:=*LWSP-char
；創建者絕對不能產生非零長度的transport-padding，但接收方必
須能夠處理由報文傳輸添加的padding。
encapsulation:=delimitertransport-padding
CRLFbody-part
delimiter:=CRLFdash-boundary
close-delimiter:=delimiter"--"
preamble:=discard-text
epilogue:=discard-text
discard-text:=*(*textCRLF)*text
；可以忽視或丟棄
body-part:=MIME-part-headers[CRLF*OCTET]
；在主體部分的內容千萬不能以特定的虛邊界開始，分隔符也不能在主
體的任何地方出現。注重到主體部分的語法分析器不同于報文的語法分析器，正如在文本中
描述的那樣。
OCTET:=<any0-255octetvalue>
重要的：在這個BNF中顯示的成分中自由地插入linear-white-space和RFC822注解是
不答應的。因為這個BNF沒有指定一個結構化的報頭字段。
注重：在確定的傳輸領域，RFC822的限制條文比如限制主體部分使用printable
US-ASCII字符可能并不是有效的。（那就是說，傳輸領域中存在著類似在RFC821中規定
且在RFC822中假定的internet郵件傳輸標準，但是沒有確定的限制條文。）對這些限制的放
寬可以這樣被認為是局部地擴展主體的定義，比如說：在US-ASCII的范圍外再包含八位位
組，只要傳輸支持這些擴展，并且在Content-Transfer-Encoding（內容傳輸編碼）報頭字段
中充分地記錄。但是頭部（不管是報文頭還是主體部分的頭部）在任何情況下都不答應包含
非US-ASCII字符。
注重：在multipart類型中明顯缺少的是一種結構化的主體部分。那些若想提供更多結
構化或完整化的multipart報文傳輸便利性，則需要定義在語句構成上一致的multipart的子
類型，但在不同部分要定義相互關系。舉個例子，multipart的子類型可以被定義為包括一個
特有的部分，它依次被使用來規定不同部分的關系，可以在Content-ID（內容ID）字段注
明。若采用這種方法的話，舊的執行部分將無法識別新的子類型，但將把它作為
multipart/mixed類型，這樣使得用戶能識別標志的部分。
5.1.2處理嵌套的報文和multiparts（多部分）
在這個文檔的并發部分定義的"message/rfc822"子類型除非數據用完，否則不會終結。
同樣，一個不正確地縮短了的"multipart"實體可能沒有終止邊界標記，由于郵件系統的癱瘓
在操作上會出現這種情況。
當這些實體嵌入到另一個multipart結構中時，有必要對這些實體進行正確的處理。因
此MIME的執行就要能識別在任何層次內部嵌套中的外層的邊界標記。僅僅檢查下一個預
期的標記或其它終結條件是不夠的。
5.1.3Mixed子類型
當主體部分是獨立的并且需要按一定的順序捆綁時就要用到multipart類型的子類型
"mixed"。任何一種執行時無法識別的multipart子類型都被視為子類型"mixed"。
5.1.4alternative子類型
"multipart/alternative"類型與"multipart/mixed"在語句構成上是一致的，但語意是不同的。
不同處在于主體的每一部分都是相同信息的選擇性版本。
系統應當承認不同部分的內容是可互換的。系統可以根據本地的環境和參照來選擇最
好的類型，有時甚至可以通過與用戶的交互。對于"multipart/mixed"類型，主體部分的順序
是很重要的。因此，alternatives以不斷忠實于原文的順序出現。通常，最佳的選擇是最后部
分用系統本地環境易于接收的類型。
舉個例子，"multipart/alternative"可以用來以文本格式發送報文從而能方便地在任何地方
展現出來：

From:NathanielBorenstein<nsb@bellcore.com>
To:NedFreed<ned@innosoft.com>
Date:Mon,22Mar199309:41:09-0800(PST)
Subject:Formattedtextmail
MIME-Version:1.0
Content-Type:multipart/alternative;boundary=boundary42

--boundary42
Content-Type:text/plain;charset=us-ascii

...plaintextversionofmessagegoeshere...

--boundary42
Content-Type:text/enriched

...RFC1896text/enrichedversionofsamemessage
goeshere...

--boundary42
Content-Type:application/x-whatever

...fanciestversionofsamemessagegoeshere...

--boundary42--
在這個例子中，郵件系統理解了"application/x-whatever"格式的用戶只愿看到想要的版
本，而其它用戶根據他們系統的實際容量將只愿看到enriched（豐富的）版本或plaintext(純
文本的)版本。
通常，組織"multipart/alternative"實體的用戶代理商必定按偏愛遞增的順序來放置主體部分，
也就是說首選的格式放在最后。對fancytext格式，發送方用戶代理商會把最簡單的格式放
在最前，最豐富的格式放在最后。接手方用戶代理商可挑選顯示他們能夠顯示的最后的格式。
假如二中之一自身是multipart類型且包含不可識別的子部分時，用戶代理商就會選擇或者
顯示這其中之一，即早期的那個，或者兩者都顯示。
注重：從執行者的觀點看，也許把這個順序倒過來更明智些，就是把最簡單的放在最
后。然而，當"multipart/alternative"實體被認為用non-MIME-conformant閱讀器時，把最簡單
的放在最先是一種可能的選擇。然而這種方法加重了conformantMIME閱讀器的負擔，在
此時它與舊的郵件閱讀器的互用性就非常重要了。
也許會出現這種情況，一些用戶代理假如能夠識別不止一種格式，他們將會讓用戶選
擇觀看的格式。舉個例子，假如報文既包括了精細格式的image版本，又包括了易于編輯
的text版本，那將是很有意義的。但是最重要的是，用戶并非無意識地看到了同一數據的多
種版本。用戶或可看到最后被識別的版本，或可以作出選擇。

在MULTIPART/ALTERNATIVE中CONTENT-ID（內容ID）的語義："multipart/alternative"
實體的每一部分代表了相同的數據，但是兩者之間的映射并不一定沒有信息丟棄。舉個例子，
當把ODA翻譯成附言或純文本時，信息就會丟棄。在兩部分信息內容不一致處，建議給每
一部分一個不同的Content-ID（內容編號）值。當信息內容一致時。比如說，
"message/external-body"類型的幾個部分規定了交替的方法存取一致的數據，此時就應當使用
相同的Content-ID字段值來優化任何的高速緩存機制，這機制在接受方的終端。然而，如
果有這種Content-ID字段的話，不同部分的Content-ID值也不該與描述
"multipart/alternative"的完全相同。也就是說，一個Content-ID值指著"multipart/alternative"實
體，然而一個或多個其它的Content-ID值將指向各部分的內部。
5.1.5Digest子類型
這個文檔定義了multipart內容類型的digest子類型。這個類型在語句構成上跟
"multipart/mixed"是一致的，但語義是不同的。尤其是，在摘要中，主體部分缺省的內容類
型值是在"text/plain"和"message/rfc822"之間變化的。這樣做就答應了易讀的摘要格式，它對
RFC934的兼容性非常的好（除了引用文慣例）。
注重：雖然在不同于"message/rfc822"的摘要的主體部分指定一個內容類型值是可行的，
比如一個"text/plain"部分包含了摘要內容的描述，事實上這樣做是不可行的。
"multipart/digest"內容類型是用來發送報文集的。假如需要"text/plain"部分，它將作為
"multipart/mixed"報文的單獨的部分包括進來。
這種格式的摘要看起來如下：

From:Moderator-Address
To:Recipient-List
Date:Mon,22Mar199413:34:51+0000
Subject:InternetDigest,volume42
MIME-Version:1.0
Content-Type:multipart/mixed;
boundary="----mainboundary----"

------mainboundary----

...IntrodUCtorytextortableofcontents...

------mainboundary----
Content-Type:multipart/digest;
boundary="----nextmessage----"

------nextmessage----

From:someone-else
Date:Fri,26Mar199311:13:32+0200
Subject:myopinion

...bodygoeshere...

------nextmessage----

From:someone-else-again
Date:Fri,26Mar199310:07:13-0500
Subject:mydifferentopinion

...anotherbodygoeshere...

------nextmessage------

------mainboundary------


5.1.6.Parallel子類型
這個文檔定義了"multipart"內容類型的"parallel"子類型。這種類型在句法上與
"multipart/mixed"是一致的，但是語義是不同的。非凡的，在一個并行實體中，主體部分的
順序并不是非常重要的。
這種類型的一個普通的介紹就是把各部分同時在可能的軟硬件上顯示出來。然而，組織
代理會意識到許多郵件讀者不具備這種能力，無論如何都會順序地顯示各部分。
5.1.7其他的Multipart子類型
其他的Multipart子類型將會出現。MIME的實現通常必定把無法被識別的multipart子
類型等同地視為"multipart/mixed"。
5.2.報文媒體類型
在發送郵件時，通常希望封裝在另一個郵件報文中。一種非凡的媒體類型"message"就
是被定義來實現這個功能的。非凡的是，"message"（報文）的"rfc822"子類型就是用來封裝
RFC822報文。
注重：報文的子類型或許被定義來接受或丟棄報文。然而，接受或丟棄的報文可以被當
成多部分報文來處理，其中第一部分包含了所有的控制和描述信息，第二部分
"message/rfc822"類型是被接受或丟棄報文。在這種方式下，組和起來的接受或丟棄的報文
將會保留在原始報文中的類型信息，答應它正確地遞交給接受方，因此它是被倡導的。
報文的子類型經常在在答應編碼的地方加上限制。這些限制的描述和每一種特定的子類
型都是關聯的。
郵件網關、中繼和其它的郵件處理代理通常是改變RFC822報文的頂層（top-level）報
頭。非凡是，他們頻繁地增加、刪除、追加頭文件字段。這些操作對封裝的即內含在message
類型的報文主體內的報頭來說是明確禁止的。
5.2.1RFC822子類型
"message/rfc822"的媒體類型指出：主體按照RFC822報文的句法包含了封裝的報文。
然而，不象頂層的RFC822報文，這些限制（也就是說每個"message/rfc822"主體必須包含
一個"From","Date"和至少一個目的頭文件）被刪除了，以這樣的要求來替代：也就是說必
須出現"From","Subject",或"Date"中的一個。
應當注重到：盡管使用了數字"822"，但是"message/rfc822"實體并不嚴格限于與RFC822
完全一致。"message/rfc822"對象的語義也不必限定于RFC822中定義的語意。更明確的是，
"message/rfc822"報文可以是消息條款或一種MIME報文。
除了"7bit"、"8bit"或"binary"外，其它的編碼對"message/rfc822"實體的主體來說都是不
答應的。報頭字段在任何情況下都是US-ASCII，主體內的數據仍可編碼，在這種情況下，
處在封裝的報文內的Content-Transfer-Encoding（內容傳送編碼）的報頭字段將會反映這一
點。在封裝的報文頭的Non-US-ASCIItext可以指定為使用RFC2047中描述的機制。
5.2.2Partial子類型
"partial"子類型是用來把大的郵件分成幾個獨立的片段進行傳送，然后由接受方的用
戶代理自動地組裝。（這思想與IP分組后用基本的IP協議組裝相似。）當中間傳輸代理限制
了單個可傳送報文的大小時就可使用這種機制。媒體類型"message/partial"就這樣指出，主體
包含了一個大的郵件的片段。
因為"message"類型的數據從不會用base64或quoted-printable（加引號的可打印）類型
編碼，若"message/partial"郵件在支持binary或8bit傳輸的環境中構建，那就會出現問題。
這問題就是binary數據將會被分成多部分的"message/partial"報文，每一部分要求二進制傳
輸。若這些報文在網關碰到了7bit的傳輸環境，除了等待所有的片段組裝成內部的報文，
然后把組裝的數據以base64或quoted-printable類型編碼，沒有合適的方法進行7bit的編碼。
雖然不同的分組可以經由不同的網關，但是這仍然是不可接受的解決辦法。因此規定了
"message/partial"類型郵件必須有7bit（默認）的內容傳輸編碼。非凡的，即使在支持binary
或者8bit傳輸的環境中，使用8bit或binary的內容傳輸編碼對"message/partial"類型的MIME
郵件來說是明確禁止的。這也就反過來意味著內部的報文決不能使用8bit或binary編碼。
因為一些報文傳輸代理選擇自動地把大的報文分段，并且因為這些代理使用不同的分
段極限，所以部分的報文片段在重新組裝以后，可以看出他們是由部分的報文組成的，這是
明確答應的。
在"message/partial"類型的內容類型字段必須規定三個參數：首先是ID，這是一個唯一
的標志符，是使用來匹配所有的分段。（通常，標志符必須是一個message-id；假如放在雙
引號中，它可以是任何的message-id,與RFC2045中給出的BNF參數是一致的。其次是
number,一個整形，是分段號，它指示了每個分段的次序。最后是total，另一個整形，是分
段的總數。在最后一個分段上必須由這個字段，在之前的分段上它是可選的（雖然最好寫上）。
同樣注重：這些參數的順序是任意的。
這樣，三部分報文的第二部分可以是下列報頭字段的任一種：
Content-Type:Message/Partial;number=2;total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Content-Type:Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
但是第三部分必須指定總的分段數：
Content-Type:Message/Partial;number=3;total=3;
id=oc=jpbe0M2Yt4s@thumper.bellcore.com
請注重：分段編號從1而非0開始。
當一個郵件以這種方式被分解成的片段組合在一起，結果總是一個完整的MIME郵件，
它可能有自己的內容類型報頭字段，因此可能含有任何其它的數據類型。
5.2.2.1報文分段和重組
重組分段報文的語義必須是"inner"報文的語義，而不是包含內部報文的報文語義。這就
使得以單獨的分組報文發送一個大的audio報文成為可能，而且對接受方與其說是一個包含
一個audio報文的封裝報文，不如說是一個簡單的audio報文。那就是說，封裝的報文是透
明的。
當產生和重組"message/partial"類型的報文片段時，被封裝報文的報頭必須與封裝實體的
報頭合并。在這個過程中必須遵守下列規則：
（1）分片代理必須只用邊界線把報文分割。引入這條限制是因為在點上而非在行的末
尾進行分割，反過來依靠報文傳輸能夠保留不以CRLF序列結束的報文語義。許多傳輸是不
能保留這種語義的。
（2）除了那些以"Content-"或特定的報頭字段"Subject"、"Message-ID"、
"Encrypted"、"MIME-Version"開始的報頭外，其它所有來自初始嵌套報文的報頭字段都必
須按序復制到新的報文中去。
（3）以"Content-"加上"Subject"、"Message-ID"、"Encrypted"和"MIME-Version"字
段開始的嵌套報文頭字段必須按序添加到新報文的報頭字段。任何不以"Content-"開始的嵌
套報文頭字段將被忽視或丟棄。（除了"Subject"、"Message-ID"、"Encrypted"和"MIME-
Version"字段）
（4）第二或以后嵌套報文的所有報頭字段都會被重組過程丟棄。
5.2.2.2分割和重組實例
假如一個audio報文被分割成兩個部分，第一部分可以是這樣：

X-Weird-Header-1:Foo
From:Bill@host.com
To:joe@otherhost.com
Date:Fri,26Mar199312:59:38-0500(EST)
Subject:Audiomail(part1of2)
Message-ID:<id1@host.com>
MIME-Version:1.0
Content-type:message/partial;id="ABC@host.com";
number=1;total=2

X-Weird-Header-1:Bar
X-Weird-Header-2:Hello
Message-ID:<anotherid@foo.com>
Subject:Audiomail
MIME-Version:1.0
Content-type:audio/basic
Content-transfer-encoding:base64

...firsthalfofencodedaudiodatagoeshere...
第二部分可以是這樣：

From:Bill@host.com
To:joe@otherhost.com
Date:Fri,26Mar199312:59:38-0500(EST)
Subject:Audiomail(part2of2)
MIME-Version:1.0
Message-ID:<id2@host.com>
Content-type:message/partial;
id="ABC@host.com";number=2;total=2

...secondhalfofencodedaudiodatagoeshere...
然后，當分割的報文重組后，顯示給用戶的結果報文應該是這樣：

X-Weird-Header-1:Foo
From:Bill@host.com
To:joe@otherhost.com
Date:Fri,26Mar199312:59:38-0500(EST)
Subject:Audiomail
Message-ID:<anotherid@foo.com>
MIME-Version:1.0
Content-type:audio/basic
Content-transfer-encoding:base64

...firsthalfofencodedaudiodatagoeshere...
...secondhalfofencodedaudiodatagoeshere...
分割報文第二和以后片段的報頭中包括"References"字段，參考先前片段的Message-Id
對郵件讀者理解和跟蹤參照來說有益的。然而，象參考字段這樣的字段是完全可以任意選擇
的。
5.2.3External-Body(外部主體)子類型
External-Body(外部主體)子類型表明實際體數據僅僅是被引用,而不被包含在內.既然這
樣,參數就描述一種訪問外部數據的機制.當一個MIME實體是"message/external-body"類型,
它包括一個報頭,兩個連續的CRLFs,以及用于被壓縮報文的報頭.假如出現另一對連續
CRLFs,用于被壓縮報文的報頭就結束.然而由于被壓縮的報文主體本身是外部的,它并不會
出現在隨后的區域內.以如下報文為例:
Content-type:message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"

Content-type:image/jpeg
Content-ID:<id42@guppylake.bellcore.com>
Content-Transfer-Encoding:binary

THISISNOTREALLYTHEBODY!
稱之為"影子主體(phantombody)"的結尾區域對大多數的外部主體報文來說是被忽略的.
然而,當訪問類型是"mail-server(郵件-服務)"時,它用于包含某些輔助信息.
在文檔中定義的使用影子主體(phantombody)的唯一訪問類型是"mail-server(郵件-服務)",
但未來在其他規范中可能會定義另外一些使用這一區域的訪問類型.
在所有"message/external-body(報文/外部主體類型)"實體中,這些被壓縮的報頭必須包含
一個Content-ID(內容ID)字段作為唯一標識用來引用數據.當訪問類型是"mail-server(郵件-服
務)"時,這個標識被用于緩沖機制和數據接收的識別.
注:正如這兒所說明的,用于描述external-body(外部主體)數據的標記,例如文件名以及郵件
服務命令在US-ASII字符集中是必須的.
假如在實際應用中存在問題,那么可能就需要一種新的機制作為MIME的未來擴充,要么
為"message/external-body(報文/外部主體)"定義最新的訪問類型,要么通過其他一些機制.
與"message/partial(報文/部分)"一樣,類型"message/external-body(報文/外部主體)"的MIME
實體必須一個7bit(缺省)的
content-transfer-encoding(內容傳送編碼).非凡的,對于"message/external-body(報文/外部主
體)"類型的實體來說,即使在支持binary(二進制)和8bit傳輸的環境中,binary(二進制)和8bit
的內容編碼傳送的使用也是被明確禁止的.
5.2.3.1.普通external-body(外部主體)參數
可以和任何"message/external-body(報文/外部主體)"一起使用的參數是:
(1)ACCESS-TYPE--表示被支持的訪問機制的命令,通過它可以獲取文件和數據.這個命令
不區分大小寫.它的值包括但不限于"FTP","ANON-FTP","TFTP",
"LOCAL-FILE","MAIL-SERVER".
如RFC2048中描述的,除以"X-"開頭的測試值以外,其他值都必須到IANA注冊.這個參數不
是無條件的命令,它必須出現在每個"message/external-body(報文/外部主體)"中.
(2)EXPIRATION--過了這個日期(在RFC822"date-time(日期-時間)中定義,RFC1123中得到
擴充,答應在年字段有4個數字)之后,外部數據的存在將得不到保證.這個參數可以和任何
access-type一起使用,并一直是可選的.
(3)SIZE--數據大小(八位字節).這個參數的目的是為了幫助接收方決定是否耗費必要的資
源取回外部數據.注重這兒,它描述了數據在標準形式下的大小,標準形式就是在任何
Content-Transfer-Encoding被應用之前,或者數據被解碼之后.這個參數可以和任何access-type
一起使用,并一直是可選的.
(4)PERMISSION--一個不區分大小寫的字段,它表明客戶試圖修改數據是否是可以的.默認
情況下,或者假如permission值"read",前提條件就是他們不答應"read",并且假如數據被重新得
到過一次,它就不在需要了.假如permission值是"read-write",那么前提條件就是無效的,并且
任何本地拷貝必須僅僅被看作一個高速緩沖器."Read"和"Read-write"是唯一被定義的
permission值.這個參數可以和任何access-type一起使用,并一直是可選的.
這里定義的access-types精確語義將在下面各節中描述.
5.2.3.2'ftp'and'tftp'Access-Types(訪問類型)
FTP或者TFTP訪問類型表明報文主體可以被作為分別使用FTP[RFC-959]或者TFTP
[RFC-783]的文件一樣訪問.對于這些訪問類型來說,以下這些附加參數是強制需要的:
(1)NAME--包含實際主體數據的文件名.
(2)SITE--通過使用給定的協議,文件可以獲取的機構.它必須是一個完整的經過資格認
證的域名,而不是一個隨便取的綽號.
(3)通過使用FTP,任何數據在被重新得到之前,用戶通常被要求為通過site參數命名機構提
供登錄id和密碼.基于安全方面的原因,id和密碼不被作為content-type(內容類型)指定,而必須
從用戶那里獲得.
另外,以下一些參數是可選的:
(1)DirectorY--通過NAME命名的數據可以被重新得到的目錄.
(2)MODE--一個不區分大小寫的字符串,它表明找回信息時要用到的模式.跟TFTP協議
[RFC-783]中所說明一樣,對于"TFTP"訪問類型來說有效的值是"NETASCII","OCTET","
MAIL".
對于"FTP"訪問類型來說有效的值是"ASCII","EBCDIC","IMAGE",和"LOCALn",其中的
"n"是一個十進制整數,例如8.和FTP協議[RFC-959]中說明的一樣,以"A""E""I"and"Ln"代
表相應的類型.注重,對MODE參數來說,"BINARY"和"TENEX"是無效,應該以"OCTET"或者
"IMAGE"或者"LOCAL8"代替.假如MODE參數沒有被具體說明,對TFTP來說,其缺省值
為"NETASCII",其他協議的缺省值為"ASCII".
5.2.3.3'anon(匿名)-ftp'訪問類型
除了指定位置不需要給出用戶名和密碼這一點以外,在其他方面,"anon-ftp"和"ftp"訪問類
型都是一樣的.可以替換的是,ftp協議可以用"anonymous"和相對應的用戶郵件地址作為密碼
登錄.
5.2.3.4'local-file(本地文件)'訪問類型
"local-file"訪問類型表明實際主體可以像本地機器上的文件一樣被訪問.針對這一訪問類
型,定義了兩各附加參數:
(1)NAME--包含實際主體數據的文件名.這個參數對于"local-file"訪問類型來說是不可
少的.
(2)SITE--已知有權訪問數據文件的機器或機器集的指定域.這個選項參數用來描述數據
引用的本地位置,在那里那些文件是可見的.星形將被用來作為匹配一部分域名的通配符,例
如"*.bellcore.com",它表明一組在其上數據直接可見的機器集,但單一的一個通配符將被用來
表示一個完全可用的文件,例如通過一個全局文件系統.
5.2.3.5'mail-server(郵件服務)'訪問類型
'mail-server(郵件服務)'訪問類型用于表示來自郵件服務器的實際主體是可用的.針對這一
訪問類型,定義了兩個附加參數:
(1)SERVER--從中可以獲取實際主體數據的郵件服務器的指定地址.對于"mail-server"
訪問類型來說,這個參數是不可少的.
(2)SUBJECT--用于獲取數據的郵件所使用的主題.注重,不推薦在郵件服務器上鍵入主
題,但這些服務器是已知存在的.這個參數是可選的.
由于郵件服務器所接收的語法是各種各樣的,有些是多行,所以發送到郵件服務器的整個命
令不會像content-type(類容類型)報頭字段中的參數一樣被包含在內.當媒體類型是
"message/external-body(報文/外部主體)"和訪問類型是mail-server(郵件服務)時,將以"phantom
body(影子主體)"作為替代提供.
注重,MIME本身并不定義郵件服務器的語法.而是答應在影子主體(phantombody)包含任
意的郵件服務器命令.實現必須將影子主體(phantombody)包含在報文主體中,這個報文被發
送到郵件服務器以獲取獲取相關數據.
和其他訪問類型不同,mail-server(郵件服務)是異步的,它的發生是不可預知的.基于這個原
因,擁有一種機制是非常重要的,通過它返回的數據能與最初的"message/external-body(報文/
外部主體)"實體相匹配.為了有利于匹配,MIME郵件服務器必須在返回報文和原先的
"message/external-body(報文/外部主體)"實體上使用相同的Content-ID(內容ID).
5.2.3.6External-body(外部主體)安全問題
"Message/external-body(報文/外部主體)"實體產生兩個重要的安全問題:
(1)通過Message/external-body(報文/外部主體)引用訪問數據能使報文接收者有效的執行
一個報文創建者具體指定的操作.因此對于報文創建者,他可以欺騙報文接收者執行他們本不
愿做的某種操作.例如,使接收者在不知情的情況下違反安全策略,創建者可以指定一種操作,
試圖獲取某些未被接受者授權的信息.基于這一原因,有能力處理外部引用的用戶代理必須描
述他們預備讓接受者執行的操作,并在執行它之前,請求得到明確的答應.
'mail-server(郵件服務)'訪問類型非凡輕易受到攻擊,導致接受者發送一個內容由原先報文
發送者指定的新報文.在試圖處理MIME"message/external-body(報文/外部主體)"時,任何被
創建的請求報文都必須包含一個自動產生的明顯標記.
(2)有時MIME會在提供某些報文完整性和真實性保證的環境中被使用.假如是在當前,這
種保證將只被用于報文的實際指示性內容-他們可能會也可能不會被應用到那些通過MIME
的"message/external-body(報文/外部主體)"機制訪問的數據上.非凡的,即使報文系統本身是安
全的,它也有可能破壞特定的訪問機制.
值得注重的是,在MIME機制有效或無效這兩者之一必定存在這個問題.和一個包含某個文
檔的FTP位置的臨時引用也會帶來類似的問題,這個文檔本身包含在一個加密報文的文本中
--唯一的不同是,MIME提供這類信息的自動獲取,而用戶可能會將未獲得保證的信任放置在
這些自動獲取機制中.
5.2.3.7實例與深入說明
當external-body(外部主體)機制被用于和"multipart/alternative"媒體類型相關聯時,他擴展
"mutipart/alternative"的功能以包含下面這種情形,就是相同的實體以相同的格式提供但通過
不同的訪問機制.這樣做的話,報文的創建者必須首先按照先前的格式,再通過先前的訪問機
制定制這些部分.接收者的瀏覽器將根據其格式和訪問機制驗證這個列表.
由于每個廣域文件系統都會產生新的可能性,因此預先知道某個文件從這個文件系統可以
或不可以直接訪問的機器集是非常困難的.所以提供直接使用的文件名和一個或多個這個文
件可以被訪問的位置是有意義的.某個操作可能會試著通過FTP或其他協議,使用匿名或提示
用戶輸入必要的密碼來獲取遠程文件.假如一個外部主體可以通過多重機制被訪問,那么發送
者可以在一個封裝的"multipart/alternative"實體的主體內包含多個"message/external-body"實
體主體.
然而,正如mail-server(郵件服務器)訪問類型所表明的那樣,external-body機制的目的不是用
來限制文件的獲取.除此之外,我們可以想象,例如通過一個視頻服務器獲取視頻片斷的外部
引用.
由于外部主體沒有報頭字段用來聲明它的類型,所以假如它是除無格式US-ASCII文本之
外的其他格式的話,那么出現在"message/external-body"數據主體中內含的報文字段必須用來
聲明外部主體的媒體類型.類似的,除了"7bit"之外的任何Content-transge-encoding(內容傳送
編碼)也必須在此聲明.因此,對于附言格式中涉及的對象,完整的"message/external-body(報文/
外部主體)"報文應該與下面類似:
From:Whomever
To:Someone
Date:Whenever
Subject:whatever
MIME-Version:1.0
Message-ID:<id1@host.com>
Content-Type:multipart/alternative;boundary=42
Content-ID:<id001@guppylake.bellcore.com>

ontent-Type:message/external-body;name="BodyFormats.ps";
site="thumper.bellcore.com";mode="image";
access-type=ANON-FTP;directory="pub";
expiration="Fri,14Jun199119:13:14-0400(EDT)"

Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>

Content-Type:message/external-body;access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri,14Jun199119:13:14-0400(EDT)"

Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>

Content-Type:message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri,14Jun199119:13:14-0400(EDT)"

Content-type:application/postscript
Content-ID:<id42@guppylake.bellcore.com>

getRFC-MIME.DOC

注重上面的例子,"7bit"的缺省Content-transfer-encoding(內容傳送編碼)是假定用于外部附
言數據的.
與"message/partial"類型相似,"message/external-body(報文/外部主體)"媒體類型是透明的,也
就是在外部主體中傳送數據,而不是那個類型的主體和數據一起傳送.因此,對于
"message/partial",外面和里面部分的報頭必須按照同一規則合并.非凡的,這意味著
Content-type(內容類型)和Subject(主題)字段可以不用保護,但From字段必須得到保護.
注重,由于外部主體不和外部主體的引用一起傳送,所以他們必不需要遵循應用于引用本身
的傳送限制.非凡的,Internet郵件傳送可能會附加上7bit和行長度限制,但這些不會自動作用
在二進制外部主體引用上.因此一般來說,Content-Transfer-Encoding(內容傳送編碼)并不是必
須的,盡管這是答應的.
注重,"message/external-body(報文/外部主體)"類型的報文主體遵循RFC822報文的基本語
法.非凡的,任何出現在第一對連續的CRLFs之前的都是報頭信息,而之后的都是主體信息,這
對于絕大多數訪問類型來說都是被忽視的.
5.2.4其他message(報文)子類型
一般來說,MIME的實現必須將未得到承認得"message"子類型當作和
"application/octet-stream"相等效.
未來試圖與電子郵件一同使用的"message"子類型將被限制采用"7bit"編碼.除了"message"
類型之外,某個假如不可能被限于采用"7bit"編碼的類型也是可以使用的.
6.實驗的媒體類型值
為了被通過相互協商得到同意的系統使用,以字符"X-"開頭的媒體類型值是一個私有值.
任何沒有得到嚴格和公開定義的格式必須以'X-"作為前綴來命名,公開具體說明的值將不能
以"X-"作為開頭使用.(在Andrew系統中廣泛使用的較老版本采用"X-BE2"名,所以新的系統
可能選擇采用不同的名字)
大體上來說,"X-"頂層類型的使用效果非常不好.不管何時,只要有可能,實現者應該發明已
存在類型的子類型.在很多情況下,一個"application"的子類型將比一個新的頂層類型更合適.
7.總結
這五個離散的媒體類型為標簽實體如"audio","image"和其他各種數據提供了一個標準化
的機制."multipart"和"message"的復合媒體類型答應在一個單一的報文中出現不同類型實體
的混合和分等級結構.一個出色的參數語法答應數據格式細節的更深入說明,非凡是交替的字
符集的具體說明.附加的可選報頭字段為特定的擴充提供各種機制,這些擴充被許多實現者承
認是值得的.最后,一定數量的有用的媒體類型將通過承認用戶代理為一般性使用提供定義,
非凡如""message/partial"和"message/external-body".
8.安全性考慮
安全問題在"application/postscript"類型,"message/external-body"類型,和RFC2048的上
下文中討論.實現者應非凡注重任何媒體類型的安全性暗示,這些媒體類型會導致在接收者環
境中任何操作的執行.在這種情況下,對"application/postscript"類型的討論可能會被當作一種
考慮其他媒體類型和遠程執行能力的模型.
9.作者地址
需要更多的信息,可以通過以下的因特網郵件聯系該文擋的作者：
NedFreed
InnosoftInternational,Inc.
1050EastGarveyAvenueSouth
WestCovina,CA91790
USA

電話:+18189193600
傳真:+18189193614
EMail:ned@innosoft.com

NathanielS.Borenstein
FirstVirtualHoldings
25WashingtonAvenue
Morristown,NJ07960
USA

電話:+12015408967
傳真:+12019933032
EMail:nsb@nsb.fv.com


多用途互聯網郵件擴展協議是因特網工程任務工作小組對擴展RFC822工作的成果.你可
以通過以下方式聯系該小組主席GregVaudreuil:

GregoryM.Vaudreuil
OctelNetworkServices
17080Dallasparkway
Dallas,TX75248-1905
USA

EMail:Greg.Vaudreuil@Octel.Com

附錄A：語法集
附錄包含了本文檔具體說明的所有語法地完整BNF語法。
然而，這個語法是不完整的。它通過名字和RFC822中定義的多個語法規則相關聯。
為了不在此重復這些定義和冒造成兩者之間無心的差異的危險，本文檔只是給讀者簡單的涉
及RFC822中其余的定義。碰到未定義的術語，可查閱RFC822中的定義。
boundary:=0*69<bchars>bcharsnospace
bchars:=bcharsnospace/""
bcharsnospace:=DIGIT/ALPHA/"'"/"("/")"/
"+"/"_"/","/"-"/"."/
"/"/":"/"="/"?"
body-part:=<"message"asdefinedinRFC822,withall
headerfieldsoptional,notstartingwiththe
specifieddash-boundary,andwiththe
delimiternotoccurringanywhereinthe
bodypart.Notethatthesemanticsofa
partdifferfromthesemanticsofamessage,
asdescribedinthetext.>
close-delimiter:=delimiter"--"
dash-boundary:="--"boundary
;boundarytakenfromthevalueof
;boundaryparameterofthe
;Content-Typefield.
delimiter:=CRLFdash-boundary
discard-text:=*(*textCRLF)
;Maybeignoredordiscarded.
encapsulation:=delimitertransport-padding
CRLFbody-part
epilogue:=discard-text
multipart-body:=[preambleCRLF]
dash-boundarytransport-paddingCRLF
body-part*encapsulation
close-delimitertransport-padding
[CRLFepilogue]
preamble:=discard-text
transport-padding:=*LWSP-char
；創建者絕對不能產生非零長度的transport-padding，
；但接收方必須能夠處理由報文傳輸添加的padding。