有趣的编码问题
三只小熊的编码问题
本段是很多年前在 CSDN 上回复过一个很有意思的帖子,帖子楼主问:
String input = new String(x.getBytes("utf-8"),"gbk");
已知 input 的值为“三只小熊”,求变量 x 的值是什么?
如果限定 input 的值为“三只小熊”的话,那该问题无解。
首先“三只小熊”的 GBK 编码为:C8FD D6BB D0A1 D0DC
,拆成字节为:C8 FD D6 BB D0 A1 D0 DC
根据 Unicode 与 UTF-8 编码转换规则:
Unicode Code UTF-8 Code
0000~007F 0xxxxxxx
0080~07FF 110xxxxx 10xxxxxx
0800~FFFF 1110xxxx 10xxxxxx 10xxxxxx
10000~10FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
先从第一个字节 C8
开始看,C8
只能匹配第二行的转换,也就是采用两个字节,这时第一个字节匹配成功,再匹配后一个字节 FD
,规范要求的第二个字节是 10xxxxxx
因此 C8 FD
转换失败,C8
这时采用 UTF-8 的占位字符 EF BF BD
即 Unicode 的 U+FFFD
来替换,在我们的平台上显示为 �ֻ
了。
关于 U+FFFD
,Unicode 的描述是:
Replacement Character. A character used as a substitute for an uninterpretable character from another encoding. The Unicode Standard uses U+FFFD replacement character for this function.
“占位字符”,该字符用于替换一个无法从其他编码转换解析的字符。Unicode 标准使用U+FFFD
占位字符用于该情况。
同理 FD
以及最后两个 D0 DC
也都不能进行转换,都被 EF BF BD
所替代。
其中的 D6 BB
和 D0 A1
可以转换。
D6 BB
二进制数据为 11010110 10111011
正好能匹配 UTF-8 的双字节,去掉附加位为 10110 111011
再将其四位一组分开,即 0101 1011 1011
这个也就是 Unicode 字符的 U+05BB
编码。
同理,D0 A1
可以转成 Unicode 字符的 U+0421
。
由于 U+05BB
是一个希伯莱文附加符号 ֻ
(http://www.unicode.org/charts/PDF/U0590.pdf)在 GBK 平台上没办法显示出来,因此根据系统规范也可能显示成为 �ֻ
(可能有些机器能够正常显示),U+0421
是个西里尔字母 С
(http://www.unicode.org/charts/PDF/U0400.pdf),而 U+FFFD
则全部显示为 �ֻ
。
由于 C8FD D6BB D0A1 D0DC
在 UTF-8 编码中并没有完全对应的字符,因此“三只小熊”的这个问题无解!
锟斤拷
“锟斤拷”的出现主要是两次编码转换错误,存在于偶数个 GBK 字符转为 UTF-8 后,再由 UTF-8 转为 GBK 导致的。
根据上一节的原因,GBK 转为 UTF-8 字符时,由于有一些 GBK 编码的字符无法使用 UTF-8 来表示,因此会使用占位字符 EF BF BD
来表示,如果 有两个 GBK 的字符无法使用 UTF-8 来转换,那么就会产生 EF BF BD EF BF BD
。此后这两个 UTF-8 的字符编码又转成 GBK 了,转换成 GBK 后的字符为 EFBF BDEF BFBD
,根据 GBK 编码表可知这三个字符为“锟斤拷”。