主體內(nèi)容翻譯自https://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart-form-data 上的最高贊的回答

首先，http請求的內(nèi)容如下：

request line
headers
request body

其中，request line部分的url必須以application/x-www-form-urlencoded方式編碼

request body的編碼方式由頭部的Content-Type指定。

以下，開始翻譯stackOverFlow的application/x-www-form-urlencoded or multipart/form-data?問題下的第一個回答。

翻譯

總結(jié)：如果你有二進制的數(shù)據(jù)（即非字母或者數(shù)字，或者非常大的一段數(shù)據(jù)）要傳輸，那么使用multipart/form-data。否則，使用application/x-www-form-urlencoded。

分析：multipart/form-data和application/x-www-form-urlencoded是http post請求中，user-agent（瀏覽器或者客戶端）必須支持的兩種MIME type，這兩種多媒體類型的請求的目的是去發(fā)送name/value對的一串列表到服務(wù)端。在傳輸?shù)臄?shù)據(jù)的類型和大小不同的情況下，以上兩種方法，一種會比另一種更有效率。要理解為什么，你必須看一下這兩種編碼類型的內(nèi)部實現(xiàn)。

multipart/x-www-form-urlencoded：被發(fā)送到服務(wù)端的http消息的body在本質(zhì)上是一個巨大的查詢字符串：name/value對被&符號分開，name和value被=符號分開，例如：

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

根據(jù)specification

非字母和數(shù)字的字符會被%HH來代替，一個百分比符號和兩個16位進制的數(shù)字代表著那個字符的ASCII碼

這意味著每一個在value中的非字母和數(shù)字的字節(jié)，都將被3個字節(jié)的數(shù)據(jù)代替。如果是一個大的二進制的文件，那么3倍的傳輸數(shù)據(jù)將會變得十分低效率。

這時multipart/form-data就該出現(xiàn)了。用這種方法來傳輸name/value對，每一個鍵值對都代表著MIM消息中的一個part。不同給的part被一個獨特的字符串界線分割（該字符串分界線需要獨特地生成，以便不會在任何value中出現(xiàn)）。每一個part有他自己的一系列MIME 頭部，例如Content-Type，并且特別低，需要有Content-Disposition，來給每一個part他自己的“名字”。每一個name/value對的value是每一個MIME消息中的part的有效負載。MIME spec給了我們更多的選項，比如，我們可以選擇一個更加高效率的數(shù)據(jù)編碼方式來節(jié)約流量（eg.base64 或甚至 原生二進制）。

那么為什么不一直用multipart/form-data呢？因為：對于一些短的字母或數(shù)字的value（大多數(shù)web表單都是），添加所有MIME頭的開銷將大大超過從更有效的二進制編碼中節(jié)省的任何開銷。