頁面傳值地址爛亂碼問題

 位址列中出現漢字的情況有兩種，一種是漢字出現在URL的路徑部分，一種是漢字出現在URL的傳參的部分，第二種情況的時候必須採用編碼後傳參，接受時解碼的方式完成傳參。js中編碼有escape(),encodeURI(),encodeURIComponent()三個常用的方法，escape()常常用在提交頁面和處理頁面的編碼格式相同的情況下（比如它們都是GB2312），encodeURI()和encodeURIComponent()的用法基本相同，區別在於encodeURIComponent()也對"?"等特殊字元進行編碼。 
一開始遇到中文引數的時候，使用encodeURI()進行了一遍編碼，傳過去後，發現解碼出現問題，於是想到可能是編碼方法使用錯誤，於是使用escape()方法，這時發現解碼時丟擲isHexDigit異常。藉助百度搜尋isHexDigit異常， 
發現原來，是escape()方法造成了異常，同時瞭解了瀏覽器傳遞地址的一些原理，在瀏覽器位址列裡，瀏覽器認為%是個轉義字元，瀏覽器會把%與%之間的編碼，兩位兩位取出後進行解碼,然後再傳遞給處理頁面， 
然後由處理頁面進行再次解碼。由此我想到一直使用encodeURI方法是正確的，只是需要使用兩次encodeURI方法，例如encodeURI(encodeURI("中文"));第一次是把中文編碼成%xy的格式， 
第二次是對%xy中的%進行編碼,%編碼成%25。整個傳參過程大體應該是：提交頁面使用encodeURI(encodeURI("中文"))編碼,把最後的編碼結果%25xy傳遞給處理頁面的過程中，瀏覽器獲取URL地址 
（注意openModelDialog方法，瀏覽器獲取不到引數編碼）後解碼成%xy，然後把%xy傳遞給處理頁面,處理頁面使用URLDecoder.decode(request.getParameter("引數名"),"UTF-8");完成解碼。 
總結： 
1、漢字出現在URL路徑部分的時候不需要編碼解碼; 
2、使用encodeURI進行2次編碼; 
3、在openModelDialog()開啟的模式窗體裡沒辦法用request.getParameter正確獲取引數; 


客戶端和伺服器在傳遞資料時可以用過濾器filter解決字元編碼問題，但filter只能解決post方式提交的資料。對於get方式，可以使用兩次encodeURI(encodeURI(“中文”))並在伺服器中使用URLDecoder.decode(“中文”, "UTF-8"); 

今天用Ajax校驗資料時也遇到這個問題，儘管頁面、類和web容器都統一了字元編碼，提交的資料依然是亂碼，所以就採用了2次encodeURI()編碼方式，亂碼問題就解決了。 
頁面 
/exportExcel.topinfo?ls="+encodeURI(encodeURI(_tmplsgx))+"&zt="+encodeURI(encodeURI(_tmpzt))s
action中 
 String ls=request.getParameter("ls");
  ls = new String(ls.getBytes("iso-8859-1"),"utf-8");
  ls = java.net.URLDecoder.decode(ls,"UTF-8");這樣亂碼就解決了。