中文亂碼 encodeURI來解決URL傳遞時的中文問題

標籤：opera   系統   預設   位元組數組   tle   客戶   通過   過程   請求   

解決中文亂麻問題，頁面端發出的資料作兩次encodeURI

var name="張三";

encodeURI(encodeURI(name));

後台解碼：

 URLDecoder.decode(name,"UTF-8");

參考：http://blog.csdn.net/zqd_java/article/details/53608585

 

------------------------------------------------------------------------------------------------------------------

URL編碼與兩次encodeURI

當使用地址欄提交查詢參數時，如果不編碼，非英文字元會按照作業系統的字元集進行編碼提交到伺服器，伺服器會按照配置的字元集進行解碼，所以如果兩者不一致就會導致亂碼。

encodeURI函數採用UTF-8對URL進行編碼，所以如果伺服器在進行解碼時使用的是其他的編碼方式就會出現亂碼，預設的伺服器配置的解碼字元集都不是UTF-8，所以大部分情況下地址欄提交中文查詢參數時會產生亂碼；針對這種情況，可以連續使用兩次encodeURI在用戶端(主要指瀏覽器)對非英文字元進行編碼，然後在服務端使用Java.NET.URLDecoder(String."UTF-8")解碼，即可得到正確的中文。

如果只進行一次encodeURI，得到的是UTF-8形式的URL，伺服器端通過request.getParameter()解碼查詢參數(通常是iso-8859-1)就會得到亂碼。

如果進行兩次encodeURI,第一次編碼得到的是UTF-8形式的URL，第二次編碼得到的依然是UTF-8形式的URL，但是在效果上相當於首先進行了一次UTF-8編碼(此時已經全部轉換為ASCII字元)，再進行了一次iso-8859-1編碼，因為對英文字元來說UTF-8編碼和ISO-8859-1編碼的效果相同。在伺服器端，首先通過request.getParameter()自動進行第一次解碼(可能是gb2312,gbk,utf-8,iso-8859-1等字元集,對結果無影響)得到ascii字元，然後再使用UTF-8進行第二次解碼，通常使用java.net.URLDecoder("","UTF-8")方法。

兩次編碼兩次解碼的過程為：

UTF-8編碼->UTF-8(iso-8859-1)編碼->iso-8859-1解碼->UTF-8解碼，編碼和解碼的過程是對稱的，所以不會出現亂碼。

encodeURL函數主要是來對URI來做轉碼，它預設是採用的UTF-8的編碼.
. UTF-8編碼的格式:一個漢字來三個位元組構成，每一個位元組會轉換成16進位的編碼，同時添加上%號.

假設頁面端輸入的中文是一個“中”，按照下面步驟進行解碼

1.第一次encodeURI，按照utf-8方式擷取位元組數組變成[-28,-72-83]，對位元組碼數組進行遍曆，把每個位元組轉化成對應的16進位數，這樣就變成了[E4,B8,AD],最後變成[?,?,?]  此時已經沒有了多位元組字元，全部是單位元組字元。

2、第二次encodeURI，進行編碼，會把%看成一個逸出字元，並不編碼%以後字元，會把%編碼成%.把數組最後變成[?,?,?]然後就把處理後的資料[?,?,?]發往伺服器端，
當應用伺服器調用getParameter方法，getParameter方法會去嚮應用伺服器請求參數
應用伺服器最初獲得的就是發送來的[?,?,?]，應用伺服器會對這個資料進行URLdecode操作，應用伺服器進行解碼的這一次，不管是按照UTF-8，還是GBK，還是ISO-8859，,都能得到[?,?,?]，因為都會把%解析成%.並把這個值返回給getParameter方法

3、再用UTF-8解碼一次，就得到"中"了。

想想看，如果不編碼兩次，當伺服器自動解碼的時候，假如是按照ISO-8859去解碼UTF-8編碼的東西，就是會出現亂碼。

中文亂碼 encodeURI來解決URL傳遞時的中文問題