最近在修改一个使用Window 给FTP服务器上传中文路径的问题,头疼了很久。
从Windows读取到的字符在遇到中文个数为奇数的时候,路径会被部分识别为乱码。而中文个数为偶数个,则能正常识别出来。
以下是在网上看到某位大牛分析的原因,看了才知道,原来是java输出流搞的鬼。
引用:
最近被utf-8搞得各种头痛。差点就要练出肉眼看二进制编码的火眼金睛。先举个今天遇到的小问题吧。
java用gbk方式写入的文件,似乎有个特性,是会自动把gbk编码中不能识别的0×0这个字节,替换成”?”,也即0x3F。这原本也没什么,但当他读取utf8文本并重新写入新的文件的时候,就会出现偏差。
众所周知,utf8编码的英文和符号部分是同ASCII编码兼容的。同时,在大多数中文中,很少出现0×0这样的字节。因此,用ASCII硬写utf8编码的中英混合文字,然后这个文件再用utf8的方式打开,运气好的话居然可以侥幸蒙混过关,毫无错误。然而,一旦文字中出现了带有0×0字节的utf8编码,就没那么侥幸了。
例如“个性”的性字,其unicode编码为0×6027, 翻译成utf8的话:
性
60 27
01100000 00100111
[1110]0110 [10]000000 [10]100111
E6 80 A7
这里用方括号标识了utf8的字节头,方便辨识。在windows上是使用小端序,所以实际的序列会是这样:
0110 1110 0000 1000 0111 1010
这里第三个字节出现了0×0,悲剧发生了,被java的流输出不知怎么就那么智能替换成了”?”
0110 1110 1111 0011 ...
6 E F 3
结果这里就乱码了。打出来内容一团糟。变成“个?”。
另外一个曾让我头疼一天的问题,就是根据utf8编码规则,并不会出现0xC0 0×80这个双字。因为如果按照编码规范
0xC0 0x80
[110]0 0000 [10]00 0000
0000 0000
这根本就是0×0嘛!不可能编码成这个样子的。wiki上查了半天才发现,原来这个又是windows的专有解决方案。完全是windows系统一厢情愿,想要区别于一般的ASCII文本而作的别扭事。结果这样的文本想要插入到mysql数据库时,就会被数据库认为是不合理的utf8编码而被冷冷拒绝! 所以整理utf8的编码问题,有时候还是要一直看到二进制上面来,这样问题发生在哪里也就会比较清楚,该怎样解决就不再像是霰弹枪编程,左试右试都不知道哪里出错了哟。