精品伊人久久大香线蕉,开心久久婷婷综合中文字幕,杏田冲梨,人妻无码aⅴ不卡中文字幕

二、JSP文件中硬編碼中文字符，在瀏覽器上顯示亂碼。

我們用eclipse編寫一個JSP頁面，使用tomcat瀏覽這個頁面時，整個頁面的中文字符都是亂碼。這是什么原因呢？

JSP頁面從編寫到在瀏覽器上瀏覽，總共有四次字符編解碼。

       1. 以某種字符編碼保存JSP文件

       2. Tomcat以指定編碼（需要與1中編碼一樣）來讀取JSP文件并編譯

3. Tomcat向瀏覽器以指定編碼來發送HTML內容

4. 瀏覽器以指定編碼解析HTML內容

這里的四次字符編解碼，有一次發生錯誤最終顯示的就會是亂碼。我們依次來分析各次的字符編碼是如何設置的。

- 保存JSP文件，這是在編輯器中設置的，比如eclipse中，設置文件字符類型為utf-8。

- JSP文件開頭的《%@ page language=“java” contentType=“text/html; charset=utf-8” pageEncoding=“utf-8”%》，其中pageEncoding用來告訴tomcat此文件所用的字符編碼。這個編碼應該與eclipse保存文件用的編碼一致。Tomcat以此編碼方式來讀取JSP文件并編譯。

- page標簽中的contentType用來設置tomcat往瀏覽器發送HTML內容所使用的編碼。這個編碼會在HTTP響應頭中指定以通知瀏覽器。

- 瀏覽器根據HTTP響應頭中指定的字符編碼來解析HTML內容。如：

HTTP/1.1 200 OK

Date： Mon， 01 Sep 2008 23:13:31 GMT

Server： Apache/2.2.4 （Win32） mod_jk/1.2.26

Vary： Host，Accept-Encoding

Set-Cookie： JAVA2000_STYLE_ID=1; Domain=www.java2000.net;     Expires=Thu， 03-Nov-2011 09:00:10 GMT; Path=/

Content-Encoding： gzip

Transfer-Encoding： chunked

Content-Type： text/html;charset=UTF-8

另外，HTML中有個標簽《meta http-equiv=“Content-Type” content=“text/html; charset=UTF-8”》中也指定了charset。不過這個字符編碼只有在當網頁保存在本地作為靜態網頁時有效，因為沒有HTTP頭，所以瀏覽器根據此標簽來識別HTML內容的編碼方式。

現在在JSP文件中硬編碼出現亂碼的機會比較小了，因為大家都用了如eclipse的編輯器，基本上可以自動保證這幾個編碼設置的正確性。現在更多碰到的是在JSP文件中從其他數據源中讀取中文字符所產生的亂碼問題。

在JSP文件中讀取字符文件并在頁面中顯示，中文字符顯示為亂碼。

比如，我們在JSP文件中使用以下代碼：

《%

BufferedReader reader = new BufferedReader（new FileReader（“D：\\test.txt”））;

String content = reader.readLine（）;

reader.close（）;

%》

《%=content%》

test.txt里保存的是中文字符，但在瀏覽器上看到的亂碼。這是個經常見到的問題。我們繼續用之前的方法一步步來分析輸入和輸出流

1. test.txt是以某種編碼方式保存中文字符，比如UTF-8。

2. BufferedReader直接讀取test.txt的字節內容并以默認方式構造字符串。分析BufferedReader的代碼，我們可以看到 BufferedReader調用了FileReader的read方法，而FileReader又調用了FileInputStream的native 的read方法。所謂native的方法，就是操作系統底層方法。那么我們操作系統是中文系統，所以FileInputStream默認用GBK方式讀取 文件。因為我們保存test.txt用的是UTF-8，所以在這里讀取文件內容使用的是GBK，是錯誤的編碼。

3. 《%=content%》其實就是out.print（content），這里又用到了HTTP的輸出流JspWriter，于是字符串content又被以JSP的page標簽中指定的UTF-8方式編碼成字節數組被發送到瀏覽器端。

4. 瀏覽器以HTTP頭中指定的方式解碼字符，這時無論是用GBK還是UTF-8解碼，顯示的都是亂碼。

可見，我們字符編碼轉換在第二步時出錯了，UTF-8的字符串被當做GBK讀入了內存中。

解決這個亂碼問題有兩種方法，一是把test.txt用GBK保存，則FileInputStream能正確讀入中文字符；二是使用InputStreamReader來轉換字符編碼，如：

InputStreamReader sr = new InputStreamReader（new FileInputStream（"D：\\test.txt"），"utf-8"）;

BufferedReader reader = new BufferedReader（sr）;

這樣，JAVA就會用utf-8的方式來從文件中讀取字符數據。

