1. 介紹
自從1982年發佈以來，RFC822已經定義了一個在Internet上傳輸文本郵件的標準格式。RFC822格式是如此的成功，它已經完全或部分的爲大家所接受，其程度甚至超越了Internet或在RFC821中定義的Internet SMTP。也正是由於這種格式被廣泛的使用，所以許多限制因素日益約束着使用者羣體。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
RFC822被制定爲用來指定文本信息格式。這樣，非文本信息――如包含音頻或圖像的多媒體信息――就完全沒有被提及。甚至對一些文本的情況也是這樣。RFC822不適用於那些需要多於US－ASCII字符集內容的使用者。因爲RFC822沒有定義一種機制，以允許郵件包含音頻、視頻、亞洲語言的文本甚至一些歐洲的語言文本，所以需要一個額外的規範來進行說明。
RFC821/822中的一個基於郵件系統的明顯限制，就是將電子郵件消息(message)內容限制在一些由7位的US-ASCII字符組成的短行中（每行1000字節或更少[RFC821]）。這就迫使使用者在用本地用戶代理（UA—User Agent，用來收發郵件的程序）發送他們的郵件之前，先要將將要發送的非文本數據轉換爲可打印的7位的US-ASCII字符。當前在Internet上使用的編碼方式有：純十六進制、uuencode、RFC1421中說明的base 64、ATK(the Andrew Toolkit Representation)及一些其它方式。
當爲在RFC822主機與X.400主機之間交換郵件信息而設計網關時，RFC822的侷限性就更加明顯了。X.400[X400]指定了一種在電子郵件消息中包含非文本內容的機制。當前，從X.400消息到RFC822消息的映射標準規定，X.400消息中的非文本部分必須要轉換爲IA5Text格式，否則，這些內容就會被丟棄，並在丟棄即將發生時，通報RFC822的使用者。當一個用戶丟掉了他想接收的內容時，這顯然是十分另人不快的。即使在用戶代理不能處理非文本內容的時候，用戶也可以對其採取一些額外的機制，來提取有用的信息。另外，這種處理也沒有考慮到：消息最後可能會被網關轉發到支持非文本信息的X.400消息處理系統中。
這篇文檔描述了幾種機制，將它們聯合起來，可以解決大部分的這類問題，而不會引入與RFC822不兼容的問題。詳細的說，它描述了：
(1) “MIME-Version”頭字段。它使用一個版本號來說明消息適用於MIME，而且允許郵件處理代理將這類消息與其它由舊版本或不適用的軟件所產生的消息相區別。
(2) 在RFC1049中歸納的“Content-Type”頭字段。用來指定消息數據的媒體類型(media type)及子類型，以及指定這些數據的本地表示方法（規範形式）。
(3) “Content-Transfer-Encoding”頭字段。用來指定應用於主體(body)的編碼轉換方式及結果所處的範圍。編碼轉換不同於恆等轉換，它通常用於使數據通過那些有數據或字符集限制的郵件傳輸機制。
(4) 兩個附加的頭字段：“Content-ID”、“Content-Description”。它們被用來更深層的描述主體(body)中的數據。
這篇文檔中的所有的頭字段定義都服從於RFC822中規定的句法規則。特別的，除了“Content-Disposition”以外，所有的這些頭字段都可以包含RFC822註釋。這些註釋沒有實際意義，應該在MIME處理過程中忽略。
最後，爲了說明及促進互用性，RFC2049爲以上機制的子集提供了一個基本的適用性聲明。它定義了與本文檔相適應的最低限度。
歷史註釋：在第一次閱讀時，這組文檔中所描述的幾個機制看起來會有些奇怪或具有巴洛克風格。但要注意，對於開發這組文檔的團體而言，與現有標準兼容以及遇到現有習慣時的穩健性，這兩者具有相同的優先級。特別是“兼容性”永遠優先於“簡潔”。
請查閱當前版本的《因特網官方標準》(“Internet Official Protocol Standards”)以得到本協議的標準化狀態及情況。RFC 822和STD3，RFC1123也提供了MIME的基本背景，符合MIME的實現都不會違背它們。另外，MIME的實現者也許會關心幾個另外的RFC文檔，特別是RFC1344、RFC1345和RFC1524。
2. 定義、約定和一般的BNF語法
雖然這組文檔所定義的機制都以文字的形式給出，但仍有一部分是由RFC 822定義的BNF符號所描述。爲了瞭解這組文檔，實現者需要熟悉這些符號，並參考RFC 822，以得到這些擴充的BNF符號的完整解釋。
本文檔中的一些擴展BNF所構成的名字參考了RFC 822中的句法規則。或要獲得完整的語法則要組合如下內容：本系列每個文檔中收集了語法的附錄、RFC 822中定義的BNF以及在RFC 1123中對RFC 822 所進行的修正。（其中給出了“return”、“data”、“mailbox”的語法變化）
在這組文檔中，所有的數值字及字節的值都由十進制的形式給出。所有的媒體類型（media type）、子類型以及參數名稱都是大小寫無關的。然而，除非特別說明，否則參數內容是大小寫相關的。
格式註釋：這部分的“註釋”提供了一些不重要的信息，在閱讀時可以跳過它們而不會錯過任何本質的東西。添加這些註釋的基本目的是爲了說明關於這系列文檔的基礎原理，或是爲了將其恰當地放置於歷史或發展過程中。這些信息，可以被那些只關心建立實現的人所忽略，但對那些希望懂得爲什麼某種設計會被應用的人來說，這些信息還是會有一定用處的。
2.1 CRLF
在這系列文檔中，術語CRLF指一個US-ASCII字符序列。它由兩個字符組成：CR（十進制值爲13）和LF（十進制值爲10），它們按順序放在一起，構成RFC 822郵件的換行。
2.2 字符集 （Character Set）
在MIME中，術語“字符集”（character set）被用來表示一種將字節序列轉換成字符序列的方法。注意，反方向不需要絕對的、明確的轉換，因爲並不是所有的字符都可以被一個已知的字符集描述，而且一個字符集可能提供多於一個的字節序列，來表示某字符序列。
本定義允許將各種類型的字符編碼做爲字符集使用，如從簡單的單表映射（如US-ASCII）到多表轉換方法（如使用ISO 2022技術）等。然而與MIME字符集名稱相關的定義則必須完全說明所要執行的映射。特別的，不允許使用外部描述信息來決定精確的映射。
註釋：術語字符集(“character set”)最初是用來描述一些簡單的方案如US-ASCII和ISO-8859-1的，它們都是從單一字節到單一字符的一對一映射。多字節編碼字符集和轉換方法使得情況更加複雜。例如，一些團體使用術語“character encoding”，而不是MIME中所使用的術語“character set”來表示字符集，而且使用“coded character set”來抽象的表示從整數（而不是字節）到字符的映射。
2.3 消息 （Message）
術語“消息”（Message）在沒有進一步限定的時候，表示的是在Internet上傳輸的（完整或“頂層”的）RFC822消息，或者表示壓縮在“message/rfc822”或“message/partial”中的內容。
2.4 實體 （Entity）
術語“實體”（Entity）特指MIME定義的頭字段(header field)及內容(content),它們存在於消息(message)及多部分實體的一部分之中。對這些實體的規範是MIME的基本內容。因爲一個實體的內容經常被稱爲“主體”(“body”)，所以關於實體主體說法是有意義的。任何字段都可以出現在實體頭信息中，但是隻有那些以“content-”開頭的字段有真實的、與MIME相關的意義。注意，這並不意味着它們沒有意義，一個沒有MIME頭字段的實體（或消息）的意義由RFC822所定義。
2.5 部分主體 （Body Part）
“body part”指的是多部分實體(mulitpart entity)中的一個實體(entity)。
2.6 主體 （Body）
在沒做進一步說明的時候，術語“主體”（body）指的是一個實體(entity)的主體部分。也就是指“消息”(message)或“部分主體”(body part)的主體部分。
註釋：很明顯，以上四個概念被循環定義。因爲MIME消息的整個結構就是遞歸的，所以這種情況不可避免。
2.7 7位的數據 （7bit Data）
“7位的數據”(7bit Data)所描述的是相對較短的數據行：每行有998個或更少的8位字節內容，行分隔符爲CRLF序列[RFC-821]。其中，每一個8位字節的值都不可以大於十進制的127，也不能爲NUL(十進制的0)，而且CR（十進制值爲13）和LF（十進制值爲10）字節只可以出現在CRLF序列中。
2.8 8位的數據 （8bit Data）
“8位的數據”(8bit Data)所描述的是相對較短的數據行：每行有998個或更少的8位字節內容，行分隔符爲CRLF序列[RFC-821]。其但是字節的值可以大於十進制的127。與“7bit data”一樣， CR（十進制值爲13）和LF（十進制值爲10）字節只可以出現在CRLF序列中，字節的值不能爲NUL(十進制的0)。
2.9 二進制數據 （Binary Data）
“二進制數據”（Binary Data）是指可以包含任何字節序列的數據。
2.10 行 (Lines)
“行”（Lines）被定義爲由CRLF分隔的字節序列。這與RFC 821及RFC 822一致。“行”(Lines)是指消息(Message)中的數據單位，它可以符合或不符合用戶代理（user agent）所顯示的真實情形。