什麼是multipart/form-data請求

根據http/1.1 rfc 2616的協議規定，咱們的請求方式只有OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE等，那爲爲什麼咱們還會有multipart/form-data請求之說呢？這就要從頭來講了。

http協議規定以ASCII碼傳輸，創建在tcp，ip協議智商的引用規範，規範內容把http請求分紅3個部分，狀態行，請求頭，請求體。全部的方法，實現都是圍繞如何使用和組織這三部分來完成了，萬變不離其宗，http的知識你們能夠問度娘。

既然上面請求方式裏面沒有multipart/form-data那這個請求又是怎麼回事呢，實際上是一回事，multipart/form-data也是在post基礎上演變而來的，具體以下：

1.multipart/form-data的基礎方式是post，也就是說經過post組合方式來實現的。
2.multipart/form-data於post方法的不一樣之處在於請求頭和請求體。
3.multipart/form-data的請求頭必須包含一個特殊的頭信息：Content-Type，其值也必須爲multipart/form-data，同時還須要規定一個內容分割用於分割請求提中多個post的內容，如文件內容和文本內容是須要分隔開來的，否則接收方就沒法解析和還原這個文件了，具體的頭信息以下：

Content-Type: multipart/form-data; boundary=${bound}  

其中${bound} 是一個佔位符，表明咱們規定的分割符，能夠本身任意規定，但爲了不和正常文本重複了，儘可能要使用複雜一點的內容。如：--------------------56423498738365
4.multipart/form-data的請求體也是一個字符串，不過和post的請求提不一樣的是它的構造方式，post是簡單的name=value鍵值鏈接，而multipart/form-data是添加了分隔符等內容的構造體，具體以下：

--${bound}
Content-Disposition: form-data; name="Filename"

HTTP.pdf
--${bound}
Content-Disposition: form-data; name="file000"; filename="HTTP協議詳解.pdf"
Content-Type: application/octet-stream

%PDF-1.5
file content
%%EOF

--${bound}
Content-Disposition: form-data; name="Upload"

Submit Query
--${bound}--

其中${bound}是以前頭信息中的分隔符，若是頭信息中規定是123，那這裏也要是123；能夠很容易看到，這個請求提是多個相同部分組成的：每一部分都是以--加分隔符開始的，而後是該部份內容的描述信息，而後一個回車，而後是描述信息的具體內容；若是傳送的內容是一個文件的話，那麼還會包含文件名信息以及文件內容類型。上面第二部分是一個文件體的結構，最後以--分隔符--結尾，表示請求體結束。

能夠知道要發送一個multipart/form-data的請求，其實任何支持post請求的工具或語言均可以支持，只是本身要稍微包裝一下即可。