這幾天對接介面出現乙個問題，嬿這個中文亂碼。
小編本身因為這件事浪費了不少時間，所以自然是帶有一點情緒，但描述中並沒有誇大，也希望各位不管是對接或者是被對接的人能夠互相體諒，不要總是踢皮球
事情是這樣的。
介面呼叫出現了問題，因為中文「嬿」會亂碼。
介面方一句話：那要看你們往介面傳的是什麼
小編本著心虛的態度趕緊看一下自己的**（其實心中早已無語，因所有的中文都是按照文件指定的方式傳的，且我們系統中文字根本沒有出現亂碼的現象）
結果一看，對方介面文件裡面的gb2312編碼的碼表裡面根本沒這個字。
好吧，截圖給對方看。
此時同事剛好提到gbk可以相容gb2312的事，小編腦袋一抽，想說那就試試看吧！
結果還真行，此時才發現，真的是套路滿滿。此時對介面方已是鄙夷滿滿。
介面方：那你就用gbk吧
小編好意給的文件裡面要改一下的建議完全被無視
這還沒完，因為這只是傳資料的時候編碼錯誤，還有返回資料時候的資料也不對！！
大家請注意，jdk中的httpclient的核心工具包中對於返回資料內容的解碼，並不能強制指定編碼，而是優先以返回的字符集編碼進行解碼，沒有的時候才是以我們指定的編碼進行解碼
所以其實介面方根本不需要在文件中告知返回的資料用什麼編碼，因為這都是在協議頭中返回的，就是那個charset=utf-8
而如果介面方硬是傳回乙個錯誤的編碼，將會導致我們解碼失敗，一堆亂碼。
大哥、大叔、大爺！我知道瀏覽器即使選擇了gb2312編碼，仍然可以自動相容到gbk，但是那是客戶端，我們是服務端，我們只認協議
最終無奈妥協，在自己**中做了，如果返回gb2312編碼的時候，改用gbk，因為gbk相容gb2312的
為何http請求返回亂碼
用fiddler或者http analyz等抓包分析工具 抓取我們的http請求時 看到的返回資料都是亂碼 究其原因是因為在http請求的時候新增了accept encoding gzip,deflate這乙個設定 如果這樣設定之後 伺服器給我們返回的資料就是經過gzip加密後的資料 然後我們客戶端...
關於Http請求後返回json亂碼的問題
其實很多時候我們在做http請求資料返回的時候經常會莫名發現會出現亂碼，大部分時候我們都覺得是編碼不對造成的。一般情況下正常我們預設都是作個很簡單的操作，直接使用utf 8編碼基本問題就搞定了 基本問題就ok了，但有時候卻並不一定，比如如果事實上編碼並不是這樣呢？我們就需要去判斷當前正確編碼方式，來...
關於Http請求後返回json亂碼的問題
其實很多時候我們在做http請求資料返回的時候經常會莫名發現會出現亂碼，大部分時候我們都覺得是編碼不對造成的。一般情況下正常我們預設都是作個很簡單的操作，直接使用utf 8編碼基本問題就搞定了 基本問題就ok了，但有時候卻並不一定，比如如果事實上編碼並不是這樣呢？我們就需要去判斷當前正確編碼方式，來...