UCS-2与UTF8之间的选择（5）--断然决定UTF-8
write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie
想来想去，在Unicode这种问题上纠缠过多似乎意义不大，就如我以前说的，我认为将来很自然的不会再需要考虑这个问题，因为，未来总会统一到UTF-32上去，那时候我现在考虑的这些东西都是完全没有意义-_-!在一个不久的将来就会完全没有意义的事情上考虑来考虑去似乎太没有抓住主要问题......
最后我的决定是使用UTF-8，这是个背Windows的选择，但是是个亲开源的选择，亲近世界的选择......即便到了现在，世界上还是有很多程序员不使用Unicode,即便是在Windows下编程。
举个让人信服的例子就是breakpad（google-breakpad - Google Code），这个程序对错误的处理技术可谓手段用尽，为了在程序出错下不破坏现场的手段现在还感叹精巧，不能说开发人员没有水平，但是，在Unicode模式下编译就会有严重的问题（我去年刚开始的第一个工作就是这个，现在不知道修复了没有）。只能感叹英语的强势，无论是在文化领域还是在编程领域都是一样。。。。。对于更多的开源项目，可以想象情况怎么样。。。。。
另外，即便是一般的开源项目考虑了国际化，选择了Unicode来进行开发，一般而言，就目前的情况来看，似乎也是UTF-8居多，因为以前谈到的那么多的UTF-8的优点，其中最最符合欧美人习惯的一点就是完全兼容ASCII。。。。作为以自己语言开发的项目，移植到UTF-8一般而言比移植到UCS-2要更加方便，再加上开源世界的主导GNU/Linux的核心Linux的核心（好像有点绕）就是UTF-8的，所以，开源软件一般使用UTF-8也就很好理解了。就个人的开发学习而言，肯定会用到很多开源软件，或者参考，或者直接复用，当我的开发也是以UTF-8为基础的话，可以省事很多。举个简单的例子就是，CEGUI就是UTF-8的，这点我甚至看到Windows下的开发人员骂过，但是，这就是世界的现实。另外，就我使用的经验而言，MySQL也是对UTF-8的支持更加好，虽然其支持UCS-2编码的字符串，但是在命令行控制时无法正确显示，MySQL的著名前端工具,PhpAdmin也是对UTF-8支持良好，一样也无法显示UCS-2编码的字符串。（这些都是基于以前工作中的经验，现在不一定准确）作为个人开发。。。。我好像最可能使用的数据库也就是MySQL了。。。SQL Server我用过，的确是对UCS-2支持的更好，但是即便实在要用，还是可以现转成UCS-2的。Oracle没有用过，我不做评论。
另外，本人在公司常常是在VS2005下做Windows的开发，虽然也有Linux的工作，但是一般都仅仅是将Windows下开发好的服务器移植到Linux下的工作，其实对Linux下的学习不够深入，对Linux下的服务器开发学习也不够深入，而且以前说过，公司为了更加满足Windows下的客户端的要求，所以公司都是使用UCS-2作为编码，即便是Linux下的服务器都是强制使用了2字节的wchar_t来适应这种选择，也逼迫公司需要重编译所有其想要在Linux下使用的库。。。因为也需要这些库使用2字节的wchar_t，其实代价也挺大的。。。。而且作为学习，要是老是和工作中做一样的事情又怎么能更多的学到新东西呢，又何谓工作外的学习。。。。。再加上目前个人对Linux有很大的兴趣，希望多学点东西，这也是原因之一，虽然我的目标是可移植，但是感觉以后可能还是以在Linux下跑服务器为主，那么简化Linux下的开发，并优化速度，也算是理由之一吧。
再说，习惯了VS的我一直希望能将自己搬迁到Eclipse这样的多功能开放平台上，（虽然VS好像也可以作为开放式平台，但是相对来说插件的选择和质量实在和Eclipse不是一个量级的），虽然我目前没有学习JAVA,但是Eclipse也是我感觉非常合适的开发平台，不仅仅当我想使用C时，使用C++时，当我想使用Python,Lua时，这一样也是个很好的平台，而且，最重要的是，Linux下也能使用，在Linux下还能用其来开发bash脚本:)这一点是VS怎么也不可能达到的。。。。（我不期望MS将来开发Linux下的VS），另外，Eclipse对UTF-8的支持很好，而且也有vi的插件可用（Eclipse下的vi插件没有VS下的这么强大，支持的功能比较弱。。。这点比较遗憾。。。。），何况，假如哪天我希望学习JAVA。。。那么连IDE学习的时间都省了。。。。对于开发工具。。。实在可以有很多话说，越是学的语言更多，越是觉得为每一种语言去学习一个开发平台是不值得的，假如有一个比较统一的平台，那样可以节省很多时间，目前来说，最最能够胜任这个目标的就是Eclipse了，感谢IBM。。。。。目前我的暂时替代品就是VIM...文本编辑之王，写任何程序都感觉非常爽，就是配置起来有点麻烦，除了编辑以外的事情处理起来效率稍微低了点，调试更是弱项。。。。虽然其一向贯彻着一个程序只做好一件事情的原则，让其编辑能力无可匹敌（真的好用），但是当我需要更多丰富功能的时候。。。。实在有点麻烦。。。呵呵，我前段时间学习的时候，基本都是用vim编辑，用gdb/pydb/bashdb调试(没有找到好用的LUA调试工具，这也是我最近很少用LUA的原因，甚至Eclipse的LUA开发插件都不支持调试-_-!)对了，还有汇编，VS2005即便加上VA,汇编程序的开发也没有任何帮助。。。。这在我前段时间学习反汇编和内嵌汇编的时候感受很深，希望Eclipse不也要这样。。。。呵呵，也许额外还要多说一下Eclipse的是，多多使用GCC对于简化移植会有更多帮助，唯一的麻烦可能就是很多人可能会排斥不能用VS编译的程序-_-!这就是MS垄断的影响力所在。
似乎好像谈多了Linux就自然会讲到很多MS的坏话-_-!这几乎成了Linux社团的特点。。。。其实我并不讨厌Windows,用某人的话来说，即便某天Windows不再垄断，仅仅占有30%的市场份额，为Windows做开发的程序员仍然有广阔的空间。。。。何况现在呢-_-!我仅仅是刚开始学编程，希望多接触到一些思想，另外为了学习编程，需要看更多好的优秀的程序，而那些开源的优秀的程序往往是运行在Linux下的，Windows下的优秀程序虽然很多，但是苦于人家不让我看源码啊。。。。-_-!
唯一还需要看的问题是Python的支持，要是Python仅仅支持UCS-2，那么我还是会改变我的决定。可惜：）Python的默认Unicode实现就是UTF-8编码的，更为强大的是，Python的正则表达式库还对其UTF-8有直接支持，太强大了，这一直被视为UTF-8编码的弱项，那么，还缺少什么？万事俱备，连东风都不欠了。
对了，作为我关注的语言之一，LUA直到5.1版本都没有对Unicode有直接的支持。。。这点比较遗憾。至于Bash...我要他支持Unicode干什么-_-!
当仅在windows来进行编码转换时，就可以利用Windows的编码转换API，WideCharToMultiByte和MultiByteToWideChar函数对，还算是比较好用，起码比Unicode组织提供的好用的多。其实还有C 运行库mbtowc, wctomb可以用，这两个函数在Linux下也有实现。那么，以后就不在这个问题上再进行更多的纠缠了，UTF-8吧：）
write by 九天雁翎(JTianLing) -- blog.csdn.net/vagrxie