MIME (Multipurpose Internet Mail Extensions) 是描述內容類型的互聯網標準。Clients use this content type or media type header to select an appropriate viewer applicat ...
MIME (Multipurpose Internet Mail Extensions) 是描述內容類型的互聯網標準。Clients use this content type or media type header to select an appropriate viewer application for the type of data the header indicates. 數據接收方根據MIME type of content進行不同的解析。
MIME 消息包含文本（text/…）、圖像(image/…)、音頻(audio/…)、視頻(video/…)以及其他應用程式專用(application/…)的數據。type/subtype
<form> 標簽的 enctype 屬性指定發往伺服器的數據的MIME類型。只有 method="post" 時才使用 enctype 屬性。
|
取值 |
描述 |
|
application/x-www-form-urlencoded |
在發送前會根據HTTP標準編碼所有字元（k=v&k2=v2），空格轉換為 "+" ，特殊符號轉換為 ASCII HEX 值。【在url規範中空格要編碼成%20】 |
|
multipart/form-data |
不對字元編碼，會增加MIME headers。use when forms contain files, non-ASCII data, and binary data. |
|
text/plain |
空格轉換為 "+" 加號，不對特殊字元編碼。 |
fname欄位的value='chen 1'和name欄位的value='kevin 1'在不同MIME類型下的表現形式：
application/x-www-form-urlencoded
For application/x-www-form-urlencoded, the body of the HTTP message sent to the server is essentially one giant query string -- name/value pairs are separated by the ampersand (&), and names are separated from values by the equals symbol (=). An example of this would be:
MyVariableOne=ValueOne&MyVariableTwo=ValueTwo
According to the specification:
[Reserved and] non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character
That means that for each non-alphanumeric byte that exists in one of our values, it's going to take three bytes to represent it. For large binary files, tripling the payload is going to be highly inefficient.
multipart/form-data
會將多個表單的數據處理為一條消息，數據塊以分隔符=={boundary}開始，以 =={boundary}==結束。會有Content-Type屬性說明文件類型，content-disposition屬性說明欄位的一些具體信息。
That's where multipart/form-data comes in. With this method of transmitting name/value pairs, each pair is represented as a "part" in a MIME message (). Parts are separated by a particular string boundary (chosen specifically so that this boundary string does not occur in any of the "value" payloads). Each part has its own set of MIME headers like Content-Type, and particularly Content-Disposition, which can give each part its "name." The value piece of each name/value pair is the payload of each part of the MIME message. The MIME spec gives us more options when representing the value payload -- we can choose a more efficient encoding of binary data to save bandwidth (e.g. base 64 or even raw binary).
Why not use multipart/form-data all the time? For short alphanumeric values (like most web forms), the overhead of adding all of the MIME headers is going to significantly outweigh any savings from more efficient binary encoding.
payload：數據在傳輸過程中會根據各種協議進行封裝，以保證可靠性。去除這些包裹層後真正需要傳輸的數據即payload。
不同的參數傳遞方式，服務端獲取參數的方式也不同。
對於提交的application/x-www-form-urlencoded數據(ajax或表單)， 在servlet中可以通過request.getParameter(name)的形式來獲取表單參數。
對於multipart/form-data類型的數據，後臺一般需要通過獲取原始數據流做特別處理。
使用原生Ajax Post請求且未指定content-type時，預設使用Content-Type:text/plain;charset=UTF-8頭部，在chrome中請求參數會顯示在Request Payload部分。後臺接受數據後只能當作普通字元使用，不能使用常用API獲取參數。
jQuery.ajax()中預設的content-type為application/x-www-form-urlencoded類型，瀏覽器會將數據編碼成標準的query String，在chrome的Form Data部分可以看到對應的值。適合傳鍵值對數據（’key=value’或{key:value}），不適合對象嵌套對象的數據。
application/json
以json格式的字元串形式傳遞參數，在jQuery中需要用JSON.Stringfy()將對象字元串化。如果直接傳對象，最外層的括弧會被去掉，導致解析錯誤。大多數後端語言都支持解析json格式的數據。
query string parameters 請求url中的query部分，get和post請求都可以攜帶。
