前两天收到一个同事提交的一个疑难问题，在进行xml编码时，一些特殊的gbk编码汉字，会转换成乱码。当时大概的看了下，应该是编码转换的格式问题，怀疑为开源库的bug，给出一个简单的解决方案后就没有在关注。
当时给的是一个比较土的办法，让用了一下iconv函数，进行了一个二次转换，先有gbk转为utf8，然后在进行xml的transcode转换，最后再用iconv进行utf8转gbk，这样就可以保证那一个编码错误的可以正常输出。但是这个方法只对这一个（或部分）汉字进行验证，大规模的验证比较困难了。容易引起其他问题，当时只是应付的给出了这个建议。
后续空闲时继续跟进了一下这个问题，分析结果如下：
1、接收文件（消息）为GBK编码。
2、输出文件（消息）为GBK编码。
3、调用函数XMLString::transcode没有明确给出，编码类型的参数！！！
4、在初始化xml类时（二次开发的）默认输出为GBK编码默认的，输入编码程序中没有明确给出。
问题应该出在这里了。开扒Xerces的源码，版本从网上取了一份最新的。辗转找到底层编码转换部分，居然也有用到iconv的部分，嘿嘿。功夫部分有心人啊，终于找到可疑的地方了代码里面有 fLocalCP = getenv ("LANG"); 明显的是从环境变量里面取的值啊（因问题发生环境不同变量不同，本人用的是HP主机，不解释了）。查看主机变量果然啊是默认的LANG=C！！！ 使用locale -a |grep -i gb 找到系统已经安装好的gbk编码参数。配置到profile中。重新启动程序，测试编码错误的汉字，在程序没有任何改动下，一切OK！
总结：
1、在编码转换的过程中，两个必备条件from和to的编码类型是必须的，如果没有这两个参数的明确编码类型，需要小心了！
2、程序开发中需明确避免（或说明）此类依赖第三方参数，直接影响输出结果的地方。
3、使用开源或第三方的不熟悉代码进行二次开发的挖坑和埋雷更可怕啊。（一般此类文档还会比较少，理由貌似很充分的告诉，开源的网上好多，自己看吧~ 实际情况是给你一颗导弹，你却埋在了自家地里，当宝贝了）
阅读(3690) | 评论(0) | 转发(0) |
