1.   為什么會產(chǎn)生亂碼？

因為瀏覽器不允許提交非ASCII字符，如果提交了非ASCII，則瀏覽器自動對其進行編碼，將它們轉(zhuǎn)換為ASCII字符。根據(jù)瀏覽器的不同，轉(zhuǎn)換時使用的編碼也不同，比如有些瀏覽器會使用utf-8進行編碼，而有些會使用gbk進行編碼。

2.   瀏覽器為什么不允許提交非ASCII字符？

以下是我個人觀點，僅供參考。

因為瀏覽器和服務器通信，傳輸?shù)亩际亲止?jié)。而我們在頁面提交的都是字符，所以瀏覽器底層就有一個將字符轉(zhuǎn)換為字節(jié)的過程，這個過程涉及到編碼，瀏覽器到底是用utf-8、gbk還是iso-8859-1將字符轉(zhuǎn)換為字節(jié)呢？我想應該是iso-8859-1，因為這是西歐默認使用的編碼。何況，也沒有任何理由使用前兩種編碼格式。但是iso-8859-1編碼是不能識別中文以及其他非ASCII字符的，所以如果字符中存在這類字符，那么將字符轉(zhuǎn)換為字節(jié)的過程中勢必會產(chǎn)生亂碼。為了避免這種情況的發(fā)生，瀏覽器自動對非ASCII字符進行了編碼，將這類字符轉(zhuǎn)換為ASCII字符，這樣就能避免亂碼問題。

3.   GET和POST提交表單，分別根據(jù)什么對非ASCII字符進行編碼？

GET：

情況比較復雜，不同瀏覽器也不一樣，有的使用gbk，有的使用utf-8不好一概而論。

POST：

瀏覽器會根據(jù)網(wǎng)頁編碼對表單中的數(shù)據(jù)編碼。比如我們在jsp頁面第一行所寫的：<%@page contentType="text/html;charset=UTF-8"%>。那么這個網(wǎng)頁響應給客戶端后使用的就是utf-8編碼，那么post時使用的也是這個編碼。

編碼后的格式可以參考java中的URLEncoder.encode方法編碼的結(jié)果。

4.   服務器底層如何處理提交的數(shù)據(jù)。

上面2已經(jīng)提到，客戶端和服務器端傳輸?shù)氖亲止?jié)，那么服務器端接收到的原始數(shù)據(jù)就是字節(jié)。但是我們的程序通常需要從服務器獲取字符，而不是字節(jié)，所以服務器端必須將字節(jié)轉(zhuǎn)換為字符。這里也涉及編碼，服務器采取什么編碼方式將字節(jié)轉(zhuǎn)換為字符？我想也是iso-8859-1，這樣和客戶端的編碼方式一致，不會產(chǎn)生亂碼，相當于一個還原字符的過程。這里有個問題，比如客戶端發(fā)送：name=%D6%D0%B9%FA，那么服務器端還原后也是：name=%D6%D0%B9%FA。那么我們使用request.getParameter(“name”)如何能得到正確的值呢？難道要我們自己再進行轉(zhuǎn)換？答案是：NO。根據(jù)Servlet規(guī)范，Servlet中獲取數(shù)據(jù)的方法會按照指定的字符集解碼。指定的字符集是什么？默認是iso-8859-1。正是因為使用了iso-8859-1解碼我們發(fā)送的參數(shù)，導致了亂碼的產(chǎn)生，這里才是產(chǎn)生亂碼的源頭。具體解碼的過程可以看看java的URLDecode.decode方法。既然知道了產(chǎn)生亂碼的原因是因為服務器默認使用iso-8859-1解碼，那我們就得想辦法更改服務器使用的解碼編碼。好在服務器已經(jīng)提供給我們修改的方式了，我們可以在服務器中進行配置，比如Tomcat可以在server.xml中進行配置，比如：URIEncoding="GBK"這樣服務器就會使用gbk編碼解碼，這種方式主要針對GET提交的數(shù)據(jù)，對于POST更常用的是request.setCharacterEncoding(String charset)設置解碼編碼。

5.   為了避免亂碼，客戶端應該如何做？

GET：

對于含有非ASCII字符的URL自己進行編碼，比如使用javascript中的方法進行編碼。這樣就不需要瀏覽器為我們編碼了，從而解決了瀏覽器編碼的不確定性。

POST：

只要正確設置網(wǎng)頁編碼即可。