过渡到 UTF-8 时的问题

2006-04-29 00:39:12转载

看了一篇《[url=http://www.uuzone.com/blog/mao/98921.htm]转UTF-8编码的启发[/url]》，这叫一个着急

1.批量转码，写个PHP 脚本用 iconv 库转，20 行就可以了（有 10 行是为了打扮输出界面），绝对比又找软件又下载的利索。而且来源文件的规则自己可以很灵活的定。

2.几乎所有语言都对文件 BOM 头的处理有问题，昨天我还在跟一个新来的实习生解释为什么他的 PHP 脚本任务在命令行下会有两个奇怪字符。但问题是，完全可以控制一个 UTF-8 文件不要产生 BOM，起码我所知道的 ue、edit+ 都如此

3.参阅车东《[url=http://chedong.com/tech/unicode_java.html]从汉化到国际化——UniCode inside, Localization outsite[/url]》一文中的粗体字“输入和存储阶段就用UniCode方式进行处理和存储，以方便应用以后的国际化”

4.“不幸的是，遇到了太多的项目，太多的人，他们宁可 copy paste 大量代码，花很多时间去 debug，费九牛二虎之力，把boss在心中诅咒１００遍，用不正确的方法去做事，最终的结果可想而知。”——说句不好听的，难道老冒同学一直是只用应届毕业生吗 =,=

[hr]

5.目前做的公司的一个网站运行了快一年了，我曾经说，如果让我重新选，我会选 charset=GB2312（实际是 GBK）。由于数据库用的是一个，你不可能让两个子域名用的是不同编码，这样就要求你所有的 Web 程序员都很了解处理编码问题的方法，包括美工也要知道怎么在 dreamwaver 里设置，让有使用 Zend Studio 的人换编辑器、因为那个狗屁 IDE 不支持 UTF-8，并且，基本不要有什么合作站点之类的，因为其他站点都是 GB2312 的，你要给他点什么自己网站的内容（比方说一个供对方程序读取的 csv 接口），那你同样要负责转码问题。更多的详细问题不一一列举。总之，各种琐碎的细节带来的成本（主要是时间成本）相比 UTF-8 可能带来的好处……太不值一提了。

l18n？有几个网站需要国际化？理性的说，把一个 GBK 的网站一次性转换成 UTF-8 所需要成本远小于在没有必要用 UTF-8 前提下运行几年所产生的额外成本。

我现在总结的规则是随大流，如果所有网站全是 unicode、所有程序员刚开始写程序的时候用的就是 unicode，如果所有操作系统和编辑器也都用 unicode，那这个世界就好多了，但这是未来的事情。

如果你是个观众，还是个有品位的观众，你可能会喜欢一些实验电影，可如果你是华纳的老板，你肯定喜欢卖一部老少咸宜的商业片。