另外，我們可以通過在java命令后帶上Dfile.encoding參數來指定虛擬機讀取文件使用的默認字符編碼，例如java -Dfile.encoding=utf-8 Test，這樣，我們在JAVA代碼里用System.getProperty（“file.encoding”）取到的值為utf-8。

四、JSP讀取request.getParameter里的中文參數后，在頁面顯示為亂碼。

在JAVA的WEB應用中，對request對象里的parameters的中文處理一直是常見也最難搞的一只大怪獸。經常是剛搞定了這邊，那邊又出了亂 碼。而導致這種復雜性的，主要是此過程中字符編解碼次數非常多，而且無論是瀏覽器還是WEB服務器特別是TOMCAT總是不能給我們一個比較滿意的支持。

首先我們來分析用GET方式上傳參數的亂碼情況。

例如我們在瀏覽器地址欄輸入以下URL：http://localhost:8080/test/test.jsp？param=大家好

我們的JSP代碼如此處理param這個參數：

《% String text = request.getParameter（“param”）; %》

《%=text%》

而就這么簡單的兩句代碼，我們很有可能在頁面上看到這樣的亂碼：？ó？？？？

網上對處理request.getParamter中的亂碼有很多文章和方法，也都是正確的，只是方法太多讓人一直不明白到底是為什么。這里給大家分析一下到底是怎么一回事。

首先，我們來看看與request對象有哪些相關的編碼設置：

1. JSP文件的字符編碼

2. 請求這個帶參數URL的源頁面的字符編碼

3. IE的高級設置中的選項“總以utf-8方式發送URL地址”

4. TOMCAT的server.xml中配置URIEncoding

5. 函數request.setCharacterEncoding（）

6. JS的encodeURIComponent函數與JAVA的URLDecoder類

這么多條相關編碼設置，也難怪大家被搞得頭暈了。這里給大家根據各種情況給大家一一分析一下。見下表：

以上表格里的現象，除了指名在IE7上，其他全是在IE6上測試的結果。

由這個表我們可以看到，IE的“總以utf-8方式發送URL地址”設置并不影響對parameter的解析，而從頁面請求URL和從地址欄輸入URL居然也有不同的表現。

根據這個表列出的現象，大家只要用smartSniff抓幾個網絡包，并稍稍調查一下TOMCAT的源代碼，就可以得出以下結論：

1. IE設置中的“總以utf-8方式發送URL地址”只對URL的PATH部分起作用，對查詢字符串是不起作用的。也就是說，如果勾選了這個選項，那么類似http://localhost:8080/test/大家好.jsp？param=大家好這種URL，前一個“大家好”將被轉化成utf-8形式，而后一個并沒有變化。這里所說的utf-8形式，其實應該叫utf-8+escape形式，即%B4%F3%BC%D2%BA%C3這種形式。

那么，查詢字符串中的中文字符，到底是用什么編碼傳送到服務器的呢？答案是系統默認編碼，即GBK。也就是說，在我們中文操作系統上，傳送給WEB服務器的查詢字符串，總是以GBK來編碼的。

2. 在頁面中通過鏈接或location重定向或open新窗口的方式來請求一個URL，這個URL里面的中文字符是用什么編碼的？

     答：是用該頁面的編碼類型。也就是說，如果我們從某個源JSP頁面上的鏈接來訪問http://localhost:8080/test/test.jsp？param=大家好這個URL，如果源JSP頁面的編碼是UTF-8，則大家好這幾個字的編碼就是UTF-8。

     而在地址欄上直接輸入URL地址，或者從系統剪貼板粘貼到地址欄上，這個輸入并非從頁面中發起的，而是由操作系統發起的，所以這個編碼只可能是系統的默認 編碼，與任何頁面無關。我們還發現，在不同的瀏覽器上，用鏈接方式打開的頁面，如果在地址欄上再敲個回車，顯示的結果也會不同。IE上敲回車后顯示不變 化，而傲游上可能就會有亂碼或亂碼消失的變化。說明IE上敲回車，實際發送的是之前記憶下來的內存中的URL，而傲游上發送的從當前地址欄重新獲取的 URL。

3. TOMCAT的URIEncoding如果不加以設置，則默認使用ISO-8859-1來解碼URL，設置后便用設置了的編碼方式來解碼。這個解碼同時包 括PATH部分和查詢字符串部分。可見，這個參數是對用GET方式傳遞的中文參數最關鍵的設置。不過，這個參數只對GET方式傳遞的參數有效，對POST 的無效。分析TOMCAT的源代碼我們可以看到，在請求一個頁面時，TOMCAT會嘗試構造一個Request對象，在這個對象里，會從 Server.xml里讀取URIEncoding的值，并賦值給Parameters類的queryStringEncoding變量，而這個變量將在 解析request.getParameter中的GET參數時用來指導字符解碼。

