最近在搞XML解析优化，公司引擎用了tinyxml1和tinyxml2两个XML库，后者的效率比前者高60%吧，tinyxml1解析大文件是很慢的，可以淘汰了，tinyxml2还勉强，快的话还得算pugixml或者rapidxml吧。
奈何一些引擎代码根深蒂固，无法更换为pugixml，只能局部修改一下tinyxml库的源代码企图优化一下
今天在优化的时候碰到一个坑，就是解析出错的时候，XML库是如何处理的，比如某个节点有两个同名的属性，以下是各XML库的处理：
tinyxml1：按XML文本的顺序解析，在解析到同名属性的时候，停止解析，返回已经解析好了的那部分，并且在document对象里的 errorLocation.row 和 errorLocation.col 表明出错的位置（行和列）
tinyxml2：貌似是递归解析，碰到同名属性时，一下子全蹦了，返回的document啥子都没有，在document对象里的 _errorStr1 里存储了那个同名的属性的名字， _errorStr2 指向那个同名属性后的位置。其实不是很好分辨
pugixml：非常高效，所以没看懂是如何解析的。在给element添加属性时应该是没有见检查是否存在同名属性，能正常解析完的，最后断点观察那两个同名属性都被加进了element的
今天被坑在，某个XML文件某个节点有属性同名了，但引擎库是用了tinyxml1来解析的，所以返回的document的全半部分是正常的，而我是用tinyxml2来测试的优化代码的，发现~~~被坑大了，各种检查自己写的优化的代码~~~
刚好还发现那个XML文件里有中文，搞得又怀疑是编码的问题，顺便又恶补了一下编码的基础知识，顺便用了用比较了一下 sublime text、notepad++、UltraEdit~~~发现UltraEdit是用Unicode编码来显示的，对于黏贴进去的字符串会当成是Unicode编码格式下的来处理；sublime text 可以用utf8、大头小头Unicode-16、16进制等编码格式来显示，对于拷贝进去的字符串，会被当做是utf8编码格式下的来处理；notePad++ 可以用 ansi、utf8等编码格式来显示，对于拷贝进去的字符串，看你当前选择了什么格式，你选择了什么格式，拷贝进去的字符串就会当作那个编码格式下的来处理。
擦，都得又乱了，虽然原本也没清楚。。苦逼