研究HTTP請求頭部的 Content-Type 欄位，基於 Chrome 外掛 DHC

1. GET 請求

GET 請求不存在請求實體部分，鍵值對引數放置在 URL 尾部，因此請求頭不需要設定 Content-Type 欄位

非 ASCII 碼會自動進行編碼轉換，例如傳送請求：www.bilibili.com?hehe=你的我的

GET /?hehe=%E4%BD%A0%E7%9A%84%E6%88%91%E7%9A%84 HTTP/1.1
Host: www.bilibili.com

值得一提的是，GET 引數的編碼方式是無法人為干涉的，這導致了不同瀏覽器有不同的編碼方式，因此最穩妥的方案是人工預編碼，人工解碼，從而禁止瀏覽器編碼的干涉

2. POST 請求

第一類：raw 原始型別，可以上傳任意格式的文字，比如 text、json、xml、html（中文不進行編碼）

①text 請求

POST / HTTP/1.1
Host: www.bilibili.com
Content-Type: text/plain
Content-Length: 44

ALARM=hellowww&&adzdzd12323...22你的我的

②json 請求

POST / HTTP/1.1
Host: www.bilibili.com
Content-Type: application/json
Content-Length
 
: 44

ALARM=hellowww&&adzdzd12323...22你的我的

③html 請求

POST / HTTP/1.1
Host: www.bilibili.com
Content-Type: text/html
Content-Length: 44

ALARM=hellowww&&adzdzd12323...22你的我的

第二類：application/x-www-form-urlencoded，會將表單內的資料轉換拼接成 key-value 對（非 ASCII 碼進行編碼）

傳送 POST 請求，引數為：aaa=aaa，bbb=你的我的

POST / HTTP/1.1
Host: www.bilibili.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

aaa=aaa&bbb=%E4%BD%A0%E7%9A%84%E6%88%91%E7%9A%84

從這裡可以看出，application/x-www-form-urlencoded 對非 ASCII 的編碼方式與 GET 請求引數的編碼方式和格式都是一樣的

值得一提的是，POST 請求的編碼格式是可以人工干預的：在 form 表單所在的 html 檔案裡如果有段 ，那麼 post 就會用此處指定的編碼方式編碼，JSP 也有類似的宣告方式；開發人員可以用此來指定 POST 請求的編碼格式

第三類：multipart/form-data，將表單的資料處理為一條訊息，以標籤為單元，用分隔符分開。既可以上傳鍵值對，也可以上傳檔案

傳送 POST 請求，引數為：aaa=aaa，bbb=你的我的啊啊啊，file=圖片

POST / HTTP/1.1
Host: www.bilibili.com
Content-Type: multipart/form-data;boundary=------FormBoundary15e896376d1
Content-Length: 19532

------FormBoundary15e896376d1
Content-Disposition: form-data; name="aaa"

aaa
------FormBoundary15e896376d1
Content-Disposition: form-data; name="bbb"

你的我的啊啊啊
------FormBoundary15e896376d1
Content-Disposition: form-data; name="file"; filename="cat-icon.png"
Content-Type: image/png

[message-part-body; type:image/png, size:19201 bytes]
------FormBoundary15e896376d1--

可以看到，中文並沒有被編碼