如何解决浏览器不兼容问题 java中文乱码问题的终极解决方案(5)

对于URL中的一些特殊字符，浏览器会自动进行编码。这些字符除了"/&"等外，还包括unicode字符，比如汉子。这时的编码比较特殊。

IE有一个选项"总是使用UTF-8发送URL"，当该选项有效时，IE将会对特殊字符进行UTF-8编码，同时进行URL编码。如果改选项无效，则使用默认编码"GBK"，并且不进行URL编码。但是，对于URL后面的参数，则总是不进行编码，相当于UTF-8选项无效。比如"中文.htmla=中文"，当UTF-8选项有效时，将发送链接"%e4%b8%ad%e6%96%87.htmla=\x4e\x2d\x65\x87";而UTF-8选项无效时，将发送链接"\x4e\x2d\x65\x87.htmla=\x4e\x2d\x65\x87"。注意后者前面的"中文"两个字只有4个字节，而前者却有18个字节，这主要时URL编码的原因。

当web server(tomcat)接收到该链接时，将会进行URL解码，即去掉"%"，同时按照ISO8859-1编码(上面已经描述，可以使用URLEncoding来设置成其它编码)识别。上述例子的结果分别是"\ue4\ub8\uad\ue6\u96\u87.htmla=\u4e\u2d\u65\u87"和"\u4e\u2d\u65\u87.htmla=\u4e\u2d\u65\u87"，注意前者前面的"中文"两个字恢复成了6个字符。这里用"\u"，表示是unicode。

所以，由于客户端设置的不同，相同的链接，在服务器上得到了不同结果。这个问题不少人都遇到，却没有很好的解决办法。所以有的网站会建议用户尝试关闭UTF-8选项。不过，下面会描述一个更好的处理办法。

5.2. rewrite

熟悉的人都知道，apache有一个功能强大的rewrite模块，这里不描述其功能。需要说明的是该模块会自动将URL解码(去除%)，即完成上述web server(tomcat)的部分功能。有相关文档介绍说可以使用[NE]参数来关闭该功能，但我试验并未成功，可能是因为版本(我使用的是apache 2.0.54)问题。另外，当参数中含有"& "等符号的时候，该功能将导致系统得不到正常结果。

rewrite本身似乎完全是采用字节处理的方式，而不考虑字符串的编码，所以不会带来编码问题。

5.3. URLEncode.encode()

这是Java本身提供对的URL编码函数，完成的工作和上述UTF-8选项有效时浏览器所做的工作相似。值得说明的是，java已经不赞成不指定编码来使用该方法(deprecated)。应该在使用的时候增加编码指定。如何解决浏览器不兼容问题

当不指定编码的时候，该方法使用系统默认编码，这会导致软件运行结果得不确定。比如对于"中文"，当系统默认编码为"gb2312"时，结果是"%4e%2d%65%87"，而默认编码为"UTF-8"，结果却是"%e4%b8%ad%e6%96%87"，后续程序将难以处理。另外，这儿说的系统默认编码是由运行tomcat时的环境变量LC_ALL和LANG等决定的，曾经出现过tomcat重启后就出现乱码的问题，最后才郁闷的发现是因为修改修改了这两个环境变量。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-73658-5.html