阮一峰这篇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的话，就一了百了了。