791
java中文亂碼解決之道（六）—–javaWeb中的編碼解碼
通過下圖我們可以了解在javaWeb中有哪些地方有轉碼：
用戶想服務器發送一個HTTP請求，需要編碼的地方有url、cookie、parameter，經過編碼後服務器接受HTTP請求，解析HTTP請求，然後對url、cookie、parameter進行解碼。在服務器進行業務邏輯處理過程中可能需要讀取數據庫、本地文件或者網絡中的其他文件等等，這些過程都需要進行編碼解碼。當處理完成後，服務器將數據進行編碼後發送給客戶端，瀏覽器經過解碼後顯示給用戶。在這個整個過程中涉及的編碼解碼的地方較多，其中最容易出現亂碼的位置就在於服務器與客戶端進行交互的過程。
上麵整個過程可以概括成這樣，頁麵編碼數據傳遞給服務器，服務器對獲得的數據進行解碼操作，經過一番業務邏輯處理後將最終結果編碼處理後傳遞給客戶端，客戶端解碼展示給用戶。所以下麵我就請求對javaweb的編碼&解碼進行闡述。
客戶端想服務器發送請求無非就通過四中情況：
1、URL方式直接訪問。
2、頁麵鏈接。
3、表單get提交
4、表單post提交
對於URL，如果該URL中全部都是英文的那倒是沒有什麼問題，如果有中文就要涉及到編碼了。如何編碼？根據什麼規則來編碼？又如何來解碼呢？下麵LZ將一一解答！首先看URL的組成部分：
在這URL中瀏覽器將會對path和parameter進行編碼操作。為了更好地解釋編碼過程，使用如下URL
https://127.0.0.1:8080/perbank/ 我是cm?name=我是cm
將以上地址輸入到瀏覽器URL輸入框中，通過查看http 報文頭信息我們可以看到瀏覽器是如何進行編碼的。下麵是IE、Firefox、Chrome三個瀏覽器的編碼情況：
可以看到各大瀏覽器對“我是”的編碼情況如下：
查閱上篇博客的編碼可知對於path部分Firefox、chrome、IE都是采用UTF-8編碼格式，對於Query String部分Firefox、chrome采用UTF-8，IE采用GBK。至於為什麼會加上%，這是因為URL的編碼規範規定瀏覽器將ASCII字符非 ASCII 字符按照某種編碼格式編碼成 16 進製數字然後將每個 16 進製表示的字節前加上“%”。
當然對於不同的瀏覽器，相同瀏覽器不同版本，不同的操作係統等環境都會導致編碼結果不同，上表某一種情況，對於URL編碼規則下任何結論都是過早的。由於各大瀏覽器、各個操作係統對URL的URI、QueryString編碼都可能存在不同，這樣對服務器的解碼勢必會造成很大的困擾，下麵我們將已tomcat，看tomcat是如何對URL進行解碼操作的。
解析請求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，這個方法把傳過來的 URL 的 byte[] 設置到 org.apache.coyote.Request 的相應的屬性中。這裏的 URL 仍然是 byte 格式，轉成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：
protected void convertURI(MessageBytes uri, Request request)
throws Exception {
ByteChunk bc = uri.getByteChunk();
int length = bc.getLength();
CharChunk cc = uri.getCharChunk();
cc.allocate(length, -1);
String enc = connector.getURIEncoding(); //獲取URI解碼集
if (enc != null) {
B2CConverter conv = request.getURIConverter();
try {
if (conv == null) {
conv = new B2CConverter(enc);
request.setURIConverter(conv);
}
} catch (IOException e) {...}
if (conv != null) {
try {
conv.convert(bc, cc, cc.getBuffer().length - cc.getEnd());
uri.setChars(cc.getBuffer(), cc.getStart(), cc.getLength());
return;
} catch (IOException e) {...}
}
}
// Default encoding: fast conversion
byte[] bbuf = bc.getBuffer();
char[] cbuf = cc.getBuffer();
int start = bc.getStart();
for (int i = 0; i < length; i++) {
cbuf[i] = (char) (bbuf[i + start] & 0xff);
}
uri.setChars(cbuf, 0, length);
}
從上麵的代碼可知，對URI的解碼操作是首先獲取Connector的解碼集，該配置在server.xml中
<Connector URIEncoding="utf-8" />
如果沒有定義則會采用默認編碼ISO-8859-1來解析。
對於Query String部分，我們知道無論我們是通過get方式還是POST方式提交，所有的參數都是保存在Parameters，然後我們通過request.getParameter，解碼工作就是在第一次調用getParameter方法時進行的。在getParameter方法內部它調用org.apache.catalina.connector.Request 的 parseParameters 方法，這個方法將會對傳遞的參數進行解碼。下麵代碼隻是parseParameters方法的一部分：
//獲取編碼
String enc = getCharacterEncoding();
//獲取ContentType 中定義的 Charset
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) { //如果設置編碼不為空，則設置編碼為enc
parameters.setEncoding(enc);
if (useBodyEncodingForURI) { //如果設置了Chartset，則設置queryString的解碼為ChartSet
parameters.setQueryStringEncoding(enc);
}
} else { //設置默認解碼方式
parameters.setEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
從上麵代碼可以看出對query String的解碼格式要麼采用設置的ChartSet要麼采用默認的解碼格式ISO-8859-1。注意這個設置的ChartSet是在 http Header中定義的ContentType，同時如果我們需要改指定屬性生效，還需要進行如下配置：
<Connector URIEncoding="UTF-8" useBodyEncodingForURI="true"/>
上麵部分詳細介紹了URL方式請求的編碼解碼過程。其實對於我們而言，我們更多的方式是通過表單的形式來提交。
我們知道通過URL方式提交數據是很容易產生亂碼問題的，所以我們更加傾向於通過表單形式。當用戶點擊submit提交表單時，瀏覽器會更加設定的編碼來編碼數據傳遞給服務器。通過GET方式提交的數據都是拚接在URL後麵（可以當做query String？？）來提交的，所以tomcat服務器在進行解碼過程中URIEncoding就起到作用了。tomcat服務器會根據設置的URIEncoding來進行解碼，如果沒有設置則會使用默認的ISO-8859-1來解碼。假如我們在頁麵將編碼設置為UTF-8，而URIEncoding設置的不是或者沒有設置，那麼服務器進行解碼時就會產生亂碼。這個時候我們一般可以通過new String(request.getParameter(“name”).getBytes(“iso-8859-1″),”utf-8”) 的形式來獲取正確數據。
對於POST方式，它采用的編碼也是由頁麵來決定的即contentType。當我通過點擊頁麵的submit按鈕來提交表單時，瀏覽器首先會根據ontentType的charset編碼格式來對POST表單的參數進行編碼然後提交給服務器，在服務器端同樣也是用contentType中設置的字符集來進行解碼（這裏與get方式就不同了），這就是通過POST表單提交的參數一般而言都不會出現亂碼問題。當然這個字符集編碼我們是可以自己設定的：request.setCharacterEncoding(charset) 。
最後更新：2017-07-06 17:32:37