在平常使用web框架进行web开发时，经常讨论的一个问题就是一个中文的乱码问题。一般情况下，包括get乱码和post乱码，都能很好的解决，只需要通过配置tomcat以及增加相应的filter即可。但如果，本身tomcat并不参与解析编码时，即就不能很好地解决了。
通常在使用一些链接时，我们偶尔会显式地传递一些中文的参数，用于显式查询。如下面的一段url地址(使用源代码查看时的链接地址)：
这个地址在参数中直接带了一个中文的参数”销售”,那么这个参数传递在服务器端时，采用的何种编码进行传递的呢。如果使用firefox，我们会看到firefox将其转化为gbk编码进行传输，如下所示:
值得注意的是，这个转换是由firefox在界面上直接进行转换的，即在源代码中查看为”销售”的中文，在界面上转换时就自动转换成了%CF%FA%CA%DB。
而使用ie时，则不会发生转换，也就是说,ie直接发送中文信息到服务器端，地址信息即会变为:
这个和在源代码中看到的是一样的。
正常情况下，这两种情况都不会有问题，对于firefox，因为已经转换为gbk的url编码格式，在由tomcat进行转码时，会自动转换为CFFA CADB(即销售的gbk编码形式)；对于ie，由于是直接发送，传递到tomcat时就是CFFA CADB的编码，经由gbk转换，自然就变成了正确的形式。即在底层发送时，对于”销售”这个中文参数值,firefox发送为%CF%FA%CA%DB,而ie发送为CFFACADB(字节流方式)，两者在经由tomcat的gbk编码转换时，都没有问题。
问题出现在哪儿，当需要在浏览器上，重现当前请求的地址时，即将刚才请求的地址信息，重新显示在界面上(通常这种应用在分页上用得多，即整个请求地址不变，只替换其中的分布参数信息)。这时候，在使用struts2的标签时以及标签时，就会出问题了。
如在分页应用时，ie在地址栏出现的中文参数，在使用分页重新进行地址引用时，就会出现如下的结果：
问题就出现在struts2对于url标签，在进行地址重现时的处理手段上，在解析地址信息时(通常是get形式),它并没有使用标签的getParameter形式，而是使用了getQueryString形式。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/201683.html原文链接：https://javaforall.net
