客戶端提交資料到服務有兩種方式GET和POST
1.get方式
資料直接在url上進行拼接,使用&分隔key-value對.
但有時key,value會出現中文等對於html標準來說不安全的字元
html標準說
除了字元”a”-”z”，”A”-”Z”，”0″-”9″，”.”，”-”，”*”，和”_” 其他的字元都是不安全的,需要進行編碼.其中” “空格會被編碼成+號
當出現不安全字元時,在傳送到伺服器之前,瀏覽器會將這些引數值進行編碼,一般推薦是使用utf-8編碼格式.
字元被轉換為1個或者多個位元組,然後每個位元組都被表示成”%xy”格式的由3個字元組成的字串，xy是位元組的2位16進位制的表示.
也可以使用javascript對資料進行encodeURIComponent(url);
現在的url就成了ASCII範圍內的字元了，然後以iso-8859-1的編碼方式轉換成二進位制隨著請求頭一起傳送出去,對於get方法來說，沒有請求實體，含有資料的url都在請求頭裡面
請注意,其實這裡進行了兩次編碼,第一次是使用UTF8,第二次使用iso-8859-1編碼成能在網路上傳輸二進位制101010….
現在問題來到了伺服器端,每種伺服器預設的編碼方式都可能不同,比如tomcat預設編碼就是iso-8859-1, 而resin預設編碼是utf-8
按道理伺服器端也會做兩次的解碼動作,第一次是對二進位制內容的iso-8859-1的解碼,第二次是使用伺服器預設的編碼對資料進行解碼,
因此我們使用request.getParameter(“name”)得到的資料是經過兩次解碼的.
當tomcat使用iso-8859-1對資料進行第二次解碼時,因為對應客戶端編碼是utf8,
因此我們使用request.getParameter(“name”)就肯定亂碼.
如果我們不去改變tomcat的預設編碼,可以使用
new String(request.getParameter(“name”).getBytes(“iso-8859-1″), “utf-8″);手工重新解碼.
request.setCharacterEncoding(“utf-8″)這種方式對於get方式提交資料是無效的,
但是對post方式提交資料卻是有效的.因為get沒有request body.

通常的做法還是修改tomcat的預設編碼:
在server.xml中的connector加上URIEncoding=”UTF-8″即可

2.post方式
post方式提交的資料也是必須進行編碼的.
如果form所在html檔案指定了編碼,就使用那個編碼進行url編碼.

總結:為了防止出現亂碼,一般系統相關的檔案都設成utf8格式,web伺服器,java伺服器,資料庫的編碼格式都設為utf8.這樣一般比較少出現亂碼問題.
還有就是儘量使用post方式提交資料,一個是因為url的長度是有限制的,而get方式是將資料拼接到url上的.