考慮以下場景，在瀏覽器地址欄中直接輸入"http://localhost:8080/helloapp.do?username=編輯"提交，對于這種方式，瀏覽器不會采用頁面的charset方式，也不會按照filter設(shè)置的編碼方式。URL中的中文進(jìn)行編碼后，提交至服務(wù)器(IE,FireFox都一樣)，而是采用系統(tǒng)的GBK(估計可能和browser的語言版本或設(shè)置相關(guān)，我的機(jī)器上是編碼到GBK)轉(zhuǎn)碼為ISO- 8859-1之后，提交至Servlet容器，那么，如果對于前三種方式我們所做的設(shè)置，此種場景下就不正常了。因?yàn)?，進(jìn)入容器時中文進(jìn)行了GBK至ISO- 8859-1的轉(zhuǎn)碼，而之前我們的Servlet容器URIEncoding設(shè)置為UTF-8，當(dāng)我們使用 request.getParameter("username")時，相當(dāng)于又進(jìn)行了這樣的流程GBK-->ISO- 8859-1-->UTF-8，按照以上我們使用的測試，那么就會是亂碼了。此時，如果是使用GBK-->ISO- 8859-1-->GBK的方式轉(zhuǎn)換，那么就能正常取出中文漢字。
對于這種情況，我們可以采用的解決辦法就是，Tomcat的URIEncoding采用默認(rèn)的ISO-8859-1字符集，那么我們可以在程序中通過ISO-8859-1-->GBK這樣的轉(zhuǎn)碼方式得到正常的中文“編輯”，但這樣的結(jié)果是，我們get請求方式的中文處理解決辦法，就有問題了。
綜上分析所述，對于亂碼問題，前三種方式是一般用戶的請求方式，第四種屬于非正常途徑的請求方式，對于這種方式產(chǎn)生的問題，可能無法很好的解決(和瀏覽器有關(guān)server端無法控制)。測試IE6的設(shè)置會影響應(yīng)用路徑的編碼方式，例如地址欄中請求一個中文JSP頁面，如：http://localhost:8080/helloapp/編輯.jsp，IE默認(rèn)是勾選"以UTF-8發(fā)送 URL"項(xiàng)的，那么按照我上面總結(jié)的處理方式，這個請求可以正常顯示頁面，如圖：
如果取消IE的這個選項(xiàng)，那么瀏覽器會以GBK編碼應(yīng)用路徑的中文，得到的結(jié)果如圖：
按照我上面的設(shè)置，如果將Tomcat的URIEncoding設(shè)置為GBK，則也可以正常顯示頁面。對于FireFox3.0，則是以UTF-8編碼。因此，第四種場景是和客戶端相關(guān)。
因此，在項(xiàng)目中盡量避免第4種場景的情況出現(xiàn)，就基本可以解決java web開發(fā)中的亂碼問題了。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報。
