????? 最近又碰到了中文亂碼問題，這里我沒有把數據庫牽扯進來，先說下我的環境，servlet容器使用Tomcat6.0，瀏覽器FireFox3.0、IE6，涉及字符編碼設置的地方我的思路就是編碼的地方都統一使用UTF-8，具體配置如下：

1.所有頁面的charset設置為UTF-8。

2.Tomcat的URIEncoding默認是ISO-8859-1，而我設置為UTF-8，主要是想解決中文命名的文件以及請求以get方式提交有可能出現的亂碼問題。

3.添加過濾器，調用request.setCharacterEncoding("utf-8")方法將request的字符集設定為utf-8，解決請求以post方式提交的亂碼問題。

其實這樣的設置貌似是不會再出現亂碼問題了，不過，問題依舊來了 ，如果我在瀏覽器的地址欄中輸入中文參數提交，返回的頁面卻出現了亂碼。真搞不明白到底是哪里出了問題！說起來對中文亂碼的問題一直是一支半解，出現亂碼了，網上搜羅了一大堆資料，按照網上的配置，問題到是解決了，不過原理卻搞的很模糊，一個請求發送到服務器，服務器業務邏輯處理后返回一個頁面，這中間涉及的字符集轉換，編碼，解碼過程一概不清楚。這次，折騰了半天，總算是更進一步了解了字符編碼問題，這里做個總結。

先看我的總結,有不對的地方歡迎批評。

首先我們看下，一個請求響應的流程

?

瀏覽器 IE/FireFox ----------->Servlet容器------------------------>顯示頁面

?????? 編碼?????????????????????????? 使用容器的URIEncoding轉碼 ???????????? 解碼

我把用戶發送請求方式不同引起的中文問題劃分了四種類型：

1、表單的get提交

2、表單的post提交

3、頁面鏈接傳遞中文參數

4、地址欄中參數直接輸入中文提交

?

1.首先我們看表單get方式提交

????? 瀏覽器根據頁面的charset編碼方式對頁面進行編碼，然后提交至服務器，首先進入對應的字符編碼過濾器(如果有的話)，不過Tomcat6.0對于get提交方式采用的是server.xml文件中的URIEncoding編碼方式，而并不會采用過濾器中設置的編碼，那么根據我的環境設置，jsp頁面都使用UTF-8的編碼，Servlet容器的URIEncoding也設置為UTF-8，則servlet不用進行轉碼即可正確解碼，獲得正常的中文字符串。那么，響應頁面的中文因為頁面的統一編碼(UTF-8)自然也會正常顯示。當然，如果我們Tomcat的URIEncoding設置為其他非UTF-8的編碼方式時，頁面的內容進入Tomcat解析時，因為Tomcat和頁面的編碼不統一，就需要轉碼。例如，如果我們采用Tomcat默認的ISO-8859-1，那么當我們使用request.getParameter("your Variable ")獲取表單參數值時其實Servlet就進行了轉碼，它會以容器編碼方式進行解碼，這個過程如下：

UTF-8(編碼)-->ISO-58859-1(解碼)

這個過程也相當于我們使用如下的語句

    new String(變量值.getBytes("UTF-8"),"ISO-8859-1");
  

根據API的解釋，先將變量值以UTF-8字符集編碼轉換為字節序列，再以ISO-8859-1字符集解碼字節數組，構造出新的字符串對象。

等價于以下方式：

    String code = "編碼";
code = URLEncoder.encode(code,"UTF-8");
code = URLDecoder.decode(code,"ISO-8858-1");

  

?

例如表單的username屬性以字符串"編輯"提交，那么進入容器后，FormBean中的這個變量會亂碼，request.getParameter(username)一樣的效果，s1就是request返回的結果，下面是內存快照。

不過即使這樣，我們依然可以使用不恰當的方法顯示正常的中文，即逆向轉碼，例如上面的亂碼，我們可以通過ISO8859-1-->UTF-8這種方式還原我們提交時的中文。以下是GBK，UTF-8，ISO-8859-1三者之間互相轉換的內存快照：

