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编码
        Str ing 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]）
然后，再在程序中实现一次 decodeURIComp onent ( Java中通常使用 java. net.URLDecoder(***, "UTF-8")) 就 可以得到想提交的参数的原值。