http介面返回亂碼
這幾天對接接口出現一個問題，嬿這個中文亂碼。
小編本身因為這件事浪費了不少時間，所以自然是帶有一點情緒，但描述中並沒有誇大，也希望各位不管是對接或者是被對接的人能夠互相體諒，不要總是踢皮球
事情是這樣的。
介面調用出現了問題，因為中文“嬿”會亂碼。
介面方一句話：那要看你們往介面傳的是什麼
小編本著心虛的態度趕緊看一下自己的程式碼（其實心中早已無語，因所有的中文都是按照文件指定的方式傳的，且我們系統中文字根本沒有出現亂碼的現象）
結果一看，對方介面文件裡面的gb2312編碼的碼錶裡面根本沒這個字。
好吧，截圖給對方看。
介面方：給你個網站，你先看上面能不能解碼。
小編再次被套路，點進去網站，哎，還真可以解碼。神奇了，難道是我學藝不精？？?，而且這個網站上面還真的寫著gb2312編解碼（後來事實證明，這個網站實際用的是gbk解碼！！！！）
此時同事剛好提到gbk可以相容gb2312的事，小編腦袋一抽，想說那就試試看吧！
結果還真行，此時才發現，真的是套路滿滿。此時對介面方已是鄙夷滿滿。
介面方：那你就用gbk吧
小編好意給的文件裡面要改一下的建議完全被無視
這還沒完，因為這只是傳資料的時候編碼錯誤，還有返回資料時候的資料也不對！！
大家請注意，jdk中的httpclient的核心工具包中對於返回資料內容的解碼，並不能強制指定編碼，而是優先以返回的字符集編碼進行解碼，沒有的時候才是以我們指定的編碼進行解碼
所以其實介面方根本不需要在文件中告知返回的資料用什麼編碼，因為這都是在協議頭中返回的，就是那個charset=utf-8
而如果介面方硬是傳回一個錯誤的編碼，將會導致我們解碼失敗，一堆亂碼。
這裡小編再次受到介面方的暴擊：客戶端都可以設定編碼的啊！
大哥、大叔、大爺！我知道瀏覽器即使選擇了gb2312編碼，仍然可以自動相容到gbk，但是那是客戶端，我們是服務端，我們只認協議
最終無奈妥協，在自己程式碼中做了，如果返回gb2312編碼的時候，改用gbk，因為gbk相容gb2312的
