jsp向後臺傳中文，tomcat和weblogic下中文亂碼解決方法

前端jsp:GBK編碼
        var groupsName = "全體組";
        window.location.href="http://archive.cnblogs.com/a/2192992/<%25=path" target="_blank" rel="nofollow">skillGroups="+groupsName;
後臺:GBK編碼
        String groupsName = request.getParameter("skillGroups");
        得到groupsName爲亂碼。
起初在tomcat下調試：
        這樣處理
        window.location.href="http://archive.cnblogs.com/a/2192992/<%25=path" target="_blank" rel="nofollow">encodeURI(groupsName);
        String groupsName = request.getParameter("skillGroups");
 if(groupsName!=null&&!groupsName.equals("")){
      String loc=new String(groupsName.getBytes("iso-8859-1"),"utf-8"); //tomcat下正常
      groupsName = loc;
        }
        這是因爲tomcat默認的編碼方式爲iso-8859-1，在前臺用encodeURI編碼了一次，你的參數內容便不帶有多字節字符了，成了純粹的 Ascii 字符串，
tomcat容器request.getParameter("skillGroups")自動解碼一次，注意這裏就是按照tomcat默認的編碼方式解碼的，這樣處理下  String loc=new String(groupsName.getBytes("iso-8859-1"),"utf-8");就是將最後的中文轉成utf-8編碼。

後來將項目部到weblogic11gR1上又出現亂碼問題。
 
        這樣處理
        window.location.href="http://archive.cnblogs.com/a/2192992/<%25=path" target="_blank" rel="nofollow">encodeURI(encodeURI(groupsName));
        String groupsName = request.getParameter("skillGroups");
        if (null != groupsName && groupsName.trim().length() != 0) {
        groupsName = URLDecoder.decode(groupsName, "UTF-8");
        System.out.println("DECODE::groupsName:"+groupsName);
 }
        前臺進行兩次編碼，後臺容器自動解碼一次，在手動解碼一次解碼爲正常顯示中文的編碼方式。這樣好處在於不用考慮所用容器的編碼方式。
因爲第一次編碼，你的參數內容便不帶有多字節字符了，成了純粹的 Ascii 字符串。(這裏把編第一次的結果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多字節字符的)
再編一次後，提交，接收時容器自動解一次　（容器自動解的這一次，不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好，都能夠正確的得到 [STR_ENC1]）
然後，再在程序中實現一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的參數的原值。