RPC請求中自己遇到的一些亂碼問題的看法

在j2ee專案中，常見的亂碼一般都是中文亂碼。這裡不講平時你們遇到的那些亂碼問題。

平時遇到的亂碼，注意編碼環境和解密環境統一編碼就好。比如瀏覽器預設的是iso-8859-1編碼等。

這裡講乙個我遇到的亂碼例子，以及分析過程：

問題場景：

我這邊是乙個金融業務系統，對外提供api，對方作為業務的使用方，需要使用我的介面。通過http post的方式請求，我返回的響應報文格式為json。對方使用的http工具為apache的httpclien包。

1、我返回的json串格式，不管是中文還是英文，都是以utf-8的形式返回。

2、對方伺服器的編碼環境也是utf-8。

3、對方接收到的響應報文中，中文亂碼。（問題）

分析過程：

1、起先，我先判斷我返回報文的編碼是不是utf-8。伺服器log日誌中，中文正常顯示。通過locale指令，檢視到伺服器編碼是lang=zh_cn.utf-8。因此返回報文是utf-8格式基本可以確定。

2、我用的是oracle資料庫，檢視到資料庫中文的編碼格式為gbk。開始懷疑是不是資料庫中文編碼和我程式中中文編碼格式不一致。經過分析後，排除了這個想法。因為程式從資料庫中查詢出的中文，預設和程式的編碼格式保持一致。

3、思考是否是http傳輸過程中，導致我utf-8格式返回的響應報文，編碼變了。

因為我返回的報文格式是json格式，且使用的網路傳輸方式為http，於是，我注意到兩個http請求頭中的東西：content-type和accept。

http報文頭中，content-type和accept的區別：

1.accept屬於請求頭， content-type屬於實體頭。

http報頭分為通用報頭，請求報頭，響應報頭和實體報頭。

請求方的http報頭結構：通用報頭|請求報頭|實體報頭

響應方的http報頭結構：通用報頭|響應報頭|實體報頭

2.accept代表傳送端（客戶端）希望接受的資料型別。

比如：accept：text/xml;

代表客戶端希望接受的資料型別是xml型別

content-type代表傳送端（客戶端|伺服器）傳送的實體資料的資料型別。

比如：content-type：text/html;

代表傳送端傳送的資料格式是html。

二者合起來，

accept:text/xml；

content-type:text/html

即代表希望接受的資料型別是xml格式，本次請求傳送的資料的資料格式是html。