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