Java中文乱码原因(未完)

Java在中文环境中乱码无处不在,而且出现的时间和位置也包涵广泛,具体的解决方法也是千奇百怪。
但是如果能理清其中的脉络,理解字符处理的过程,对于解决问题很有指导意义,不至于解决了问题也不知道为什么。
其实,原因不外乎出在String输入时和输出时。

首先,Java中的任何String都是以UNICODE格式存在的。
    很多人因为在GBK环境中使用String,会误以为String是GBK格式,实际上Java的String类中并没有存储CharSet信息的字段,所有String中的字符只会以UNICODE的2字节形式存在。
    String在构造时会逐一把字符按指定编码(默认值为系统编码GBK),转换为UNICODE字符,存入一个Char(无符号16位)数组中。
   
    如:
    new String(bytes,"gbk");
   
    并不是说,生成一个GBK编码的字符串,而是按GBK逐一辨认字节数组bytes中的字符转化为UNICODE。
    假设,bytes本是按GB编码的,构造方法在发现一个最高位为0的byte就作为ascii字符处理,最高位为1就和后面的一个byte合成中文字符,再转换编码。
    可以看出,在这个过程中,编码选择错误就会导致程序按错误方法辨认bytes,乱码就出现了。
    在这里产生的乱码,很多时候还可以通过.getByte()方法修复,还没有后面的严重。
   
    如:
    "中".getBytes("iso-8859-1");
   
    因为iso-8859-1中没有中文,所以"中"的值被替换成63,显示'?',无法判断以前是什么值。
   
    所以如下String将被破坏掉:
    new String("中文".getBytes("iso-8859-1"),"iso-8859-1");
   
    如果目标编码方式支持中文,就不会损坏String:
    new String("中文".getBytes("utf-8"),"utf-8");

Java在显示字符时,还需要进行一次转换,把UNICODE字符转换成用于显示的字符编码形式。
    很多时候,这个过程是自动的,会按系统的默认编码(一般是GBK)转换String。
    如果和页面编码不一样,就会出现乱码,虽然在Java的程序中只有一种编码,输出却可以有不同的编码。
   
有时候,我们需要用iso-8859-1格式分解String的中文,以便在不支持中文的系统中存储:
    new String("中文".getBytes("GBK"),"iso-8859-1");
    先通过GBK等支持中文的编码方式分解为byte数组,再做为iso-8859-1字符组成字符串,就避免了被替换为Char(63)。