http Content-Type 知多少

時間 2020-06-18

原文原文鏈接

前言

做爲前端開發，工做中少不了與接口請求打交道。對於常見的content-type，也能說上來幾個，感受還算了解。直到有一天，我要在查看google的批量接口合併時發現Content-Type: multipart/mixed以及Content-Type: application/http時，有點措手不及。趕忙深刻研究下Content-Type相關內容來彌補下本身的不足，從前端的角度來看看Content-Type。javascript

Content-Type

Content-Type:實體頭部用於指示資源的MIME類型。若是未指定 ContentType，默認爲text/html 有兩種場景：在請求中 (如POST 或 PUT)，客戶端告訴服務器實際發送的數據類型。html

在響應中，Content-Type標頭告訴客戶端實際返回的內容的內容類型。瀏覽器會在某些狀況下進行MIME查找，並不必定遵循此標題的值; 爲了防止這種行爲，能夠將標題 X-Content-Type-Options 設置爲 nosniff。前端

簡而言之就是標識資源或者所需資源的MIME類型。java

句法以下：web

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

參數通常media-type、charset、boundary三種。咱們的關注點在於media-type的取值以及其適用場景。json

media-type

更多的是做爲MIME type( Multipurpose Internet Mail Extensions)出現，即多用途Internet郵件擴展。
其目的是用一種標準化的方式來標識文檔的性質和格式。
瀏覽器一般使用MIME類型（而不是文件擴展名）來肯定如何處理文檔；
所以服務器設置正確以將正確的MIME類型附加到響應對象的頭部是很是重要的。api

結構

MIME 組成結構以下：由類型與子類型兩個字符串中間用'/'分隔而組成。不容許空格存在。對大小寫不敏感，但傳統都是小寫。容許額外參數，如後面所示：瀏覽器

type/subtype;parameter=value

其中：bash

type對應通用類目，例如：text/video等。
subtype對應準確的子類，例如text下面細分爲plain(純文本)、html(html源碼)、calendar（.ics）文件等。
parameter可選通常是charset或者bundaary等。

Types

類目包括兩種類型：獨立類型和Multipart類型。服務器

獨立類型

獨立類型指只表明一個單獨的文件或者媒體的類型，代表了對文件的分類。常見類型和實例以下：

text 文本數據包括一些人類可讀的內容或者源碼。例如：text/plain, text/csv, text/html.
application 數據爲二進制的一種，例如application/octet-stream,application/pdf,application/pkcs8,application/zip.
audio 音頻或者音樂數據，例如audio/mpeg, audio/vorbis
video 視頻數據或者文件，例如video/mp4
image 圖像或圖形數據，包括位圖和矢量靜止圖像以及靜止圖像格式的動畫版本。例如image/gif, image/png, image/jpeg, image/bmp, image/webp, image/x-icon

Multipart類型

Multipart類型指明被分爲幾部分的一種文檔的類目，且常常有不一樣的MIME類型。也能夠用來表示屬於相同事物的多個且獨立的文件，這些獨立的文件構成一個複雜的文檔。在電子郵件場景中常見。
有兩種Multipart類型：message和multipart。

message 一個包括其餘信息的消息，經常使用於下面的場景，例如指明一個郵件包含轉發信息或者在多種信息的狀況下，容許以chunk的形式發送數據量很大的信息。包括message/rfc822和message/partial
multipart
由多個不一樣MIME類型組件構成的數據，例如 multipart/form-data(使用FormData API生成的數據)

看完了基本定義，下面看看常見的類型及使用場景。

常見類型及使用場景

靜態資源、圖片、媒體類

對於靜態資源、圖片和媒體類，也就是text、image、video等比較清晰明瞭，再也不詳細描述。

application類

application/json

隨着json這種輕量級的數據交互格式的流行，特別是和腳本交互的便利，使得在先後接口中，愈來愈多采用json格式。對於http協議來講，最終傳輸的仍是字符。這裏再也不多進行描述。
application/x-www-form-urlencoded 做爲表單提交中默認的類型，其代表數據以標準的編碼格式被編碼爲鍵值對。數據被編碼成以 '&' 分隔的鍵-值對, 同時以 '=' 分隔鍵和值. 非字母或數字的字符會被 percent-encoding: 這也就是爲何這種類型不支持二進制數據的緣由 (應使用 multipart/form-data 代替).
咱們以新浪爲例，能夠看到其請求報文(formdata那裏選擇，view source能夠看得比較清楚)：

multipart/form-data 這裏爲了對比，就也放到這裏來講了。
通常用於涉及文件的表單提交，用於post請求，其格式以下：
```
Content-Type: multipart/form-data; boundary=aBoundaryString
```
其中boundary指明瞭請求體中每部分的分割符(對於multipart的類目，都會存在該字段，以區分請求體中數據的分割)，其請求體中則是對應表單每部分的內容。每部分都會有本身的請求體和相關內容。
例如以下的文檔結構：