?我們可以看到，偶數漢字可以在UTF-8，GBK兩者中互相轉換，而奇數個漢字則不能。綜上看來，貌似Tomcat的URIEncoding設置為UTF-8是最好的解決辦法，不過這樣的設置依然無法解決上面我所說的第三、第四種情況。大家繼續向下看。(這里有一點我不確定，就是頁面提交至Servlet容器時，是以頁面的charset方式編碼后直接進入容器，還是以charset轉碼為ISO-8859-1方式進入，大家有什么見解？)
2.表單的post提交

對于這種方式的請求，request.setCharacterEncoding("一般來自于web.xml中過濾器設置的參數")方法進行編碼設置將會產生作用，struts的表單提交方式默認為post方式，那么按照上面我的環境設置，頁面，容器，都采用UTF-8編碼方式，就不會產生中文亂碼問題。
3.頁面鏈接中傳遞中文參數

我虛擬一個這樣的場景，請求頁面中有如下代碼

    <%
String username = "編輯";
%>
<a href="hello.do?username=<%=username%>">頁面中鏈接傳遞中文</a>
  

對于這種方式，我們需要先將參數使用統一的編碼方式編碼，將編碼后的字符放入鏈接，這里我對參數以UTF-8方式編碼，如下

    <%
String username = java.net.URLEncoder.encode("編輯","UTF-8");
%>
  

那么這樣我們也不會產生中文亂碼問題

4.地址欄中參數直接輸入中文提交

例如瀏覽器地址欄中輸入"http://localhost:8080/helloapp.do?username=編輯"提交，對于這種方式，瀏覽器不會采用頁面的charset方式對URL中的中文進行編碼后提交至服務器(IE,FireFox都一樣)，而是采用系統的GBK轉碼為ISO-8859-1之后提交至Servlet容器，那么，如果對于前三種方式我們所做的設置，在這里就有問題了，因為進入容器時中文進行了GBK至ISO-8859-1的轉碼，而之前我們的Servlet容器URIEncoding設置為UTF-8，當我們使用request.getParameter("username")時，相當于又進行了這樣的流程GBK-->ISO-8859-1-->UTF-8，按照以上我們使用的測試中文，“編輯”，使用request.getParameter("username")則會得到這樣的結果??，下圖是進行轉碼的內存快照：

我們可以看到

“編輯”經過從GBK-->ISO-8859-1-->UTF-8的過程后得到的就是??這樣的結果，這里我們還會想到那進行2次逆向轉碼看看，不過可惜的是，結果為“錕潔輯”。對于這種情況，我們的解決辦法就是，Tomcat的URIEncoding采用默認的ISO-8859-1字符集，那么我們可以在程序中通過ISO-8859-1-->GBK這樣不恰當的逆向轉碼方式得到正常的中文“編輯”，但這樣的結果是，我們get請求方式的中文處理解決辦法就需要改變。如，在我的環境下就需要進行ISO-8859-1-->UTF-8的轉碼，挺不爽。

?

綜上，對于亂碼問題，前三種方式是一般用戶的請求方式，第四種屬于非正常途徑的請求方式，對于這種方式產生的問題我認為無法很好的解決，也不需要解決。我看到javaeye對于這樣的情況就沒有處理，不知道大家在自己的項目中是如何處理的？我的實驗是，IE6的設置會影響應用路徑的編碼方式，例如地址欄中請求一個中文JSP頁面，如：http://localhost:8080/helloapp/編輯.jsp，IE默認是勾選"以UTF-8發送URL"項的，那么按照我上面總結的處理方式，這個請求可以正常顯示頁面，如圖：

如果取消IE的這個選項，那么瀏覽器會以GBK編碼應用路徑的中文，得到的結果如圖：

按照我上面的設置，這里如果將Tomcat的URIEncoding設置為GBK，則也可以正常顯示頁面。對于FireFox3.0，則是以UTF-8編碼。

最后，回到我的題目，向大家討教下，IE6的“以UTF-8發送URL”選項設置對請求頁面字符編碼有影響嗎？歡迎討論！

?

我的測試代碼共享給大家:),使用的是struts1.2，struts的jar包，大家可以去apache下載。

?

這里推薦個鏈接，有興趣的可以深入了解更多字符集、編碼的問題。

http://hideto.iteye.com/blog/97803

解決字符集亂碼問題完全攻略