我决定用icu换掉iconv
基于如下几点理由,我决定用icu换掉iconv1、跨平台gnu iconv 1.13在它的README中写到:“Building requires the mingw or cygwin development environment (includes gcc).MS Visual C/C++ with "nmake" is no longer supported.”既然它这么傲慢的抛弃了vc,那我也只有放弃它。icu支持所有我常用的平台:win/linux/freebsd/solaris2、版权gnu iconv也顺应潮流的采用了GPLv3,这个令BSD和GNU之间陷入无限争吵的东西。而icu采用的是一个类似于bsd的版权协议,更加开放自由。另外,icu还有如下几点好处:3、易于上手大部分vc程序员都是采用宽字符(utf16)编译、链接,而java用户更是没有选择的采用了utf16be。相对用过vc和java的人,icu的字符处理方式非常容易上手,况且,设计jdk/unicode的人和icu是同一拨人。4、文档详尽IBM作为一家大型的软件服务公司,写文档的能力真不是盖的。5、有IBM做强力支持所以,任何一个版本的发布都有严格的商业化测试。并且,比较贴近市场需求。比如,ibm需要在中国出售它的产品,而icu就是它唯一的法宝。中国政府要求在中国出售的软件必须支持gb18030,于是icu每个版本的变化都紧跟着gb18030的发展。6、有简洁的C++/java的接口我向以前的同事推荐iconv的时候,他们都在说使用起来太复杂。其实接口已经不能再简化了,一共也就open/close/iconv三个函数。可是对于C++程序员而言,巴望不得就像glib::ustring那样,完全仿照std::string那样让他用就好了,转码也就像java的String.getBytes(“gbk”)那么简单最好。7、容易和现有的项目整合发布数据都在dll里面,把用到的dll打包发出去即可。8、有高层的io/regex支持基于unicode的正则表达式支持,以及仿照stdio的基于unicode的io。我对前面这个很感兴趣,后面这个……貌似还是个比较粗燥的咚咚,另外,io实在是个太广义的东西,还是不要它来帮我抽象了吧