jsp向后台传中文，tomcat和weblogic下中文乱码解决方法

tec_feng

前端jsp:GBK编码
        var groupsName = "全体组";
        window.location.href = "/CustomersServlet?method=service_customer&skillGroups="+groupsName;
后台:GBK编码
        String groupsName = request.getParameter("skillGroups");
        得到groupsName为乱码。
起初在tomcat下调试：
        这样处理
        window.location.href = "/CustomersServlet?method=service_customer&skillGroups="+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 = "/CustomersServlet?method=service_customer&skillGroups="+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")) 就可以得到想提交的参数的原值。


扩展学习
url参数中带有#号的情况，例如通过url向后台传”递DAAU#####F33“字符串时候，后台接收只能得到"DAAU"，#号全部丢失，这个原因估计是浏览器解析的原因
这下encodeURI就不好用了，这时要用到encodeURIComponent，下面说一下二者区别：
　　js 中encodeURI 与 encodeURIComponent的区别
　　encodeURI方法返回一个编码的 URI。如果您将编码结果传递给 decodeURI，那么将返回初始的字符串。encodeURI方法不会对下列字符进行编码：":"、"/"、";" 和 "?"。请使用 encodeURIComponent 方法对这些字符进行编码。经过我测试“#”也属于这个特殊字符的范畴，使用encodeURI编码时#是不会被编码的，所以上面场景的问题依然存在的，对于这种输入的内容，肯定是用encodeURIComponent。