最近在閱讀Okhttp原始碼的時候，遇到了Content-Type:application/x-www-form-urlencoded

其實還有一種常見的編碼格式是application/json

因為自己有一些理解，而且比較懶，所以我不百度了

Content-Type裡的東西就是告訴雙方，資料的格式是怎樣的

資料放在哪呢？可以是在url中，可以是在body裡。

application/x-www-form-urlencoded就是表單格式，

application/json就是json格式，

本質上都是鍵值對，只不過大家的套路不同而已

表單是啥

以前被整的對錶單有點害怕，哇，好牛逼，我不懂欸。。。其實就是一種和json一樣的用於存放鍵值對的資料格式。

聲明瞭Content-Type，就代表告訴了對方，這是怎樣的鍵值對資料格式。對方就按照這種方式去解析了。當然你也可以不宣告，對方可以一種種方式去判斷，判斷到底是啥，這效能損失有點太大了

Accept-Chaset、Accept-Encoding

得先理解整個HTTP協議。

HTTP協議底層到底長啥樣子？其實就是流，編碼格式是utf-8。你把他轉回來，又是一種特殊的資料格式，也是一種類似鍵值對的東西，這就是HTTP特有的資料格式。

然後的東西是我猜測的，body裡的東西仍會進行一次編碼，由accept-charset控制；也就是說你拿到body後要先解碼，目前它是流的形式（解碼注意了，你用什麼字符集轉字元流的，那麼就只能用這種字符集轉回來。然後再進行字元流和位元組流的轉化）。解碼後就得到了比如表單資料格式、json資料格式的資料。

Accept-Encoding則又是在此基礎上的壓縮，常見的有gzip。上面不是已經把應用層的資料，轉化成了鍵值對格式，然後又轉化成位元組流了嗎。現在就是一堆010101的東西了。Accept-Encoding是對位元組流的壓縮，採用比如哈夫曼壓縮演算法，把比如本來100M的位元組流轉化成30M。

所以綜合HTTP的解析，步驟如下：

1.HTTP協議是位元組流，按utf-8解析得到真實文字

2.按照HTTP的鍵值對規範去解析出HTTP的一切到應用層中

3.拿到body

4.解壓縮，超短的位元組流變成原來的超長的位元組流

5.解碼，位元組流按對的編碼格式去解碼，轉成真實文字資料

6.對文字資料按某鍵值對格式進行解析，得到應用層裡的鍵值對

上述是我結合平時看的一些網路框架的原始碼分析出來的，還有待驗證，不過應該八九不離十。