05/07/08。 cathayan.org版权所有,保留一切权利。转载请保留此说明。谢绝商业转载。
阮一峰这篇Blog引用了一张互联网网页编码统计图,上面
显示UTF-8的比例正在迅猛上升,而欧美字母编码正在下降,显得比较乐观;但GB2312的比例变动很小,而且我国主流大站基本还是采用GB2312的编码,Unicode的前景又显得很不乐观。
其实中文网页增速应该是很快的,如果它快过全世界网页的平均增速的话,这个比例不变岂不已经说明使用UTF-8的还是在增加?Unicode确实有很多好处,本着不再将就、一了百了的方针,还是很应该采用的。
前些天换空间的时候,本站就转了一把,从GB到UTF-8,过程基本顺利,但也挺麻烦的,似乎还没有很稳妥的工具可用。原因在于这些字符虽然99%都是GB2312的,在那7000字的范围之内,但也有少数超出了这个范围,比如有一些怪字或繁体字。当然这里浏览器表现都很好,虽然不在GB2312范围内,它们也能处理和显示。但是不知道它是作为什么编码存储和处理的,这个问题在在转UTF-8时出现了。iconv这个工具要求说明从哪种编码到哪种编码,然后它似乎就只在这两个范围内转换,这样就老是出问题,总是在某字节处断掉。假装原来是GBK也不行,估计字符是相当怪或者碰到了iconv的能力极限。A core提醒说可以让它闭嘴只是干活,但我怀疑那样保留下来的编码可能还不是UTF-8(?)。
最后借用的是在这些问题上表现比较好的字处理器,实践表明,OpenOffice.org在这方面(直接打开备份的sql文件)比MS word 2003略微强那么一点,显示正确的比例比Word要大那么一点点。但它们也仍然没有完美显示所有字符,也出现了由于某个字符出问题,引起后面一串乱码,只好手工在Vim切换编码直到显示正常再拷贝过来。
总之,这些都是编码不统一造成的毛病,今后就一了百了了(希望吧)。但iconv这种编码转换工具显然还有改进的空间。除了习惯力量大,结构复杂尾大不掉之外,没有特别好的转换工具也许是造成许多大站不敢转向Unicode的一个小原因吧。当然,如果微软的产品缺省全部都转用Unicode的话,就一了百了了。
05/07/08 10:01:39,由
cathayan发表。目录:
电脑
10条评论
以前也经常碰到用iconv在某处断掉的时候,用gbk依然不行的情况,尝试用gb18030,大多数时候可以成功转换。
huisi 于 05/07/08 10:36:23 发表.
你看, 有些时候人们还是希望黑暗势力来做些有助于中土统一的事情啊
btsb 于 05/07/08 10:58:06 发表.
从Win2000起Windows内部已经彻底Unicode化,看到的传统编码如GBK其实是由c_936.nls等码表在内存里虚拟出来的。只是上层软件如记事本的默认编码仍是ANSI……
ec2049 于 05/07/08 14:31:05 发表.
GBK包括了BIG5里几乎所有的繁体字,还有全部日文字母。
而GB18030覆盖了Unicode里CJK区全部内容,连4字节的CJK扩展也包括在内,中日韩三国所有本地编码都可以转为GB18030不丢字。算是个中国大陆过渡方案,不过其他国家貌似打算直接转Unicode,没出这种东西。
另外还有不明原因尚未推广就销声匿迹的GB13000
http://www.google.cn/search...
据IRG前召集人说GB18030/GB13000间不兼容,由于GB13000莫名“失踪”,我没看过转码表,不太清楚。
ec2049 于 05/08/08 08:28:11 发表.
坊间传闻:GBK是微软强推的,不理会天朝的GB13000,也就是ISO10646,给老大一刀;老大一气,强推GB18030,不支持不许上市,又砍了微软一小刀。如果不是微软,天朝至少8年前就已经全面Unicode了。说起尾大不掉,微软尾巴最大了。
haha 于 05/08/08 09:04:39 发表.
用iconv来做gbk转utf8是有问题的,曾经在maillist看到是iconv的bug,有少数几段编码处理有问题。所以我通常都改用php的mbstring来做,很好用,完全没有问题,但就没有命令行的iconv方便啦
http://blog.i5un.com ck 于 05/24/08 15:30:35 发表.
I am watching and will delete all spam.