網路標準之永遠是1.0版本的 MIME
簡介
無規矩不成方圓,無標準不成網路通訊。正是在各種網路協議和標準的基礎之上,才構建了我們現在流行的網際網路。今天給大家介紹的就是一個網路標準格式,叫做MIME,它的全稱是Multipurpose Internet Mail Extensions,翻譯過來就是多用途Internet郵件擴充套件。
那麼有小夥伴開始疑惑了,原來是一個郵件的擴充套件協議,那麼它跟我們使用的Internet網路有什麼關係呢?
不急,我們慢慢道來。
MIME詳解
在很久很久以前,計算機的一種流行的應用就是發郵件,最開始的時候,計算機世界的編碼方式就只有ASCII一種,但是隨著時間的推移和各種應用需求的激增,ASCII格式已經不能滿足我們的需求了,格式多型別的同時也照成了互相通訊之間的困難,於是一個統一的訊息格式標準產生了,這個就是MIME。
MIME可以讓郵件不僅支援ASCII,還可以支援其他的編碼方式。同時支援圖片、音訊、影片和應用程式等多種附件。
訊息體還可以支援多個part的集合,當這樣的訊息郵件使用MIME格式編碼之後,就可以透過標準的郵件協議,比如SMTP、POP、IMAP等進行傳送了。
因為MIME是一個標準,所以只要符合這種標準的郵件都能夠被解析成功。
很快,MIME就在郵件世界被廣泛應用,但是網際網路已經發展到使用流行的HTTP協議來訪問全球資訊網的時候了,MIME中定義的各種content types很自然的也成了其他協議中使用的content標準。
這種content types是在MIME頭中定義的,應用程式接收到content type之後,會根據型別中指定的訊息型別,來採用對應的應用程式對訊息內容進行解析。
MIME頭
MIME頭很重要,是應用程式用來判斷訊息格式的首要依據。MIME頭可以包含下面的欄位。
MIME-Version
如果存在這個訊息頭,說明這個訊息是遵循的是MIME格式。它的值通常是1.0。
有細心的小夥伴可以能要問了,既然有1.0,那麼有沒有1.1或者2.0呢?
很抱歉,答案是沒有。因為根據MIME 共同建立者 Nathaniel Borenstein 的說法,雖然引入MIME版本號是為了在後續中對MIME進行修改和升級。但是因為MIME規範並沒有為未來MIME版本的升級進行良好的設計,所以不同的人可能對MIME版本升級後的處理方式都是不一樣的。從而導致在MIME廣泛應用的今天,很難對MIME規範進行升級。
所以,就使用1.0吧。
Content-Type
如果屬性HTTP協議的同學,對這個頭應該很熟悉了吧,這個頭表示的是訊息體的型別,包含了型別和子型別,比如:
我們常說的MIME type就是指這個標籤。
下面是常用的MIME type:
Content-Disposition
Content-Disposition是在RFC 2183中新增的一個欄位,表示的是訊息的展示樣式。因為之前的訊息只是定義了它的訊息格式,並沒有考慮訊息是如何展示的問題,尤其是對於郵件來說。
比如郵件中插入了一個圖片,那麼這個圖片是在我們讀訊息的時候內聯展示呢?還是以附件的形式,必須要使用者下載才能看到呢?
如果是在HTTP中,響應頭欄位Content-Disposition:attachment 通常用作提示客戶端將響應正文呈現為可下載檔案。通常,當收到這樣的響應時,Web瀏覽器會提示使用者將其內容儲存為檔案,而不是將其顯示為瀏覽器視窗中的頁面。
Content-Transfer-Encoding
這個欄位是做什麼用的呢?
我們知道,隨著資料格式越來越多,傳統的ASCII已經不能支援龐大的內容表示形式,所以出現了超出ASCII範圍的內容表示形式如Unicode。
但是對於SMTP伺服器來說,能夠傳輸或者認識的編碼是有限的,如果要傳輸二進位制內容,則需要使用一定的transfer encodings方式對二進位制內容進行轉換。這就是Content-Transfer-Encoding的意義。
根據RFC和IANA的定義,有下面幾個transfer encodings方式:
具體transfer encodings的含義,可以參考我後續的文章,這裡只做簡單的介紹。
對於普通的SMTP伺服器來說,可以支援7bit、quoted-printable和base64這三種編碼方式。
對於8BITMIME SMTP extension的SMTP伺服器來說,還支援8bit這種編碼方式。
對於支援BINARYMIME SMTP extension的SMTP伺服器來說,還支援binary這種編碼方式。
Encoded-Word
根據RFC 2822,確認訊息頭中的欄位名和值必須使用ASCII字元。如果訊息中包含非ASCII字元,則需要進行編碼。這個編碼就是encoded-word 。
編碼的格式如下:
charset表示的是原訊息的編碼,encoding表示的是使用的編碼方式,encoded text是編碼後的訊息。
Multipart messages
最後,介紹一下Multipart messages,我們知道一個訊息是有對應的訊息型別:Content-Type的。
如果是複雜的訊息,那麼它裡面的訊息型別可能不止一種。所以這時候就需要用到Multipart messages,也就是將訊息分為多個部分,每個部分都有一個Content-Type。
這種型別在郵件中比較常見。下面是一個Multipart messages的例子,在Content-Type中指定了一個訊息的分割標記boundary。
來自 “ https://mp.weixin.qq.com/s/gFEq4DFRtoAVpXDzKcscmA ”, 原文作者:程式那些事;原文連結:https://mp.weixin.qq.com/s/gFEq4DFRtoAVpXDzKcscmA,如有侵權,請聯絡管理員刪除。
相關文章
- 網路標準之:永遠是1.0版本的MIME
- 倚網路安全標準興網路強國之夢
- 網路標準之:IANA定義的傳輸編碼
- 1個公式讓你永遠不缺網際網路專案公式
- 部落格時代之殤:網際網路上23%的內容將永遠消失
- 無線網路安全標準(轉)
- 重構之美-跨越Web標準,觸碰語義網[分離:程式設計師請“遠離”Web標準]Web程式設計師
- k8s~helm映象版本永遠不要用latestK8S
- 網際網路創業標準,你符合嗎?創業
- 網路安全標準體系啟動個人資訊保護等標準先行
- Oracle企業版、標準版本、簡化版之間的區別Oracle
- TLSv 1.3 網路安全標準通過 帶來更安全的網路環境TLS
- 無線感測器網路ZigBee與Z-Wave的標準之爭
- 永遠成長的蘋果樹蘋果
- Evercookie(永遠刪不掉的cookie)Cookie
- 人民日報批網路問政”萬能回覆”:永遠在“等待”
- 圖解神經網路之--1.0 感知器(Perceptron)圖解神經網路
- 可行動網路應用物件技術標準物件
- 影視永遠不懂遊戲遊戲
- 標準庫之template
- 物聯網標準將是一個難解的問題
- 什麼是MIME型別型別
- 阿里、京東、美團等主流網際網路公司的最新招聘標準阿里
- 讓網站不停止,永遠持續執行網站
- 微軟曝“永恆之黑”漏洞,或成網路攻擊“暗道”微軟
- volley建立標準的網路請求(Making a Standard Request)
- 程式設計師與軟體工程是永遠的矛盾嗎? (轉)程式設計師軟體工程
- 百度、阿里、騰訊等大型網際網路的Java程式設計師評級標準是什麼?阿里Java程式設計師
- UNIX作業系統的版本與標準(轉)作業系統
- 軟體測試的准入準出是什麼?標準是什麼?
- 18-網路安全測評技術與標準
- 電視連續劇風雲--雄霸天下主題曲-永遠永遠
- 2014年成為網際網路極客的14個標準
- 全網開發網站搭建教程篇之Python 標準庫之 sys網站Python
- golang標準庫之 fmtGolang
- 標準庫之 random 模組random
- Battle.net更名 “戰網”永遠成為歷史BAT
- 郵件協議之MIME協議