标签:io sp on 文件 问题 bs 代码 ad nbsp
最近在搞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等编码格式来显示,对于拷贝进去的字符串,看你当前选择了什么格式,你选择了什么格式,拷贝进去的字符串就会当作那个编码格式下的来处理。
擦,都得又乱了,虽然原本也没清楚。。苦逼
标签:io sp on 文件 问题 bs 代码 ad nbsp
原文地址:http://www.cnblogs.com/zouzf/p/4154569.html