多用途網際網路郵件擴展(英語:Multipurpose Internet Mail Extensions,縮寫:MIME)是一個網際網路標準,它擴充了電子郵件標準,使其能夠支援:
- 非ASCII字元文字;
- 非文字格式附件(二進位制、聲音、圖片等);
- 由多部分(multiple parts)組成的訊息體;
- 包含非ASCII字元的標頭資訊(Header information)。這個標準被定義於 RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049 等RFC中。
此條目可參照英語維基百科相應條目來擴充。 (2020年10月1日) |
MIME改善了由 RFC 822 轉變而來的 RFC 2822 ,這些舊標準規定電子郵件標準並不允許在郵件訊息中使用7位ASCII字元集以外的字元。正因如此,一些非英語字元訊息和二進制檔案,圖像,聲音等非文字訊息原本都不能在電子郵件中傳輸(MIME可以)。MIME規定了用於表示各種各樣的資料類型的符號化方法。此外,在全球資訊網中使用的HTTP協定中也使用了MIME的框架,標準被擴展為網際網路媒體形式。
MIME headers
MIME是通過標準化電子郵件報文的頭部的附加域(fields)而實現的;這些頭部的附加域,描述新的報文類型的內容和組織形式。
MIME版本(MIME-Version),這個標頭區域在郵件訊息的報文用一個版本號碼來指明訊息遵從的MIME規範版本。目前版本是1.0。
MIME-Version: 1.0
內容類型(Content-Type),這個標頭區域用於指定資訊的類型。一般以下面的形式呈現。
Content-Type: [type]/[subtype]; parameter
type有以下的形式:
- Text:用於標準化地表示的文字訊息,文字訊息可以是多種字元集和或者多種格式的;
- Multipart:用於連接訊息體的多個部分構成一個訊息,這些部分可以是不同類型的資料;
- Application:用於傳輸應用程式資料或者二進位資料;
- Message:用於包裝一個E-mail訊息;
- Image:用於傳輸靜態圖片資料;
- Audio:用於傳輸音訊或者音聲資料;
- Video:用於傳輸動態影像資料,可以是與音訊編輯在一起的視訊資料格式;
- Font:用於傳輸字型檔案;
- Model:用於傳輸3D模型檔案。
subtype用於指定type的詳細形式。content-type/subtype配對的集合和與此相關的參數,將隨著時間而增長。為了確保這些值在一個有序而且公開的狀態下開發,MIME使用Internet Assigned Numbers Authority (IANA)作為中心的序號產生器制來管理這些值。常用的subtype值如下所示:
- text/plain(純文字)
- text/html(HTML檔案)
- application/xhtml+xml(XHTML檔案)
- image/gif(GIF圖片)
- image/jpeg(JPEG圖片)【PHP中為:image/pjpeg】
- image/png(PNG圖片)【PHP中為:image/x-png】
- audio/mpeg(MP3音訊)
- audio/aac(AAC音訊)
- video/mpeg(MPEG影片)
- video/mp4(MPEG-4影片)
- application/octet-stream(任意的二進位資料)
- application/pdf(PDF檔案)
- application/msword(Microsoft Word檔案)
- application/vnd.openxmlformats-officedocument.wordprocessingml.document(Microsoft Word 2007檔案)
- application/vnd.wap.xhtml+xml (wap1.0+)
- application/xhtml+xml (wap2.0+)
- message/rfc822(RFC 822形式)
- multipart/alternative(HTML郵件的HTML形式和純文字形式,相同內容使用不同形式表示)
- application/x-www-form-urlencoded(使用HTTP的POST方法送出的表單)
- multipart/form-data(同上,但主要用於表單送出時伴隨檔案上傳的場合)
此外,尚未被接受為正式資料類型的subtype,可以使用x-開始的獨立名稱(例如application/x-gzip)。vnd-開始的原生名稱也可以使用(例:application/vnd.ms-excel)。
parameter可以用來指定附加的資訊,更多情況下是用於指定text/plain和text/htm等的文字編碼方式的charset參數。MIME根據type制定了預設的subtype,當客戶端不能確定訊息的subtype的情況下,訊息被看作預設的subtype進行處理。Text預設是text/plain,Application預設是application/octet-stream而Multipart預設情況下被看作multipart/mixed。
內容組態(Content-Disposition),原始的MIME只描述郵件內容的結構,並不會處理表現類型的問題。內容組態(Content-Disposition)在RFC 2183 (頁面存檔備份,存於網際網路檔案館)中被添加,用來指明MIME的表現類型。MIME的每一部分可以添加下列組態。
- inline 添加此組態後客戶端應自動展示資訊。
- attachment 添加此組態後客戶端在接受到資訊後不自動展示,需要使用者自己選擇相應的方法處理資訊。
Content-Disposition欄位也提供了一些參數。如檔名,檔案的建立日期和修改日期等,使郵件客戶端可以儲存附件。 以下是一個範例。
Content-Disposition: attachment; filename=genome.jpeg; modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
儘管有些郵件客戶端僅在Content-Type的參數中添加了檔名來通訊,但這是不推薦的。正確的做法是在Content-Disposition中指定filename或是同時在Content-Type和Content-Disposition中指定name和filename的參數。在HTTP中Content-Disposition: attachment通常用來提示客戶端將回應體作為下載檔案,而不是在頁面中展示它。filename參數是預設的下載檔名。
內容傳輸編碼(Content-Transfer-Encoding),這個區域使指定ASCII以外的文字編碼方式成為可能。形式如下:
Content-Transfer-Encoding: [mechanism]
其中,mechanism的值可以指定為「7bit」,「8bit」,「binary」,「quoted-printable」,「base64」。
7位元ASCII碼。
8位元ASCII碼。
Not only may non-ASCII characters be present but the lines are not necessarily short enough for SMTP transport.
因為歐洲的一些文字和ASCII字元集中的某些字元有部分相同。如果郵件訊息使用的是這些語言的話,與ASCII重疊的那些字元可以原樣使用,ASCII字元集中不存在的字元採用形如「=??」的方法編碼。這裡「??」需要用將字元編碼後的16進制數字來指定。採用quoted-printable編碼的訊息,長度不會變得太長,而且大部分都是ASCII中的字元,即使不通過解碼也大致可以讀懂訊息的內容。
base64是一種將二進位的01序列轉化成ASCII字元的編碼方式。編碼後的文字或者二進位訊息,就可以運用SMTP等只支援ASCII字元的協定傳送了。Base64一般被認為會平均增加33%的報文長度,而且,經過編碼的訊息對於人類來說是不可讀的。
這個值是預留的擴充。
參見
- 8BITMIME
- Unicode and email
- Binary-to-text encoding
- DIME—微軟提議的一種技術,被稱為DIME,是部分改變的MIME,最初應用於Web服務
- Extended SMTP (ESMTP)
- Mailcap
- mime.types
- Object Linking and Embedding (OLE)
- S/MIME
- SOAP with Attachments
- Uuencoding
- VPIM
參考
- 備註
- RFC 1426
- SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. February 1993.
- RFC 1847
- Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
- RFC 3156
- MIME Security with OpenPGP
- RFC 2045
- MIME Part One: Format of Internet Message Bodies.
- RFC 2046
- MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
- RFC 2047
- MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
- RFC 4288
- MIME Part Four: Media Type Specifications and Registration Procedures.
- RFC 4289
- MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
- RFC 2049
- MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
- RFC 2183
- Communicating Presentation Information in Internet Messages: The Content-Disposition Header. Troost, R., Dorner, S. and K. Moore. August 1997.
- RFC 2231
- MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
- RFC 2387
- The MIME Multipart/Related Content-type
- RFC 1521
- Mechanisms for Specifying and Describing the Format of Internet Message Bodies
外部連結
- MIME類型
- 追蹤網際網路郵件草稿與標準的Blog
- IANA已註冊的MIME媒體類型列表 (頁面存檔備份,存於網際網路檔案館)
- 字元集列表(頁面存檔備份,存於網際網路檔案館)
- Debian Wiki上的MIME (頁面存檔備份,存於網際網路檔案館)
- MIME的更詳細綜述(1993年)
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.