乱码常见问题分析。

    出现乱码问题是因为在从char到byte或从byte到char的转换中编码和解码的字符集不一致导致的,由于一次操作涉及多次编解码,所以出现乱码时很难查到到底是哪个环节出现了问题。下面就对几种常见的情况进行分析。

中文变成了看不懂的字符

    字符串在解码时所用的字符集与编码字符集不一致会导致汉字变成看不懂的乱码,而且是一个汉字字符变成两个乱码字符。

一个汉字变成一个问号

    将中文和中文符号经过不支持中文的ISO-8859-1编码后,所有字符变成了“?”,这是因为用ISO-8859-1进行编解码时,遇到不在码值范围内的字符会统一用3f表示,这也就是通常所说的“黑洞”,所有ISO-8859-1不认识的字符都变成了“?”。

一个汉字变成两个问号

    这种情况比较复杂,中文经过了多次编码,但是其中有一次编码或者解码不对仍然会出现中文字符变成“?”的情况,这时要仔细查看中间的编码环节,找出出现编码错误的地方。

一种不正常的正确编码

    还有一种情况是我们在通过request.getParameter获取参数值时,直接调用
    String value = request.getParameter(name);
    会出现乱码,但是如果用下面的方式:
    String value = String(request.getParameter(name).getBytes("ISO-8859-1"),"GBK");
    解析时取得的value会是正确的汉字字符。这种情况是怎么造成的呢?
    这种情况是这样的,ISO-8859-1字符集的编码范围0000~00FF,正好和一个字节的编码范围相对应。这种特性保证了使用ISO-8859-1进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时,被错误的“拆”成了两个欧洲字符,但由于输出时也用了ISO-8859-1,结果被“拆”开的中文字的两半又被合并在一起,刚好组成了一个正确的汉字。虽然最终能取得正确的汉字,但还是不建议用这种不正常的方式取得参数值,因为这中间增加了一次额外的编码与解码。在这种情况下出现乱码是因为在Tomcat的配置文件中没有将useBodyEncodingForURI配置项设置为“true”,从而造成第一次解析是ISO-8859-1来解析。

猜你喜欢

转载自blog.csdn.net/en_joker/article/details/81332308