如果选用utf8编码的系统在linux上面开发，xml类库采用libxml，那么不说也罢，一切都显得顺气自然。尤其libxml在xml处理效率方面的良好表现自然成了首选。
但如果系统架构编码支持已开始就选定了gb2312，那么噩耗将会接踵而来。当然所谓的噩耗，并非说libxml就不能解析gb2312编码的xml数据。其实无论采用linux系统函数iconv或者libxml的系统自带函数都可以正常读入gb2312编码的xml数据，唯一的区别就是使用编码转化带来的效率问题以及其他问题。尤其是通信服务端解析来自客户端的xml数据，在高并发的情况下，往往并非select,poll,epoll的关键字会如何造成数据处理的堆积，很大程度上取决于后台业务处理的效率。xml数据编码转化甚至如同蝴蝶效应一样可能给整个系统带来效率和稳定性上的损耗。
好在libxml通过不停的完善之后，已经能够支持gb2312编码的xml数据输入处理了，但是却又给大家开了一个天大的玩笑。似乎libxml解析xml后的结果，输出依然是utf8等类库内核编码。呵呵，这就如同某个男人进了一间黑屋子穿了一件帅气的衣服出来后却变成了女的。还是又不得不用iconv来进行处理。
呵呵，苦笑，本想去编译libxml源码，后来发现其内核编码支持的非常有限，apache组织的xml解析库也存在libxml的问题，无奈之下，选择了小巧灵活的tinyxml。编码也简单多了，至少少了许多libxml惊心动魄的内存管理，唯一的付出，就是需要一些算法进行xml的特出的业务处理。
无奈，这个世界就这样，没有完美的东西。