http/1.1 協議規定的 http 請求方法有 options、get、head、post、put、delete、trace、connect 這幾種。其中 post 一般用來向服務端提交資料，本文主要討論 post 提交資料的幾種方式。
我們知道，http 協議是以 ascii 碼傳輸，建立在 tcp/ip 協議之上的應用層規範。規範把 http 請求分為三個部分：狀態行、請求頭、訊息主體。類似於下面這樣：
協議規定 post 提交的資料必須放在訊息主體（entity-body）中，但協議並沒有規定資料必須使用什麼編碼方式。實際上，開發者完全可以自己決定訊息主體的格式，只要最後傳送的 http 請求滿足上面的格式就可以。
但是，資料傳送出去，還要服務端解析成功才有意義。一般服務端語言如 php、python 等，以及它們的 framework，都內建了自動解析常見資料格式的功能。服務端通常是根據請求頭（headers）中的 content-type 欄位來獲知請求中的訊息主體是用何種方式編碼，再對主體進行解析。所以說到 post 提交資料方案，包含了 content-type 和訊息主體編碼方式兩部分。下面就正式開始介紹它們。
這又是乙個常見的 post 資料提交的方式。我們使用表單上傳檔案時，必須讓 form 的 enctyped 等於這個值。直接來看乙個請求示例：
這個例子稍微複雜點。首先生成了乙個 boundary 用於分割不同的字段，為了避免與正文內容重複，boundary 很長很複雜。然後 content-type 裡指明了資料是以 mutipart/form-data 來編碼，本次請求的 boundary 是什麼內容。訊息主體裡按照字段個數又分為多個結構類似的部分，每部分都是以 --boundary 開始，緊接著內容描述資訊，然後是回車，最後是字段具體內容（文字或二進位制）。如果傳輸的是檔案，還要包含檔名和檔案型別資訊。訊息主體最後以 --boundary-- 標示結束。關於 mutipart/form-data 的詳細定義，請前往 rfc1867 檢視。
這種方式一般用來上傳檔案，各大服務端語言對它也有著良好的支援。
json 格式支援比鍵值對複雜得多的結構化資料，這一點也很有用。記得我幾年前做乙個專案時，需要提交的資料層次非常深，我就是把資料 json 序列化之後來提交的。不過當時我是把 json 字串作為 val，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交。
google 的 angularjs 中的 ajax 功能，預設就是提交 json 字串。例如下面這段**：
最終傳送的請求是：
我的部落格之前提到過 xml-rpc（xml remote procedure call）。它是一種使用 http 作為傳輸協議，xml 作為編碼方式的遠端呼叫規範。典型的 xml-rpc 請求是這樣的：
content-type: text/xml
<?xml version="1.0"?>
examples.getstatename
41xml-rpc 協議簡單、功能夠用，各種語言的實現都有。它的使用也很廣泛，如 wordpress 的 xml-rpc api，搜尋引擎的 ping 服務等等。j**ascript 中，也有現成的庫支援以這種方式進行資料互動，能很好的支援已有的 xml-rpc 服務。不過，我個人覺得 xml 結構還是過於臃腫，一般場景用 json 會更靈活方便。
四種常見的 POST 提交資料方式
urlencoded 其次，提交的資料按照 key1 val1 key2 val2 的方式進行編碼，key 和 val 都進行了 url 轉碼。大部分服務端語言都對這種方式有很好的支援。例如 php 中，post title 可以獲取到 title 的值，post sub 可以得到 sub 陣列。這...
四種常見的POST提交資料方式
想寫這篇文章的原因不太想說，哎，十萬個後台十萬個想法。post是前端最常見的一種請求資料方式，比get請求方式更安全的同時，也支援更大的資料傳輸。http協議把http請求分為三個部分 狀態行 請求頭 訊息主體 通過post提交的資料需要放在請求頭的訊息主體中，主要支援以下四種格式，伺服器主要通過對...
HTTP四種常見的POST提交資料方式
http 1.1 協議規定的 http 請求方法有 options get head post put delete trace connect 這幾種。其中 post 一般用來向服務端提交資料，本文主要討論 post 提交資料的幾種方式。我們知道，http 協議是以 ascii 碼傳輸，建立在 t...