JSP指令標簽中<%@ page contentType="text/html;charset=GB2312"%>這句有什麼用途？
關於JSP頁面中的pageEncoding和contentType兩種屬性的區別：
pageEncoding是jsp文件本身的編碼
contentType的charset是指服務器發送給客戶端時的內容編碼
JSP要經過兩次的“編碼”，第一階段會用pageEncoding，第二階段會用utf-8至utf-8，第三階段就是由Tomcat出來的網頁， 用的是contentType。
第一階段是jsp編譯成.java，它會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8 JAVA源碼（即.java），如果pageEncoding設定錯了，或沒有設定，出來的就是中文亂碼。
第二階段是由JAVAC的JAVA源碼至java byteCode的編譯，不論JSP編寫時候用的是什麼編碼方案，經過這個階段的結果全部是UTF-8的encoding的java源碼。
JAVAC用UTF-8的encoding讀取java源碼，編譯成UTF-8 encoding的二進制碼（即.class），這是JVM對常數字串在二進制碼（java encoding）內表達的規范。
第三階段是Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼，輸出的結果，也就是在客戶端見到的，這時隱藏在階段一和階段二的參數contentType就發揮了功效
contentType的設定.
pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個, 另一個就跟著一樣了(TOMCAT4.1.27是如此). 但這不是絕對的, 這要看各自JSPC的處理方式. 而pageEncoding不等於contentType, 更有利亞洲區的文字 CJKV系JSP網頁的開發和展示, (例pageEncoding=GB2312 不等於 contentType=utf-8)。
jsp文件不像.java，.java在被編譯器讀入的時候默認采用的是操作系統所設定的locale所對應的編碼，比如中國大陸就是GBK，台灣就是BIG5或者MS950。而一般我們不管是在記事本還是在ue中寫代碼，如果沒有經過特別轉碼的話，寫出來的都是本地編碼格式的內容。所以編譯器采用的方法剛好可以讓虛擬機得到正確的資料。
但是jsp文件不是這樣，它沒有這個默認轉碼過程，但是指定了pageEncoding就可以實現正確轉碼了。
舉個例子:
<%@ page contentType="text/html;charset=utf-8" %>
大都會打印出亂碼，因為輸入的“你好”是gbk的，但是服務器是否正確抓到“你好”不得而知。
但是如果更改為
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>
這樣就服務器一定會是正確抓到“你好”了。
Java中將數據由UTF8轉換成GB2312格式
關鍵字: java字符編碼
UTF8轉換成GB2312 當我們在基於HTTP協議的JSP或Servlet的應用中獲取數據或發送請求時，JVM會把輸送的數據編碼成UTF8格式。如果我們直接從HTTP流中 提取中文數據，提取的結果為“????”（可能更多問號），為轉換成我們能夠理解的中文字符，我們需要把UTF8轉換成GB2312，借助ISO- 8859-1標准編碼能夠輕易的實現，下面的代碼實現了這一功能：
byte [] b;
String utf8_value;
utf8_value = request.getParameter("NAME");//從HTTP流中取"NAME"的UTF8數據
b = utf8_value.getBytes("8859_1"); //中間用ISO-8859-1過渡
String name = new String(b, "GB2312"); //轉換成GB2312字符
這是我做的一個項目程序的一段：
byte[] b;
String gbk_value;
gbk_value=request.getParameter("address");//從HTTP流中取"name"的GBK數據（由於web.xml中過濾器設置默認編碼為GBK，所以外網從UTF-8變為GBK）
b=gbk_value.getBytes("GBK");//中間用GBK過渡，從GBK轉換成GBK數組
String address=new String(b,"utf-8");//轉換成utf-8字符
myform.setAddress(address);
在知道流長度的情況下將輸入流轉換成字節數組 Java中的輸入流抽象類InputStream有int read(byte[] b, int off, int len)方法，參數中byte[] b是用來存放從InputStream中讀取的數據,int off指定數組b的偏移地址，也就是數組b的起始下標，int len指定需要讀取的長度，方法返回實際讀取的字節數。
剛學Java 的朋友可能要說：先定義一個與流長度等長的字節數組，調用read方法，指定起始下標為0，指定讀取長度與數組長度等長，不是一下子可以讀出來了嗎？說的 沒錯，筆者曾經也試著這樣讀取數據，但後來發現在讀取網絡數據時很不安全，我們想想在網絡上獲取數據可能並沒那麼流暢，數據流的傳送可能會斷斷續續，所以 並不能保證一次就能讀取全部數據，特別是在讀取大容量數據時更是如此，所以我們必須在讀取數據時檢測實際讀到的長度，如果沒有讀完已知長度的數據就應該再 次讀取，以此循環檢測，直到實際讀取的長度累加與已知的長度相等，下面的代碼實現了這一功能：
ServletInputStream inStream = request.getInputStream(); //取HTTP請求流
int size = request.getContentLength(); //取HTTP請求流長度
byte[] buffer = new byte[size]; //用於緩存每次讀取的數據
byte[] in_b = new byte[size]; //用於存放結果的數組
int count = 0;
int rbyte = 0;
while (count < size) {
//循環讀取
rbyte = inStream.read(buffer); //每次實際讀取長度存於rbyte中
for(int i=0;i
在不知道流長度的情況下將輸入流轉換成字節數組 前面介紹了已知流長度的情況下的轉換方法，那麼當我們不知道流有多長時，也就是說不能確定轉換後的字節數組有多大時，該怎麼處理呢？筆者查看了JDK文檔 之後發現ByteArrayOutputStream有一個byte[] toByteArray()方法，該方法會自動創建一個字節數組，然後返回。於是就巧妙的用ByteArrayOutputStream來作中間過渡實現 轉換，其它處理跟上面所介紹已知長度的情況差不多。假設需要被轉換的流已經放在inStream裡了，我們可以用如下的代碼實現這一功能：
ByteArrayOutputStream swapStream = new ByteArrayOutputStream();
byte[] buff = new byte[100]; //buff用於存放循環讀取的臨時數據
int rc = 0;
while ((rc = inStream.read(buff, 0, 100)) > 0) {
swapStream.write(buff, 0, rc);
}
byte[] in_b = swapStream.toByteArray(); //in_b為轉換之後的結果
JSP 中 pageEncoding charset 的區別
首先，說說JSP/Servlet中的幾個編碼的作用。
在JSP/Servlet中主要有以下幾個地方可以設置編 碼，pageEncoding="UTF-8"、contentType="text/html;charset=UTF-8"、request.setCharacterEncoding("UTF-8")和 response.setCharacterEncoding("UTF-8")，其中前兩個只能用於JSP中，而後兩個可以用於JSP和Servlet 中。
1、pageEncoding="UTF-8"的作用是設置JSP編譯成Servlet時使用的編碼。
眾所周知，JSP在服務 器上是要先被編譯成Servlet的。pageEncoding="UTF-8"的作用就是告訴JSP編譯器在將JSP文件編譯成Servlet時使用的 編碼。通常，在JSP內部定義的字符串（直接在JSP中定義，而不是從浏覽器提交的數據）出現亂碼時，很多都是由於該參數設置錯誤引起的。例如，你的 JSP文件是以GBK為編碼保存的，而在JSP中卻指定pageEncoding="UTF-8"，就會引起JSP內部定義的字符串為亂碼。
另外，該參數還有一個功能，就是在JSP中不指定contentType參數，也不使用response.setCharacterEncoding方法時，指定對服務器響應進行重新編碼的編碼。
2、contentType="text/html;charset=UTF-8"的作用是指定對服務器響應進行重新編碼的編碼。
在不使用response.setCharacterEncoding方法時，用該參數指定對服務器響應進行重新編碼的編碼。
3、request.setCharacterEncoding("UTF-8")的作用是設置對客戶端請求進行重新編碼的編碼。
該方法用來指定對浏覽器發送來的數據進行重新編碼（或者稱為解碼）時，使用的編碼。
4、response.setCharacterEncoding("UTF-8")的作用是指定對服務器響應進行重新編碼的編碼。
服務器在將數據發送到浏覽器前，對數據進行重新編碼時，使用的就是該編碼。
其次，要說一說浏覽器是怎麼樣對接收和發送的數據進行編碼的
response.setCharacterEncoding("UTF- 8")的作用是指定對服務器響應進行重新編碼的編碼。同時，浏覽器也是根據這個參數來對其接收到的數據進行重新編碼（或者稱為解碼）。所以在無論你在 JSP中設置response.setCharacterEncoding("UTF-8")或者 response.setCharacterEncoding("GBK")，浏覽器均能正確顯示中文（前提是你發送到浏覽器的數據編碼是正確的，比如正 確設置了pageEncoding參數等）。讀者可以做個實驗，在JSP中設置response.setCharacterEncoding("UTF- 8")，在IE中顯示該頁面時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是" Unicode（UTF-8）"，而在在JSP中設置response.setCharacterEncoding("GBK")，在IE中顯示該頁面 時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是"簡體中文（GB2312）"。
浏覽器在發送數據時，對URL和參數會 進行URL編碼，對參數中的中文，浏覽器也是使response.setCharacterEncoding參數來進行URL編碼的。以百度和 GOOGLE為例，如果你在百度中搜索"漢字"，百度會將其編碼為"%BA%BA%D7%D6"。而在GOOGLE中搜索"漢字"，GOOGLE會將其編 碼為"%E6%B1%89%E5%AD%97"，這是因為百度的response.setCharacterEncoding參數為GBK，而 GOOGLE的的response.setCharacterEncoding參數為UTF-8。
浏覽器在接收服務器數據和發送數據到服務器 時所使用的編碼是相同的，默認情況下均為JSP頁面的response.setCharacterEncoding參數（或者contentType和 pageEncoding參數），我們稱其為浏覽器編碼。當然，在IE中可以修改浏覽器編碼（在IE的菜單中選擇"查看(V)"à"編碼(D)"中修 改），但通常情況下，修改該參數會使原本正確的頁面中出現亂碼。一個有趣的例子是，在IE中浏覽GOOGLE的主頁時，將浏覽器編碼修改為"簡體中文 （GB2312）"，此時，頁面上的中文會變成亂碼，不理它，在文本框中輸入"漢字"，提交，GOOGLE會將其編碼為"%BA%BA%D7%D6"，可 見，浏覽器在對中文進行URL編碼時，使用的就是浏覽器編碼。
弄清了浏覽器是在接收和發送數據時，是如何對數據進行編碼的了，我們再來看看服務器是在接收和發送數據時，是如何對數據進行編碼的。
對於發送數據，服務器按照response.setCharacterEncoding—contentType—pageEncoding的優先順序，對要發送的數據進行編碼。
對於接收數據，要分三種情況。一種是浏覽器直接用URL提交的數據，另外兩種是用表單的GET和POST方式提交的數據。
因為各種WEB服務器對這三種方式的處理也不相同，所以我們以Tomcat5.0為例。
無論使用那種方式提交，如果參數中包含中文，浏覽器都會使用當前浏覽器編碼對其進行URL編碼。
對於表單中POST方式提交的數據，只要在接收數據的JSP中正確request.setCharacterEncoding參數，即將對客戶端請求進行重 新編碼的編碼設置成浏覽器編碼，就可以保證得到的參數編碼正確。有寫讀者可能會問，那如何得到浏覽器編碼呢？上面我們提過了，在默認請情況下，浏覽器編碼 就是你在響應該請求的JSP頁面中response.setCharacterEncoding設置的值。所以對於POST表單提交的數據，在獲得數據的 JSP頁面中request.setCharacterEncoding要和生成提交該表單的JSP頁面的 response.setCharacterEncoding設置成相同的值。
對於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方式的請求的數據進行統一的重新 編碼（解碼），而useBodyEncodingForURI則是根據響應該請求的頁面的request.setCharacterEncoding參數 對數據進行的重新編碼（解碼），不同的頁面可以有不同的重新編碼（解碼）的編碼。所以對於URL提交的數據和表單中GET方式提交的數據，可以修改 URIEncoding參數為浏覽器編碼或者修改useBodyEncodingForURI為true，並且在獲得數據的JSP頁面中 request.setCharacterEncoding參數設置成浏覽器編碼。
下面總結下，以Tomcat5.0為WEB服務器時，如何防止中文亂碼。
1、對於同一個應用，最好統一編碼，推薦為UTF-8，當然GBK也可以。
2、正確設置JSP的pageEncoding參數
3、在所有的JSP/Servlet中設置contentType="text/html;charset=UTF-8"或response.setCharacterEncoding("UTF-8")，從而間接實現對浏覽器編碼的設置。
4、 對於請求，可以使用過濾器或者在每個JSP/Servlet中設置request.setCharacterEncoding("UTF-8")。同時， 要修改Tomcat的默認配置，推薦將useBodyEncodingForURI參數設置為true，也可以將URIEncoding參數設置為 UTF-8（有可能影響其他應用，所以不推薦）。
作者 婁立軍
