這段時間，在給一個地區門戶網站(alexa全球排行1200左右)做SSO集成，其中的一個部分就是Web Services服務接口，以及客戶端，我們采用的是REST方式，不是SOAP，大致就是客戶端通過HTTP POST方式向服務器提交數據，如賬號同步，服務器返回xml，給客戶端反饋。但提交過程中中文問題出來了，因為賬號中有個realName字段是中文。客戶端有以下幾種：

1、Java HTTP客戶端(HttpURLConnection)

2、PHP客戶端(curl庫)

3、ajax 客戶端(XMLHTTP)

4、普通表單提交(POST方式)

…..

開發上面四種客戶端API和 demo都很快，現在就記錄一下中文解決方案問題吧。

我之所以要發表出來，是因為我這兒的解決方式是自動化的，編碼量最小，并且我進行了無數次嘗試，確定怎樣行，怎樣不行，并找出原因。

注意：我只是說明了request的中文解決方案，并且只是POST方式，但只要是對這個很理解，response的中文也就很簡單了。

開始時候，我也是采用了比較機械的，在服務器端servlet中將得到的參數值：

Java代碼

byte[]?b?=?value.getBytes("ISO-8859-1");

output?=?new?String(b,"UTF-8");

這樣可以解決問題，而且都成功了，但必須在四種客戶端發送的中文時候要進行encoding操作。最后我覺得這肯定不是最優解，因為工作量太大，于是決定重構。

將發往服務器的request都用filter攔截，主要就是下面這句話，其實這個方式非常old了，不值得一提。在doFilter里：

Java代碼

request.setCharacterEncoding(encoding);

也就是將到來的所有請求(還沒有說到response呢)都用指定的編碼(UTF-8)進行編碼。

用filter，可以解決服務器移植的問題，如我最熟悉的Tomcat，resin，WL，WS。

我用axis (著名的Web Services SOAP引擎)附帶的TCPMonitor來探測發出的POST請求。

Java HTTP客戶端(HttpURLConnection)：

必須將請求數據的key/value的value，進行編碼：

Java代碼

URLEncoder.encode(value,"UTF-8")

;

PHP客戶端(curl庫)：

同上，必須進行轉碼：

Java代碼

$truename?=?iconv("GBK",?"UTF-8","陳志武");

因為我們PHP默認環境是中文

ajax客戶端：

發送POST請求時，直接用中文，不需要用Javascript的encodeURI()，或者escape()，但是用了也不影響。

why？因為ajax POST方式默認是以UTF-8方式發送的。對已經編碼的中文，也就是一些%E9%99%88%E5%BF%97%E6%AD%A6這樣的正常符號了，服務器就忽略編碼了，因為編和不編一個樣。

注意，這兩個函數對中文encode后結果不一樣。用encodeURI()是以UTF-8編碼，但沒有其它編碼類型可選擇，這樣，如果你的服務器端的filter用GBK默認，那么，就不能象這樣自動處理。

所以，用ajax客戶端時，必須慎重點。

普通表單提交(POST方式)

如果希望自動解決問題，在filter里對request請求編碼設置為UTF-8的前提下，最好就是加入如下：

Java代碼

"Content-Type"?content="text/html;?charset=UTF-8"?/>

如果charset為GBK，那么到Server端就是亂碼的。

why？因為，用submit方式提交時，我們的提交的表單編碼類型(enctype)是：

Content-Type: application/x-www-form-urlencoded，也就是說，提交的時候，我們的中文會自動進行編碼，但依據就是上面的那個html指令。這個證據可以從TCPMonitor攔截的HTTP數據包里看到。

和上面的方式比較，ajax方式感覺是瀏覽器為我們建立了一個http通道，直接將中文提交上去了，和最前面介紹的兩種一樣。

在服務器端，我們的Java Web容器或應用服務器會自動給我們的request參數解碼。將編碼后的字符還原為本來面目。

如果你在控制臺里面看到的都是正確的中文，你就可以拋開數據庫這個存在編碼問題了，但那個有時也有點麻煩

總結

以上是生活随笔為你收集整理的idhttp返回乱码_HTTP客户端POST方式中文编码（乱码）解决方案(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。