編碼問題(.java/.jsp/.js等文件的中文亂碼)

亂碼的出現是由於編碼與解碼的不一致形成的，假如你對「中文」兩個字進行了gbk格式的保存，卻用utf-8格式的解讀，是確定會出現亂碼的。

如何避免中文亂碼：應用上下統一用一種編碼格式。 utf-8或者gbk  建議用utf-8. 雖然佔空間，可是通用性強，它屬於國際編碼格式。相反，gbk是國家級的。

下面簡單說下以tomcat爲容器的程序響應response的編碼流程：

.java--.class

.jsp--.java--.class~~.html

.js--.js

.css--.css

編碼涉及到的就這幾種流程，而在程序響應中出現中文亂碼也就中間的兩種狀況：

.jsp--.java--.class~~.html：

第一步 jsp的保存編碼能夠經過<%@ page language="java" pageEncoding="utf-8"  來設置，pageEncoding="utf-8"的意思是該jsp頁面將以utf-8的形式保存，在tomcat讀取時也一樣以utf-8的形式讀取；

第二步 而後經過某種（假設A）編碼保存爲.java(能夠是任何編碼，即便是ISO-8859，雖然可能出現中文亂碼，但不礙事，由於用戶看不到。該編碼格式可能先參考tomcat的默認編碼，若是沒有設置可能參考操做系統的默認編碼)，而後tomcat會繼續用A編碼讀取；

第三步 接着走.class編譯流程，相似.java。

最終，會生成html。而html的格式相當重要，它的格式是根據誰來的呢？  有個優先順序，第一  看response.setCharacterEncoding("UTF-8")是否進行設置 ，沒有沒則看看jsp中是否設置了<%@ contentType="text/html; charset=utf-8"，若是沒有則依照

 pageEncoding="utf-8"的格式進行保存。 （不一樣瀏覽器不同） 而瀏覽器很是聰明，它根據響應頭信息獲得該html的保存編碼，而後就用保存編碼的編碼格式去解碼顯示。 如圖：

而我遇到的亂碼狀況是這樣的：jsp的保存編碼爲pageEncoding="utf-8",而js的保存編碼爲gbk(經過eclipse能夠看到)；當該html在瀏覽器中以utf-8的格式顯示時，它的js也會以utf-8的解碼格式去顯示，這樣 gbk-utf-8就出現亂碼了。

解決方法一： 單獨爲該js設置 <script type="text/javascript" src="<%=basePath%>nccm/js/Dialog.js" charset="utf-8" ></script>編碼格式

解決方法二： 修改js的保存編碼格式，能夠把js複製到文本中，另存爲utf-8。而後修改eclipse對js的默認編碼爲utf-8.window-general-content types -text-javascript,修改成utf-8，update---ok。最後再把文本中的utf-8格式的js複製到eclipse中。

到此，只是簡單的描述了一下響應response的編碼轉換流程。 真正容易出現亂碼的地方是 request請求。

request的中文請求亂碼分三種狀況：1.url參數請求 2.表單 post 參數請求   3.表單 get參數請求

不管哪一種狀況，在從客戶端(瀏覽器)發送的時候，都採用瀏覽器的編碼方式先編碼，而後在服務端再用某一種編碼來解碼; 之因此出現亂碼，是由於在客戶端跟服務端所用的編碼和解碼格式不一致形成的。那麼何爲瀏覽器編碼？ 能夠經過（ie）頁面-編碼進行查看（注意若是你所瀏覽的頁面是由frame構成的，那麼你所看到編碼爲最外層頁面的編碼，並不必定是當前響應頁面的編碼《若是外層頁面編碼和當前響應頁面的編碼不一致》）。而當前瀏覽器編碼，也就是當前響應頁面的編碼；若是你在A頁面上再次發送請求，那麼此次請求所用的編碼即瀏覽器編碼爲上次響應A頁面所用的編碼，也就是瀏覽器展現A頁面所用的編碼(參考上面響應部分)。

那麼，咱們肯定了瀏覽器端的編碼，服務端解碼是依據誰來決定解碼格式呢？  首先，表單post方式則經過request.setCharacterEncoding("UTF-8")來決定。ssh2，框架中通常配置有spring、strust2的中文過濾器。org.springframework.web.filter.CharacterEncodingFilter、 org.apache.struts2.dispatcher.FilterDispatcher。 通常狀況，都是struts2的過濾器在最後，由於執行完struts2可能就不執行其餘過濾器了而直接找對應的action。 CharacterEncodingFilter的格式直接在web.xml中配置，而FilterDispatcher則會取得struts2的默認編碼struts.i18n.encoding=UTF-8(在strust2-core.jar下面的default.properties中)，若是你沒有在struts.xml中設置struts.i18n.encoding的話。 這兩個過濾器的做用都是設置request.setCharacterEncoding（）；

其次，就是url和表單get方式了，他們針對不一樣的容器，作出的判斷也是不同的。下面以tomcat爲例：

對於URL提交的數據和表單中GET方式提交的數據，在接收數據的JSP中設置request.setCharacterEncoding參數是不行的，由於在Tomcat5.0中，默認狀況下使用ISO- 8859-1對URL提交的數據和表單中GET方式提交的數據進行從新編碼（解碼），而不使用該參數對URL提交的數據和表單中GET方式提交的數據進行從新編碼（解碼）。要解決該問題，應該在Tomcat的配置文件的Connector標籤中設置useBodyEncodingForURI或者 URIEncoding屬性，其中useBodyEncodingForURI參數表示是否用request.setCharacterEncoding 參數對URL提交的數據和表單中GET方式提交的數據進行從新編碼，在默認狀況下，該參數爲false（Tomcat4.0中該參數默認爲 true）；URIEncoding參數指定對全部GET方式請求（包括URL提交的數據和表單中GET方式提交的數據）進行統一的從新編碼（解碼）的編碼（不建議使用，可能影響到其餘項目）。URIEncoding和useBodyEncodingForURI區別是，URIEncoding是對全部GET方式的請求的數據進行統一的從新編碼（解碼）（tomcat下的全部項目），而useBodyEncodingForURI則是根據響應該請求的頁面的request.setCharacterEncoding參數對數據進行的從新編碼（解碼），不一樣的頁面能夠有不一樣的從新編碼（解碼）的編碼。因此對於URL提交的數據和表單中GET方式提交的數據，能夠修改 URIEncoding參數爲瀏覽器編碼或者修改useBodyEncodingForURI爲true，而且在得到數據的JSP頁面中 request.setCharacterEncoding參數設置成瀏覽器編碼。

而weblogic服務器，網上給出說法須要在weblogic.xml中設置：

此方法可同時用於 GET 和 POST 操做。

input-charset

使用 <input-charset> 元素定義用於讀取 GET 和 POST 數據的字符集。例如：

<input-charset>
    <resource-path>/foo</resource-path>
    <java-charset-name>SJIS</java-charset-name>
</input-charset>

有關詳細信息，請參閱肯定 HTTP 請求的編碼。

下表描述可在 <input-charset> 元素中定義的元素。

元素	必需/ 可選	描述
<resource-path>	必需	若是某請求的 URL 中包含此路徑，則將指示 WebLogic Server 使用 <java-charset-name> 指定的 Java 字符集。
<java-charset-name>	必需	指定要使用的 Java 字符集。

上述方法未測試。   

<meta http-equiv="content-type" content="text/html; charset=UTF-8" />  的做用有待測試