在《再谈java乱码:GBK和UTF-8互转尾部乱码问题分析》我们分析了,如果从一个UTF-8 的字节序列,经过 new String(b,"GBK")
的操作,”可能”(与总字节数有关)会破坏数据。结果可能是,损失最后一个”字”。
反过来呢?可能会很惨,大范围溃散。。。
同时,可参考:一段java代码带你认识锟斤拷
来看一段代码:
public static void main(String[] args) throws IOException, ParseException {
String str="中国人";
System.out.println(str);
byte[] b=str.getBytes("GBK");
System.out.println("GBK-8 字节码长度:"+b.length);
printHex(b);
System.out.println("******");
str=new String(b,"UTF-8");
b=str.getBytes("UTF-8");
printHex(b);
System.out.println("按照通常的经验,三个汉字的UTF-8长度,应该是9,然而不是。");
System.out.println("UTF-8 字节码长度:"+b.length);
System.out.println("******");
System.out.println("why?");
b="中国人".getBytes("UTF-8");
System.out.println("三个汉字的UTF-8字节码应该是:"+b.length);
printHex(b);
}
private static void printHex(byte[] b) {
StringBuilder sb=new StringBuilder();
for(byte t:b) {
sb.append(Integer.toHexString((t & 0xF0)>>4).toUpperCase());
sb.append(Integer.toHexString(t & 0xF).toUpperCase())
.append(" ");
}
System.out.println(sb.toString());
}
输出结果:
中国人
GBK-8 字节码长度:6
D6 D0 B9 FA C8 CB
******
EF BF BD D0 B9 EF BF BD EF BF BD EF BF BD
按照通常的经验,三个汉字的UTF-8长度,应该是9,然而不是。
UTF-8 字节码长度:14
******
why?
三个汉字的UTF-8字节码应该是:9
E4 B8 AD E5 9B BD E4 BA BA
原因在于,str=new String(b,"UTF-8");
这行代码破坏了数据,而在此之前的数据是正常的。
我们通常说,UTF-8字符集的汉字,每一个字占3个字节。我们并没有说过 UTF-8 字符集的一个字符都是3个字节。
UTF-8是一种变长字节编码方式,它的长度从1~6个字节都是合法的编码范围。
对于某一个字符的UTF-8编码,如果只有一个字节则其最高二进制位为0;
如果是多字节,其第一个字节从最高位开始,二进制位中连续的1的个数决定了其编码的位数,其余各字节均以10开头。
UTF-8最多可用到6个字节。
具体可以参看下表:
utf-8的字节数(byte) | 有效数据位(bit) |
---|---|
1 | 0xxxxxxx |
2 | 110xxxxx 10xxxxxx |
3 | 1110xxxx 10xxxxxx 10xxxxxx |
4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
5 | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
6 | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
我们来数一下x的数量,也就是每一种编码规则包含的有效数据位:
utf-8的字节数(byte) | 有效数据位(bit) |
---|---|
1 | 7 |
2 | 5+6=11 |
3 | 4+6*2=16 |
4 | 3+6*3=21 |
5 | 2+6*4=26 |
6 | 1+6*5=31 |
那么,如果需要编码的bit数大于可以编码的bit数,则该编码方案无效。
假设需要编码的数据位为6 bits,那么这个六种方案都可以编码;如果需要编码的数据位为27 bits,那么只有6字节方案可以编码。
但事与愿违,抛开浪费空间不说,如果我们把3字节汉字的数据位前面强行置0,让它以4字节编码,数据转换过程还是会破坏,这里留一个疑问。
那么,4字节字符到底是什么?emoji,所谓Emoji就是一种在Unicode位于 \u1F601-\u1F64F
区段的字符。这个显然超过了目前常用的UTF-8字符集的编码范围 \u0000-\uFFFF
。
如 “{(byte)0xF0,(byte)0x9F,(byte)0x98,(byte)0x81}” 表示一个笑脸。
言归正传,实际上我们关注的是Unicode和UTF-8之间的关系:
Unicode符号范围 | UTF-8编码方式 |
---|---|
0000 0000-0000 007F | 0xxxxxxx |
0000 0080-0000 07FF | 110xxxxx 10xxxxxx |
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
根据编码规则,我们手动来把一个汉字进行一个转码,来实际体验一下:
public static void main(String[] args) throws Exception {
System.out.println("UTF-8:");
printBin("中".getBytes("UTF-8"));
System.out.println("unicode:");
printOctet("中".getBytes("UTF-16BE"));
//上面打印的unicode码是:01001110 00101101
//要转为UTF-8 ,我们要知道它占用了几个数据位
//数一数,去掉高位前面的0,是15个数据位
//查上面的表可以知道,可以使用3字节及以上的编码方案
//完整的unicode码被分段为:0100 111000 101101,分别拼接上头,如下:
byte[] tmpb= {(byte)Integer.parseInt("1110"+"0100",2) //第一个字节是1110xxxx
,(byte)Integer.parseInt("10"+"111000",2)
,(byte)Integer.parseInt("10"+"101101",2)
};
//打印看看,应该没问题
System.out.println(new String(tmpb,"UTF-8"));
}
开头提出了问题,现在就解决问题。
例子中的三个汉字,用UTF-8 转一次为什么不是意料中的9字节,而是14个字节呢?
我们把代码改一下,打印一下二进制。
public static void main(String[] args) throws Exception {
String str = "中国人";
byte[] b = str.getBytes("GBK");
System.out.println(b.length);
printHex(b);
printOctet(b);//就加了这一行
str = new String(b, "UTF-8");
b = str.getBytes("UTF-8");
System.out.println(b.length);
printHex(b);
}
private static void printHex(byte[] b) {
StringBuilder sb = new StringBuilder();
for (byte t : b) {
sb.append(Integer.toHexString((t & 0xF0) >> 4).toUpperCase());
sb.append(Integer.toHexString(t & 0xF).toUpperCase()).append(" ");
}
System.out.println(sb.toString());
}
private static void printOctet(byte[] b) {
StringBuilder sb = new StringBuilder();
for (byte t : b) {
sb.append(String.format("%08d", Integer.parseInt(Integer.toBinaryString(t & 0xFF)))).append(" ");
}
System.out.println(sb.toString());
}
输出结果:
6
D6 D0 B9 FA C8 CB
11010110 11010000 10111001 11111010 11001000 11001011
14
EF BF BD D0 B9 EF BF BD EF BF BD EF BF BD
来看一下 str = new String(b, "UTF-8");
这一行到底干了什么事情?
原始的byte[]为:11010110 11010000 10111001 11111010 11001000 11001011
首先读取第一个字节,11010110,根据UTF-8 编码规则,因为110开头,编码器认为这是一个双字节的字,它会去取第二个字节,而且要求第二个字节必须是10开头。这时它发现错了,因为,他会用 "EF BF BD" 三个字节替换第一个字节,转成二进制,就是第二段字节流的:“11101111 10111111 10111101”。
"EF BF BD" 是什么?前文已经说过,就是一个标准占位符。
那么,第二个字节它已经拿出来了,根据规则,因为110开头,编码器还是当做一个双字节字处理,再取第三个字节,是10开头,符合规则,当做双字节处理,正常。因此,直接把 D0 B9 拼接到新的字节流里,现在新的字节流变成了:[EF BF BD] [D0 B9]
第四个字节,11111010 以111110 开头,编码器认为这是一个5字节编码的UTF-8字,后面至少需要4个后续字节,明显不够了。因此,再拼接一个 "EF BF BD" ,新的字节流变成了:[EF BF BD] [D0 B9] [EF BF BD]
依次处理第五、第六个字节,同样再次拼接了两个"EF BF BD" ,最终的字节流是:[EF BF BD] [D0 B9] [EF BF BD] [EF BF BD] [EF BF BD]
14个字节。
如果使用 jdk 1.6 和 1.7 来运行用例,结论不同了,最终是8个字节:
中国人
GBK-8 字节码长度:6
D6 D0 B9 FA C8 CB
******
EF BF BD D0 B9 EF BF BD
按照通常的经验,三个汉字的UTF-8长度,应该是9,然而不是。
UTF-8 字节码长度:8
从打印的日志来看,原字节码,前三个字节的分析没有问题。问题在于后面的三个字节,遇到错误的字节时,编码器直接用三位的占位符替换了错误的三个字节。
编码器的源码暂时没找到,先从表面上来看一下他们不同的编码规则的不同。
先看一个例子:
String str="中国86";
System.out.println(str);
byte[] b=str.getBytes("GBK");
str=new String(b,"UTF-8");
System.out.println(str);
输出结果:
比如用 “中国86" 来测试,java8,打印是这样的:
�й�86
而 java6、7打印是这样的:
�й�
如此看来,jdk6、7太暴力,发现一个异常字节,直接忽略后续2个字节,当做一个占位符,哪怕你后面两个字节 0x38 0x36 是可识别的ascii码。
因此jdk6、7的破坏性更强,java8的规则是优化了的结果,尽可能保留了有效数据,这也是unicode中占位符的初衷。
参见:https://en.wikipedia.org/wiki/Specials_(Unicode_block)#Replacement_character
Since the replacement is the same for all errors this makes it impossible to recover the original character.
先回顾一下前文的结论:
对于任意字节流,使用ISO-8859-1 转为字符串再转回来,是安全的;使用GBK和UTF-8可能会破坏数据。
现在扩展一下,使用GBK可能会破坏数据,损失最后一个字;如果使用UTF-8 可能损失大部分的字。
但这绝不是说UTF-8 是不好的,而是在这个乱码问题出现的时候,UTF-8是最惨烈的。实际上,UTF-8 尤其是动态长度的编码方案,无疑是最经济的。而且,4字节字符的出现,双字节编码方案,完全无法解决,唯UTF-8才是较好的选择(utf-8mb4)。
汉字unicode编码表:http://www.chi2ko.com/tool/CJK.htm
emoji编码表:
https://apps.timwhitlock.info/emoji/tables/unicode