再谈java乱码：GBK和UTF-8互转尾部乱码问题分析

一直以为java中任意unicode字符串可以使用任意字符集转为byte[]再转回来只要不抛出异常就不会丢失数据事实证明这是错的。

经过这个实例也明白了为什么 getBytes()需要捕获异常虽然有时候它也没有捕获到异常。

言归正传先看一个实例。

设想一个场景

用户A有一个UTF-8编码的字节流通过一个接口传递给用户B

用户B并不知道是什么字符集他用ISO-8859-1来接收保存

在一定的处理流程处理后把这个字节流交给用户C或者交还给用户A他们都知道这是UTF-8他们解码得到的数据不会丢失。

下面代码验证

输出

重复前面的流程将ISO-8859-1 用GBK替换。

只把中间一段改掉

运行结果

好像没有问题这就是一个误区。

将两个汉字 “用户” 修改为三个汉字 “用户名” 重新测试。

ISO-8859-1测试结果

GBK 测试结果

ISO-8859-1 可以作为中间编码不会导致数据丢失

GBK 如果汉字数量为偶数不会丢失数据如果汉字数量为奇数必定会丢失数据。

why

重新封装一下前面的逻辑写一段代码来分析

输出结果

前三段都没问题最后一段奇数个汉字的utf-8字节流转成GBK字符串再转回来前面一切正常最后一个字节变成了 “0x3f”即”?”

我们使用”用户名” 三个字来分析它的UTF-8 的字节流为

[e7 94 a8] [e6 88 b7] [e5 90 8d]

我们按照三个字节一组分组他被用户A当做一个整体交给用户B。

用户B由于不知道是什么字符集他当做GBK处理因为GBK是双字节编码如下按照两两一组进行分组

[e7 94] [a8 e6] [88 b7] [e5 90] [8d ]

不够了怎么办它把 0x8d当做一个未知字符用一个半角Ascii字符的 “” 代替变成了

[e7 94] [a8 e6] [88 b7] [e5 90] 3f

数据被破坏了。

因为 ISO-8859-1 是单字节编码因此它的分组方案是

[e7] [94] [a8] [e6] [88] [b7] [e5] [90] [8d]

因此中间不做任何操作交回个用户A的时候数据没有变化。

因为UTF-16 区分大小端严格讲unicode==UTF16BE。

其中 “fe ff” 为大端消息头同理小端消息头为 “ff fe”。

作为中间转存方案ISO-8859-1 是安全的。

UTF-8 字节流用GBK字符集中转是不安全的反过来也是同样的道理。

getBytes() 是会丢失数据的操作而且不一定会抛异常。

unicode是安全的因为他是java使用的标准类型跨平台无差异。