IE缺省对URL后面的参数是不编码发送的,但是Tomat缺省是按ISO8859-1来进行URL编码的,因此才会出错。

方法一:

对URL链接进行二次编码:

<a onclick="javascript:window.open(encodeURI(encodeURI('./DispatchAction.do">测试</a>

或者单独对参数进行二次编码:

var code_type = "中文参数";
code_type = encodeURI(code_type); 
code_type = encodeURI(code_type);
window.open("./DispatchAction.do"+code_type);
Service:
String code_type = request.getParameter("code_type");
//这句话一定要写,因为如果不写的话编码就是%E5%A6%88%
code_type = java.net.URLDecoder.decode(code_type,"UTF-8");

有人提出为什么要在客户端对字符串重复编码两次呢?

如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数,比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东西搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)

这个时候,在客户端对参数进行二次编码,可以有效的避开“提交多字节字符”的这个棘手问题。

因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)

再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])

然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder.decode(***, "UTF-8"))就可以得到想提交的参数的原值。

简单来说,就是Tomcat服务器会自动帮你做一次URLDecode,再加上你自己在Service代码里面写的URLDecode,一共就是两个Decode了。既然要两次Decode,当然就需要两次Encode了。或许你会问,干脆只Encode一次,然后在java代码里不Decode,呵呵,这个也是不行的,这其实也就是为什么要进行两次Encode的原因吧。

方法二:(经测试不支持IE8)

http://xxx.do"ptname");
strPtname = new String(strPtname.getBytes("ISO-8859-1"), "UTF-8");

方法三:

<%@ page contentType="text/html;charset=gb2312" %>
<a href="ds.jsp"编码的是这里","GB2312")%>">点击这里</a>
<%
//request.setCharacterEncoding("GBK");
if(request.getParameter("url")!=null)
{
str=request.getParameter("url");
str=java.net.URLDecoder.decode(str,"GB2312");
str=new String(str.getBytes("ISO-8859-1"));
out.print(str);
}
%>

方法四:
Tomcat中设置server.xml中的Connector熟悉URIEncoding="UTF-8",确保解码格式与编码格式统一。

标签:
JSP,URL,中文乱码

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
评论“JSP对URL链接中的中文乱码处理方法总结”
暂无“JSP对URL链接中的中文乱码处理方法总结”评论...