把gbk的编码按utf-8来解码，可能导致的不可恢复的错误

上一遍文章：http://blog.csdn.net/chinainvent/archive/2010/05/02/5550438.aspx　提到，utf-8使用三个字节来表示一个汉字（更准确的说，是使用三个字节来表示unicode内码为2048至65535的文字）。

 

那么，这带来了一个问题。当utf-8使用三个字节来表示一个汉字时，它要求这三个字节的格式为：

1110yyyy 10yyyyxx 10xxxxxx

 

如果某个字节的前四位满足1110，那么utf-8的解码器，就要求其后的两个字节的前两位都必须是10。若不满足此格式，就会产生解码失败，utf-8解码器使用：0xEF 0xBF 0xBD（这三个字符表示一个“�”）来代替第一个字节，并对第二个字节进行解码，以此类推。

 

正是因为存在解码失败的可能性，所以当我们误把一个gbk编码的汉字，以utf-8来解码时，就有可能得到“�”字符，即乱码。而且，一旦把gbk误当成utf-8来解码，就有可能把一个汉字的gbk码变成：0xEF 0xBF 0xBD，造成信息的丢失，无法逆向恢复！

 

 

在使用java的String类时，这个问题，非常明显：

 

String org_str = "我";         //假设java环境的内部编码，已经设置为utf-8

 

byte[] gbk_byte1 = org.getBytes("gbk");

 

String err_str = new String(gbk_byte, "utf-8");      //把一个gbk的byte组数，当成utf-8来解码，将造成信息丢失

 

byte[] gbk_byte2 = err_str.getBytes("gbk");         //比较后，会发现gbk_byte1与gbk_byte2已经不一致。

 

把org_str与err_str这两个字符串打印出来，结果如下：

 

org_str: 我

err_str: ��

 

因为“我”字的gbk编码里，有两个字节：

 0xCE 0xD2    =>    11001110 11010010

 

而utf-8在解码时，遇到11001110时，因为前缀为110，它期望下一个字节的格式为：10xxxxxx，显然不满足所以使用“�”来代替，然后继续解码下一个字节；解码第二字节时，也是同样的错误，所以产生了两个了“�”。