我决定用icu换掉iconv

基于如下几点理由,我决定用icu换掉iconv

1、跨平台

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/solaris

2、版权

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实在是个太广义的东西,还是不要它来帮我抽象了吧

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