JAVA中文字符编码问题详解(3)
五、对URL做Encode和Decode
对于request参数的中文乱码问题,个人觉得最好的还是用URLEncode/URLDecode,因为如果你的WEB站点要支持国际化,最好就是保证从IE递送过来的参数永远是正确的UTF-8编码。
在IE端,我们可以用JS脚本来对参数编码:encodeURIComponent(),编码后中文字符便变成了%B4%F3%BC%D2%BA%C3这种形式。在JAVA端,可以用java.net.URLDecoder.decode来解码。不过这里要注意一个问题,就是TOMCAT会自动先对URL 做一次decode,我们可以在TOMCAT的UDecoder类中看到这一点。不过TOMCAT并非使用了URLDecoder.decode,而是自 己编写了一个decode函数。网上有些文章上介绍过一种处理乱码的方法便是在JS中对参数做两次encodeURIComponent,在JAVA中做 一次decode,可以解决一些没有设置URIEncoding时发生的乱码问题。不过个人觉得如果弄懂了整个字符编码转换的过程,基本上是用不到这种方法的。
六、从数据库中读取中文字符数据,在页面上显示为乱码。
对于数据库中读取中文字符出现乱码的问题,本人遇到的还比较少,所以暂时没有总结。如果大家有类似的经验,欢迎补充说明,我一定注明作者身份。
好了,对各种字符乱码问题的分析就总结到这里,相信只要把握“以指定编码读取--转换为UNICODE--以指定编码输入”这基本步骤,初学者也可以很快 分析出字符乱码的根源所在。另外我建议不要随便使用new String(str.getBytes(enc1),enc2)这种方式来强行转码,也不要随便使用网上的字符转码函数,我觉得只会把问题隐藏更深更复杂化。我们应该清晰地分析整个字符流的编解码过程,自然可以找出乱码的根源所在,从而保证整个字符流动中,在内存中的UNICODE始终是正确的。
另外再附上个人总结的乱码分析的一套秘籍!即从乱码的长相来分析是哪种编码转换错误。有人可以闻香识酒,我们也来个看字识码。请看下表:
名称 |
示例 |
特点 |
产生原因 |
古文码 |
鐢辨湀瑕佸ソ濂藉涔犲ぉ澶╁悜涓? |
大都为不认识的古文,并加杂日韩文 |
以GBK方式读取UTF-8编码的中文 |
口字码 |
����Ҫ�¨²�ѧϰ������ |
大部分字符为小方块 |
以UTF-8的方式读取GBK编码的中文 |
符号码 |
ç±æè¦å¥½å¥½å¦ä¹ 天天åä¸ |
大部分字符为各种符号 |
以ISO8859-1方式读取UTF-8编码的中文 |
拼音码 |
ÓÉÔÂÒªºÃºÃѧϰÌìÌìÏòÉÏ |
大部分字符为头顶带有各种类似声调符号的字母 |
以ISO8859-1方式读取GBK编码的中文 |
问句码 |
由月要好好学习天天向?? |
字符串长度为偶数时正确,长度为奇数时最后的字符变为问号 |
以GBK方式读取UTF-8编码的中文,然后又用UTF-8的格式再次读取 |
锟拷码 |
锟斤拷锟斤拷要锟矫猴拷学习锟斤拷锟斤拷锟斤拷 |
全中文字符,且大部分字符为“锟斤拷”这几个字符 |
以UTF-8方式读取GBK编码的中文,然后又用GBK的格式再次读取 |
不过个人至今仍然弄不明白的就是问号码的产生原因,问号码即所有字符几乎全部为问号的乱码。问号码的出现有多种情况。我目前能确认的当我们把中文字符强行以ISO8859-1编码写入文件后,字符的高位信息会丢失,从而再次从文件中读出字符时便全部变为问号符。而我在JAVA代码中用UTF-8的方式去读 取GBK编码的字符,出来的也是问号码,而并非口字码,这是我百思不得其解的问题。