4. request.setCharacterEncoding函數只對POST的參數有效，對GET的參數無效。且這個函數必須是在第一次調用 request.getParameter之前使用。這是因為Parameters類有兩個字符編碼參數，一個是encoding，另一個是 queryStringEncoding，而setCharacterEncoding設置的是encoding，這個是在解析POST的參數是才用到 的。

所以，這就導致了我們通常都要分開處理POST和GET的字符編碼，用TOMCAT自帶的filter只能處理POST的，另外要設置URIEncoding來設置GET的。這樣很麻煩而且URIEncoding無法根據內容來動態區分編碼，總還是一個問題。

        在調查TOMCAT的代碼時發現了另一個在server.xml里的參數useBodyEncodingForURI，可以解決這個問題。這個參數設成 true后，TOMCAT就會用request.setCharacterEncoding所設置的字符編碼來同樣解析GET參數了。這樣，那個 SetCharacterEncodingFilter就可以同時處理GET和POST參數了。

知道了以上知識后，我們再來分析一下前面表格中列出的幾個典型現象。

      第一條，請求源頁面的編碼為UTF-8，而TOMCAT的URIEncoding未指定，則TOMCAT用ISO8859-1方式來解碼參數，所以從request中讀出來后，內存中存儲的為錯誤的UNICODE數據，導致之后到屏幕顯示的所有轉換全部出錯。

      第二條，請求源頁面編碼為GBK，而TOMCAT的URIEncoding也為GBK，TOMCAT用GBK方式去解碼塬本用GBK編碼的字符，解碼正確，內存中的UNICODE值正確，最終顯示正確的中文。

      第三條，請求源頁面編碼為UTF-8，TOMCAT的URIEncoding也為UTF-8，而在IE6中最終顯示的中文字符，如果是奇數個數，則最后一個會顯示為亂碼。這是為什么呢？

我的猜測是，這是因為IE6將URL地址發送時，對查詢字符串是直接對UTF-8格式的字符使用GBK來編碼，而不是對UNICODE的字符來用GBK編 碼，所以UTF-8的數據沒有經過UNICODE而直接編碼成了GBK。而到了TOMCAT這邊，GBK的編碼又被當成UTF-8做了解碼。所以這個過程 中經過了UTF-8轉換成GBK，然后又從GBK轉換成UTF-8的過程，而這種轉換，恰好就會出現奇數個中文字符串的最后一位為亂碼的現象。而在IE7 中，估計把這種現象當做BUG已經被解決了，即在發送地址時會先轉成UNICODE再編碼成GBK。那么估計在IE7的瀏覽器+中文操作系統環境下，如果 我們把TOMCAT的URIEncoding設置成GBK，無論JSP編碼成什么格式，都不會出現亂碼。這個沒測試，請大家自己驗證。

其他幾條就不再做分析了，有興趣的大家自己分析。

五、對URL做Encode和Decode

     對于request參數的中文亂碼問題，個人覺得最好的還是用URLEncode/URLDecode，因為如果你的WEB站點要支持國際化，最好就是保證從IE遞送過來的參數永遠是正確的UTF-8編碼。

     在IE端，我們可以用JS腳本來對參數編碼：encodeURIComponent（），編碼后中文字符便變成了%B4%F3%BC%D2%BA%C3這 種形式。在JAVA端，可以用java.net.URLDecoder.decode來解碼。不過這里要注意一個問題，就是TOMCAT會自動先對URL 做一次decode，我們可以在TOMCAT的UDecoder類中看到這一點。不過    TOMCAT并非使用了URLDecoder.decode，而是自己編寫了一個decode函數。網上有些文章上介紹過一種處理亂碼的方法便是在JS中對參數做兩次encodeURIComponent，在JAVA中做 一次decode，可以解決一些沒有設置URIEncoding時發生的亂碼問題。不過個人覺得如果弄懂了整個字符編碼轉換的過程，基本上是用不到這種方法的。

六、從數據庫中讀取中文字符數據，在頁面上顯示為亂碼。

     對于數據庫中讀取中文字符出現亂碼的問題，本人遇到的還比較少，所以暫時沒有總結。如果大家有類似的經驗，歡迎補充說明，我一定注明作者身份。

     好了，對各種字符亂碼問題的分析就總結到這里，相信只要把握“以指定編碼讀取--轉換為UNICODE--以指定編碼輸入”這基本步驟，初學者也可以很快 分析出字符亂碼的根源所在。另外我建議不要隨便使用new String（str.getBytes（enc1），enc2）這種方式來強行轉碼，也不要隨便使用網上的字符轉碼函數，我覺得只會把問題隱藏更深更復 雜化。我們應該清晰地分析整個字符流的編解碼過程，自然可以找出亂碼的根源所在，從而保證整個字符流動中，在內存中的UNICODE始終是正確的。