http接口返回亂碼

這幾天對接接口出現一個問題，嬿這個中文亂碼。

 

小編自己由於這件事浪費了很多時間，因此天然是帶有一點情緒，但描述中並無誇大，也但願各位無論是對接或者是被對接的人可以互相體諒，不要老是踢皮球

 

事情是這樣的。

 

接口調用出現了問題，由於中文「嬿」會亂碼。

 

接口方一句話：那要看大家往接口傳的是什麼

 

小編本着心虛的態度趕忙看一下本身的代碼（其實心中早已無語，因全部的中文都是按照文檔指定的方式傳的，且咱們系統中文字根本沒有出現亂碼的現象）

結果一看，對方接口文檔裏面的gb2312編碼的碼錶裏面根本沒這個字。

好吧，截圖給對方看。

 

接口方：給你個網站，你先看上面能不能解碼。

 

小編再次被套路，點進去網站，哎，還真能夠解碼。神奇了，難道是我學藝不精？？?，並且這個網站上面還真的寫着gb2312編解碼（後來事實證實，這個網站實際用的是gbk解碼！！！！）

此時同事恰好提到gbk能夠兼容gb2312的事，小編腦殼一抽，想說那就試試看吧！

結果還真行，此時才發現，真的是套路滿滿。此時對接口方已經是鄙夷滿滿。

 

接口方：那你就用gbk吧

 

小編好意給的文檔裏面要改一下的建議徹底被無視

這還沒完，由於這只是傳數據的時候編碼錯誤，還有返回數據時候的數據也不對！！

 

你們請注意，jdk中的httpclient的核心工具包中對於返回數據內容的解碼，並不能強制指定編碼，而是優先以返回的字符集編碼進行解碼，沒有的時候纔是以咱們指定的編碼進行解碼

因此其實接口方根本不須要在文檔中告知返回的數據用什麼編碼，由於這都是在協議頭中返回的，就是那個charset=utf-8

而若是接口方硬是傳回一個錯誤的編碼，將會致使咱們解碼失敗，一堆亂碼。

 

這裏小編再次受到接口方的暴擊：客戶端均可以設置編碼的啊！

 

大哥、大叔、大爺！我知道瀏覽器即便選擇了gb2312編碼，仍然能夠自動兼容到gbk，可是那是客戶端，咱們是服務端，咱們只認協議

最終無奈妥協，在本身代碼中作了，若是返回gb2312編碼的時候，改用gbk，由於gbk兼容gb2312的