關於Character decoding failed. Parameter skipped.java.io.CharConversionException的問題

今天調程序時需要在新增記錄前進行唯一性檢查，使用了.post函數。在拼接post的url參數時會將一input標簽的值作為參數。

function dsnameCheck(){
  var name= $("#name").val();
  var url="local_datasource?method=checkDsName&name="+name;
  $.post(url,function(data){
     if($.trim(data)=="yes"){  
         alert("該子類名已存在");
       }else{
          var form1 = document.getElementById('form1');
          form1.action='local_datasource?method=add&status=save';
          form1.submit();
        }
  });
}

測試功能時，當input內輸入的內容為“;;''%%”時，數據能夠添加，但編譯器報Character decoding failed. Parameter skipped.java.io.CharConversionException的異常。試了幾次發現有"%"就會出現這個問題。查了些資料發現參數傳遞中有參數包含有“%”時需要做一下轉換，不然就會出現這個問題。

function dsnameCheck(){
  var name= $("#name").val();
  var url="local_datasource?method=checkDsName&name="+name;
  url = encodeURI(url);
  url = encodeURI(url);
  $.post(url,function(data){
     if($.trim(data)=="yes"){  
         alert("該子類名已存在");
       }else{
          var form1 = document.getElementById('form1');
          form1.action='local_datasource?method=add&status=save';
          form1.submit();
        }
  });
}

在前台進行以上兩次轉換，后台接收后再進行如下的轉碼，就能解決這個問題了：

    String name = request.getParameter("name");
    name=java.net.URLDecoder.decode(name,"UTF-8");

至於兩次編碼的原因，在網上找到的解釋(http://bbs.csdn.net/topics/330072196)：

一般情況下, 發送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
接收時, 直接 String paramValue = request.getParameter(paramName); // 容器自動解碼.

我們知道 encodeURIComponent 使用的是 UTF-8 編碼規則來編的.
如果 request.getParameter(paramName) 時,容器也按 UTF-8 解的話,是正確的. 根本無須在客戶端
進行二次的 encodeURIComponent(...)


如果 request.getParameter(paramName),容器沒有按 UTF-8 解的話, 結果只有一個,就是亂碼!
容器按什么編碼來解碼,決定於 request.setCharacterEncoding(***) 或者 服務器程序配置.

如果你在 jsp 程序中,能夠 request.setCharacterEncoding("UTF-8"), 並且 修改服務器配置,讓容器在解 GET 提交的參數時,使用 UTF-8.

客戶端提交前不用二次編碼, 接收時,也只要直接 request.getParameter(paramName) 即可

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

為什么網上會有人提出在客戶端對字符串重復編碼兩次呢.
如果因為項目需要,不能指定容器使用何種編碼規則來解碼提交的參數, 比如:需要接收來自不同頁面，不地編碼的參數內容時。 (又或者是開發人員被這有點復雜的東東搞得暈頭轉向，不懂得如何正確的去做好這接收參數的工作)
這個時候，在客戶端對參數進行二次編碼，可以有效的避開“提交多字節字符”的這個棘手問題。
因為第一次編碼，你的參數內容便不帶有多字節字符了，成了純粹的 Ascii 字符串。(這里把編第一次的結果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多字節字符的)
再編一次后，提交，接收時容器自動解一次　（容器自動解的這一次，不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好，都能夠正確的得到 [STR_ENC1]）
然后，再在程序中實現一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的參數的原值。