<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
  <input type="text" name="myTextField">
  <input type="checkbox" name="myCheckBox">Check</input>
  <input type="file" name="myFile">
  <button>Send the file</button>
</form>

其請求信息以下：

POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
// 以 ---------------------------8721656041911415653955004498 做爲分割符
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
// 分段一 文本相關信息
Content-Disposition: form-data; name="myTextField"
// 對應value
Test
-----------------------------8721656041911415653955004498
// checkbox
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
// 文件
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--

application/javascript application/x-javascript text/javascript
對於js文件，常見MIME類型爲text/javascript，可是前兩種應該會有見到過。三者之間多少仍是有點區別的。
傳統的js程序對應的MIME類型爲text/javascript，其餘的還有"application/x-javascript"（x前綴表示這是實驗性類型），由於text/javascript是最多見的類型，因此RFC4329定義了「text/javascript」。不過，js文件實際上並非真正的文本類型，所以推出了application/javascript類型，不過現行的支持性並很差，因此經常會用application/x-javascript來代替。
application/zip application/gzip
zip 對應zip壓縮文件，gzip是若干種文件壓縮程序的簡稱，一般指GNU計劃的實現，此處的gzip表明GNU zip。
application/http
這一種你們可能就不常見了，從類型能夠知道，是http請求，但具體用途仍是要翻下規範才能找到的。
此類型包含的http請求包含在binary消息體中，在郵件協議傳輸中須要指明Content-Transfer-Encoding。
在批量處理請求時會遇到，其表現以下：

--batch_0123456789
Content-Type: application/http
Content-ID: 
// 必須的字段，代表傳送內容的編碼格式 即二進制流
Content-Transfer-Encoding: binary

POST https://www.googleapis.com/analytics/v3/management/accounts/XXXXXX/webproperties/UA-XXXXXX-1/customDimensions
Content-Type: application/json
Content-Length: 68

{
 "name": "Campaign Group",
 "scope": "SESSION",
 "active": true
}

multipart類型

正如上文所述，multipart通常對應單個消息頭對應多個消息體。常見語法以下:

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

其中boundary字段是必須的，用於區分消息體中的數據邊界，通常是兩個'-'的格式做爲該端的開頭，例如：

--gc0p4Jq0M2Yt08jU534c0p

咱們主要關注的也就是下面幾種：

multipart/form-data 見上面application部分。下面這幾部分可能不是那麼常見，不過仍是能夠了解一下，以避免遇到的時候懵逼。
multipart/mixed
該類型用於，消息體由多個獨立的部分組成且想連續的展現。而且子數據類型有任一種沒法被識別(此處指被瀏覽器直接識別的類型，例如text等)的類型時，都應該爲mixed。
歸納而言就是該郵件有二進制內容，非能夠直接識別的內容

例如：

POST /batch/farm/v1 HTTP/1.1
Authorization: Bearer your_auth_token
Host: www.googleapis.com
Content-Type: multipart/mixed; boundary=batch_foobarbaz
Content-Length: total_content_length

--batch_foobarbaz
// 子內容爲http請求 不過是boundary編碼過的
Content-Type: application/http
Content-ID: <item1:12930812@barnyard.example.com>

GET /farm/v1/animals/pony

--batch_foobarbaz
Content-Type: application/http
Content-ID: <item2:12930812@barnyard.example.com>

PUT /farm/v1/animals/sheep
Content-Type: application/json
Content-Length: part_content_length
If-Match: "etag/sheep"

{
  "animalName": "sheep",
  "animalAge": "5"
  "peltColor": "green",
}

--batch_foobarbaz
Content-Type: application/http
Content-ID: <item3:12930812@barnyard.example.com>

GET /farm/v1/animals
If-None-Match: "etag/animals"

--batch_foobarbaz--

這裏消息體中的內容就是http請求，在google批量接口協議中用使用。

multipart/alternative
該類型與mixed的語法相同，但語義不一樣。其代表，消息體中的不一樣部分應該是相同信息的不一樣版本。即內容相同傳輸類型不一樣，以適應不一樣的接受者。
仍是舉例：

From:  Nathaniel Borenstein <nsb@bellcore.com> 
To: Ned Freed <ned@innosoft.com> 
Subject: Formatted text mail 
MIME-Version: 1.0 
Content-Type: multipart/alternative; boundary=boundary42 


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

...plain text version of message goes here.... 

--boundary42 
Content-Type: text/richtext 

.... richtext version of same message goes here ... 
--boundary42 
Content-Type: text/x-whatever 

.... fanciest formatted version of same  message  goes  here 
... 
--boundary42--

假如用戶的系統能夠識別 text/x-whatever 類型，那麼其將會只看到這一部分。不一樣的用戶看到什麼內容取決於其系統支持何種類型。