简介一份面向 Visual C 开发者的 XML 解析与读写原生源码包强调无需安装任何第三方库即可编译运行特别适合希望深入理解 XML 底层解析机制、愿意脱离框架依赖的 C/C 学习者也适合需要在轻量级工程中快速集成 XML 读写能力的开发者参考。压缩包共 18 个文件、约 46KB涵盖 7 个 C 源文件、5 个头文件、3 个 XML 样例文件同时附有解决方案、项目工程配置与文本说明文档源码、工程骨架与样本数据相互配套可直接编译运行验证。已有 189 人浏览学习。内容围绕 DOM 节点遍历、属性读取、元素创建与追加、文本转义、序列化输出以及格式校验等 XML 处理完整流程展开配合示例数据便于实际跑通并观察读写结果。整体体积小、模块边界清晰既可作为原生 XML 编程的入门模板也能在此基础上快速改造为轻量级数据交换组件。1. 不装三方库Visual C读写XML到底靠什么很多人一听到“Visual C读写XML”第一反应是去找TinyXML、Xerces-C或者NuGet上拉一个包其实Windows系统目录里早就躺着一个能跑十几年的原生解析器——MSXML。它在系统里以COM组件形式存在从VC 6.0时代就有到现在的Visual Studio 2022都不需要额外安装三方库也不存在Redistributable缺失的问题直接调COM接口就能完成解析和序列化。这篇笔记就围绕“纯原生源代码”这个思路讲清楚怎么用MSXML在VC项目里读写XML以及不想依赖第三方库时哪些坑值得提前避开。适合那些需要快速集成、交付环境不能随意装运行时、或者被三方库许可证折腾过的开发者。2. 用MSXML实现XML读取从加载DOM到遍历节点的完整代码2.1 为什么选MSXML而不是自己写解析器在开始写代码之前先回答一个最容易被问的问题既然标题强调“纯原生源代码”为什么不干脆自己写一个解析器我见过不少同事用fgetc加状态机去啃XML最后都在换行折叠、CDATA和实体转义上撞墙。一个合法的XML里可以出现![CDATA[not-tag]]这样的整段文本也可以出现#x4E2D;这样的数字字符引用自己的状态机很难把所有情况覆盖完而且一旦遇到非UTF-8编码的输入往往连第一个?xml声明都读不对。MSXML是Windows操作系统自带的COM组件从Windows 2000之后的系统里都有它不了解它的人总觉得这是“又引入一个依赖”其实它本来就系统级存在。Visual C项目里用#import指令就能引用它的类型库不需要下载任何SDK包也不需要在目标机器上装运行时这正好符合“不装三方库”的约束。更重要的是它原生支持XPath能用一句selectSingleNode定位到几十层深的节点这是手写解析器短期内赶不上的能力。选型上我一般分两步如果项目只需要读取、修改、另存XML且文件在几十MB以内DOM最合适API简单、修改方便如果文件超过百MB或者要求边读边丢弃已经处理过的节点再上SAX流式解析。下面的代码主要围绕DOM展开因为这是日常最高频的场景。2.2 初始化COM与加载XML文件的最小代码先写一个最基础的加载函数。这里用#import msxml6.dll生成智能指针代码看起来干净也不用到处写Release。#include windows.h #include comdef.h #import msxml6.dll using namespace MSXML2; bool LoadXmlFile(const wchar_t* filePath, IXMLDOMDocumentPtr doc) { HRESULT hr doc.CreateInstance(__uuidof(DOMDocument60)); if (FAILED(hr)) { printf(CreateInstance failed: 0x%08X\n, hr); return false; } doc-async VARIANT_FALSE; VARIANT_BOOL ok doc-load(_variant_t(filePath)); if (ok ! VARIANT_TRUE) { IXMLDOMParseErrorPtr err doc-parseError; printf(load failed: code%ld line%ld pos%ld reason%ls\n, err-errorCode, err-line, err-linepos, (wchar_t*)(_bstr_t)err-reason); return false; } return true; }CreateInstance(__uuidof(DOMDocument60))创建的是MSXML6.0的DOMDocument对象。__uuidof从#import生成的头文件里拿到CLSID运行时会向COM注册表查询并创建实例。如果你用的是VC 6.0或者目标系统很老可以把msxml6.dll改成msxml3.dll并把DOMDocument60改成DOMDocument30其余代码几乎一致。async必须设为FALSE否则load可能立即返回而解析还在后台进行下一个语句就开始访问空文档。doc-load()接收的是_variant_t这里传入文件路径。它内部会根据文件头BOM和XML声明自动识别编码所以UTF-8、UTF-16、GB2312都能正确处理。返回的VARIANT_BOOL为TRUE才表示解析成功。失败时从parseError里拿错误码、行号和原因这个信息后面调试会一直用到。调用前务必初始化COM线程模型int main() { CoInitialize(NULL); // 每个使用COM的线程都要调用 IXMLDOMDocumentPtr doc; if (LoadXmlFile(Ltest.xml, doc)) { printf(loaded OK\n); } CoUninitialize(); return 0; }CoInitialize(NULL)默认把当前线程设为单线程单元STA。如果是在工作线程里解析建议改用CoInitializeEx(NULL, COINIT_MULTITHREADED)并且别忘了在函数末尾CoUninitialize()。这个初始化很容易漏漏掉后CreateInstance会返回REGDB_E_CLASSNOTREG让你误以为是MSXML没装好其实是COM没启动。2.3 遍历节点、读取属性与文本的写法加载成功只是第一步更常用的是把整棵树扫一遍。下面这个递归函数会打印每个元素、属性和文本节点代码里用的都是DOM标准属性不依赖具体文件名。void WalkNode(IXMLDOMNodePtr node, int depth) { if (!node) return; if (node-nodeType NODE_ELEMENT) { _bstr_t name node-nodeName; for (int i 0; i depth; i) wprintf(L ); wprintf(L%ls\n, (wchar_t*)name); IXMLDOMNamedNodeMapPtr attrs node-attributes; if (attrs ! NULL) { for (long i 0; i attrs-length; i) { IXMLDOMNodePtr attr attrs-item(i); _variant_t v attr-nodeValue; v.ChangeType(VT_BSTR); _bstr_t attrVal v.bstrVal; for (int j 0; j depth 1; j) wprintf(L ); wprintf(Lattr: %ls %ls\n, (wchar_t*)(_bstr_t)attr-nodeName, (wchar_t*)attrVal); } } IXMLDOMNodeListPtr children node-childNodes; for (long i 0; i children-length; i) { WalkNode(children-item(i), depth 1); } } else if (node-nodeType NODE_TEXT) { _variant_t v node-nodeValue; v.ChangeType(VT_BSTR); _bstr_t text v.bstrVal; if (text.length() 0) { for (int i 0; i depth; i) wprintf(L ); wprintf(Ltext: %ls\n, (wchar_t*)text); } } }判断nodeType是最稳妥的方式因为文本节点的nodeName返回的是#text直接拿名称过滤会漏掉空白节点。attributes只对元素节点有效但这里已经用NODE_ELEMENT保护了。属性节点的值是_variant_t不能直接交给_bstr_t先ChangeType(VT_BSTR)再取bstrVal否则在64位编译下可能读取到错误的偏移量。这个细节我建议直接固化到自己的代码模板里省得每次踩一遍。如果你只需要某一层的节点不需要递归可以用childNodes配合item(i)来遍历。要注意MSXML里的IXMLDOMNodeList下标从0开始和C的习惯一致。2.4 常用查询接口selectNodes与XPath以前我手写查找函数时每次都要递归判断节点名后来发现MSXML自带XPath一句就能取代几十行循环。void QueryItems(IXMLDOMDocumentPtr doc) { IXMLDOMNodeListPtr list doc-selectNodes(_bstr_t(L//item[enabled1]/name)); for (long i 0; i list-length; i) { IXMLDOMNodePtr nameNode list-item(i); _bstr_t nodeText nameNode-text; wprintf(Lname: %ls\n, (wchar_t*)nodeText); } }这里//item表示任意深度下的item节点[enabled1]是属性过滤/name取子节点。selectNodes返回的是所有匹配节点组成的集合selectSingleNode只返回第一个。如果你的XML里带了命名空间比如根节点写了xmlnshttp://example.com/ns直接写//item会查不到任何内容。这时候需要先设置selectionNamespacesdoc-setProperty(_bstr_t(LSelectionNamespaces), _variant_t(Lxmlns:nshttp://example.com/ns)); // 然后用带前缀的XPath IXMLDOMNodePtr node doc-selectSingleNode(_bstr_t(L//ns:item[ns:id1001]));setProperty必须在执行查询之前调用命名空间前缀随便起只要映射到正确的URI就行。MSXML对XPath的大小写是敏感的Item和item是两个不同的路径属性名也区分大小写这个和在浏览器里写XPath的习惯不太一样我在第一次用老生成的数据时吃过亏。3. 原生写XML构建节点、序列化到文件的三条路径3.1 创建DOMDocument并构建根节点读会了就得会写。很多项目里“写XML”不是把一段字符串直接丢进文件而是要修改配置然后保存回去。用DOM创建文档和节点的顺序有讲究先建文档再建声明最后建根元素。IXMLDOMDocumentPtr doc; doc.CreateInstance(__uuidof(DOMDocument60)); IXMLDOMNodePtr decl doc-createProcessingInstruction( _bstr_t(Lxml), _bstr_t(Lversion\1.0\ encoding\UTF-8\)); doc-appendChild(decl); IXMLDOMElementPtr root doc-createElement(_bstr_t(Lconfig)); doc-appendChild(root); IXMLDOMElementPtr item doc-createElement(_bstr_t(Litem)); item-setAttribute(_bstr_t(Lid), _variant_t(1001)); root-appendChild(item);createProcessingInstruction的第一个参数固定是xml第二个参数是声明字符串注意这里的引号要写成转义后的\。声明节点必须通过appendChild挂在文档节点下而且位置必须是第一个否则输出文件不符合“先声明后根元素”的规范。createElement只能创建没有父节点的元素最后用root-appendChild(item)把它挂到根下。DOM的好处是孩子顺序完全由append的顺序决定不用手动维护标签闭合。这段代码里我没有手动拼config之类的字符串原因是MSXML会自动做转义。手动拼容易漏掉和后面解析时会报“无效字符”之类的错误排查半天才发现是数据本身带了特殊符号。3.2 添加子节点、属性、文本的API顺序给元素添加文本有两种做法它们的副作用不一样许多教程没提过这个区别。// 方式一创建文本节点后追加适合混合内容 IXMLDOMTextPtr text doc-createTextNode(_bstr_t(L单价100)); item-appendChild(text); // 方式二直接设置text属性会替换该元素下所有子节点 item-Puttext(_bstr_t(L替换后的内容));方式一借助createTextNode文本里的会被序列化成lt;读回来时又是原始字符这个过程MSXML自动完成。方式二Puttext是快捷方法适合只保留纯文本的叶子节点。如果元素下面已经有子元素先用Puttext会把它们全冲掉所以要在没有其他子节点时使用。需要同时设置多个子节点或文本节点时老老实实用appendChild按顺序加。添加属性时要注意setAttribute的第二个参数是VARIANT你可以传整数、字符串、布尔值。传字符串时必须包成_bstr_t否则编译器会把它当成const wchar_t*之外的类型导致匹配到错误的重载。写成item-setAttribute(_bstr_t(Lid), _variant_t(1001))大家都能看懂但如果传的是宽字符串最好写成item-setAttribute(_bstr_t(Lname), _variant_t(_bstr_t(Ldemo)))避免隐式转换的意外。3.3 保存到文件的编码选择UTF-8与GB2312保存是写XML最直接的成败点。我遇到过很多次代码里怎么写的都对保存完中文全变问号最后发现是XML声明编码和文件实际存储编码不一致。HRESULT hr doc-save(_variant_t(Loutput.xml)); if (FAILED(hr)) { printf(save failed: 0x%08X\n, hr); }save到文件路径时MSXML会读取文档里XML声明中的encoding属性并按这个编码去写文件。所以只要在createProcessingInstruction里写了encodingUTF-8保存出来的就是UTF-8。如果你写的是encodingGB2312它会用系统代码页转成GB2312。没有声明时MSXML会按系统默认ANSI代码页处理在简体中文系统上可能是GBK一旦换到英文系统保存中文就乱了。注意save到文件时会根据XML声明写编码所以创建文档时就要把encoding写对。还有一个容易被忽略的点doc-xml属性返回的是UTF-16字符串。如果你在调试时把它直接写进一个ANSI文件中文内容会变成类似“浣犲ソ”的乱码。所以不要拿xml属性绕过save自己去写文件除非你明确知道自己在做编码转换。save方法自己处理编码是性价比最高的做法。3.4 流式写入SAXXMLWriter与手动拼字符串的取舍DOM适合中小型文档但如果要生成几十万行的订单文件把所有节点都建立为COM对象内存会很可观。MSXML还提供了一个SAX风格的写入器SAXXMLWriter它不建DOM树而是把开始标签、文本、结束标签逐段输出。这个方向需要自己管理状态的推进代码量明显增加常见做法是封装一个小类在回调里把接收到的内容写到自己的std::wstring缓冲区。但说实话如果只是写文件而不是做复杂转换多数项目直接用DOM加save就够了性能瓶颈通常在编码转换和磁盘IO而不在DOM节点分配。有一种情况我建议直接拼字符串XML结构固定、数据量小、且要求零COM依赖的嵌入式或测试环境。比如生成一个只有两三个节点的简单配置std::wstring BuildConfigXml(const std::wstring value) { std::wstring xml L?xml version\1.0\ encoding\UTF-8\?\r\n; xml Lconfig\r\n; xml L value; xml EscapeXml(value); xml L/value\r\n; xml L/config\r\n; return xml; }这里的EscapeXml需要自己实现替换、、、和。你自己拼字符串省掉了COM对象创建但对转义、编码、换行风格都要负责。我不建议把这种方法用在无法预见内容的场景里因为遇到注释、CDATA、处理指令时手拼代码很快变成一团乱麻。标题既然写的是“纯原生源代码”我更倾向于把它理解为“用系统自带的MSXML来读写而不是非得自己解析”。4. 纯原生实现的边界大文件、编码、字符集与性能4.1 大文件为什么不要用loadXML内存与栈的坑loadXML和load是两回事。loadXML接收一个包含完整XML文本的BSTR也就是说你要先把整个文件读进内存再传给MSXMLMSXML又会在内存里建立DOM树等于文件数据被复制了两次。一个20MB的文件用ANSI读入变成40MB的宽字符DOM树节点再膨胀几倍轻松超过200MB。在小内存机器上这种膨胀是你肉眼可见的卡顿来源。我一般处理超过100MB的XML时改用SAX读取。MSXML的SAX2接口和Java里那套很像注册一个内容处理器在startElement和characters回调里处理当前节点处理完就扔。这样内存里永远只有当前层级。代价是API使用复杂度高不少且不能随机访问节点。如果你只需要提取某些字段而不是修改后保存SAX是稳妥选择。下面是最小的SAX回调骨架重点是告诉你接口签名实际使用时还要实现所有纯虚函数才能编译class XmlHandler : public ISAXContentHandler { public: HRESULT STDMETHODCALLTYPE startElement( const wchar_t* /*namespaceURI*/, int /*namespaceURILength*/, const wchar_t* localName, int localNameLength, const wchar_t* qName, int qNameLength, ISAXAttributes* /*attributes*/) override { wprintf(Lstart: %.*s\n, qNameLength, qName); return S_OK; } // startPrefixMapping, endElement, characters, ignorableWhitespace, // processingInstruction, documentLocator, resetState // 这些接口都要按声明实现并返回S_OK };用ISAXXMLReader的putContentHandler挂接上面的实例然后parseURL或parse输入流。这个方案相比DOM省掉的是节点对象占用的内存但你的处理函数里如果大量保存数据内存也可能涨回去。所以SAX适合“读了就处理处理完就丢”的流水线场景。4.2 读写时最常见的编码翻车点BOM、UTF-16、转义先说BOM。MSXML从文件加载时会读文件最前面的几个字节判断编码。UTF-8的EF BB BF它是认的UTF-16的FF FE或FE FF它也认。但如果你用程序生成的XML文件没有BOM同时文件里也没有?xml encoding...声明MSXML默认按UTF-8还是系统ANSI处理这是一个历史包袱。稳妥做法是无论手动拼字符串还是用DOM创建都明确写上encodingUTF-8这样不依赖BOM。再说UTF-16。loadXML接受的是BSTRBSTR本身是UTF-16Windows宽字符编码。如果你从磁盘读到一个UTF-8的字节流直接强转成const wchar_t*塞给loadXML就会把每个字节对当成一个字符中文直接变成乱码。正确做法是要么用load传文件路径要么自己把UTF-8字节流转成UTF-16的宽字符串再调loadXML。许多“MSXML中文乱码”的求助帖根源就在这里。还有一个隐藏的坑是宽窄字符混合。MSXML的API全是宽字符如果你项目里用了char*保存文件名或数据必须用MultiByteToWideChar转成wchar_t*再传入。尤其是UTF-8的数据直接赋值给_bstr_t会按ANSI转得到的宽字符串是错的。我习惯封装一个Utf8ToWString的小函数把所有外部输入统一成宽字符串后再交给MSXML。转义问题容易被忽略的是CDATA。CDATA区块里的内容不需要转义和但]]这个字符序列仍然不允许出现。如果你用createCDATASection创建CDATA内容里一旦包含]]序列化时会自动拆分或报错。另外属性值不能包含未转义的空白符和引号DOM的setAttribute会帮你转义但如果你用put_text设置文本再把它当属性导出可能会漏掉。4.3 性能对比DOM、SAX、手动解析的实测结论我没有办法在这里给出一个公认的数字因为性能依赖文件结构、节点数量、编码和机器但一个经验结论值得说DOM在节点数小于10万时解析耗时通常在几十毫秒到几百毫秒而手动写的状态机如果只提取一个字段可能只要几毫秒一旦遇到大文件DOM的浪费成倍放大SAX则能保持平稳的内存曲线。具体的取舍可以看这张表方案内存随机访问修改XML适用场景DOM较高支持支持配置文件、中小型数据交换SAX低不支持不支持日志、大文件、流式处理手写解析最低看实现很难固定结构、格式严格可控看起来手写解析很诱人但它的开发成本不只是写一个忽略空格的扫描器还要处理实体表、CDATA、注释、DTD甚至数字字符引用。我见过有人写了两个月解析器结果遇到一个!DOCTYPE声明就直接废了。选择手写解析之前先确认你的输入集永远不会出现这些情况。4.4 何时值得自己写一个极简解析器有一种场景我会毫不犹豫地推荐手写工具链里的“伪XML”。比如某些老旧系统输出的日志类似recordtime2024-01-01/timenametest/name/record没有命名空间、没有CDATA、没有实体一行一条格式严格。这时候用DOM建树反而是杀鸡用牛刀用一个正则或者简单的字符串查找就能提取time和name。但即使写极简解析器也要处理两个基本问题一个是被提取的值里可能包含或必须验证它们不会破坏提取逻辑另一个是文件里如果出现跨行的文本使用逐行读取会出错。我会先把整个文件读进内存然后逐个找和的索引用std::wstring::find循环取子串。这种方法没有尝试处理自闭合标签和嵌套所以只能用于扁平结构。最后还要在代码里留注释说明这个解析器不能用于生产环境的通用XML避免后来人拿它去解析任意文件。5. 避坑指南Visual C读写XML的常见问题与排查5.1 CreateInstance返回REGDB_E_CLASSNOTREG现象用MSXML6创建DOMDocument60时CreateInstance返回0x80040154中文错误信息是“没有注册类”。原因最常见不是MSXML没装而是当前线程没有初始化COM。MSXML是COM组件必须先CoInitialize。另一个次要原因是系统太老Windows XP SP2之前没有MSXML6或者安装的精简版系统把MSXML组件去掉了。解决在调用CreateInstance前先调用CoInitialize(NULL)并检查返回值。如果确认初始化还不行改用MSXML3#import msxml3.dll并把__uuidof(DOMDocument60)替换成__uuidof(DOMDocument30)。注意MSXML3和MSXML6的ProgID都不一样代码里不要混用。5.2 程序退出时内存不释放或卡住现象程序反复创建DOM文档处理XML长时间运行后内存只升不降或者退出时在COM对象释放阶段卡住几秒。原因DOM节点对象和文档对象存在循环引用比如你取了doc-documentElement之后又把这个元素挂到了另一个文档下或者把节点的ownerDocument缓存到全局变量导致引用计数无法归零。智能指针虽然能自动释放但循环引用依然会让对象在全局析构阶段才被回收。解决用完节点后主动置空尤其是全局或成员变量。nodePtr NULL; docPtr NULL;顺序上先释放子节点再释放文档。不要在函数退出前保留IXMLDOMElementPtr等局部智能指针的副本。另外加载后立即把async设为FALSE也能避免后台线程持有文档引用。5.3 解析后取到的文本前面带空格或乱码现象使用node-text读取元素内容发现结果里混入了缩进的换行和空格或者从属性值取出的字符串在转换为wchar_t*后显示乱码。原因text属性返回的是该元素下所有文本节点连接后的结果包括格式化用的空白文本节点例如a\n bx/b\n/a在a元素上取text会得到“\n x\n”。乱码则是_variant_t转BSTR时没有ChangeType(VT_BSTR)直接读了bstrVal或者把_bstr_t当成了窄字符输出。解决只对叶子元素调用text或用node-childNodes-length判断是否没有元素子节点对于属性值先v.ChangeType(VT_BSTR); _bstr_t val v.bstrVal;再使用。输出宽字符串用wprintf(L%ls)不要用printf(%s)MSXML里全是宽字符。5.4 保存文件后中文变成问号现象代码在调试窗口里看到节点内容都是中文doc-save(_variant_t(Lout.xml))写完再用记事本打开变成“????”。原因XML声明没有写encodingMSXML默认按系统ANSI代码页写文件。在简体中文系统上是GBK记事本按UTF-8打开就会乱码或者声明里写了encodingUTF-8但实际系统代码页不是UTF-8MSXML在编码转换时用替代字符填了问号。解决把声明写成version1.0 encodingUTF-8并确保保存路径文件本身没有以UTF-16的wchar_t字节直接写入。如果你自己用CFile写文件要把宽字符串转成UTF-8字节再写不要直接写wchar_t数组。最简单的验证方法用十六进制编辑器看文件头UTF-8无BOM时头部是3C 3F 78 6D即?xm不应该出现FF FE字节序标记。5.5 XPath查询结果为空换一种写法又能查到现象同样的XML用//item查不到但用/*/*能查到或者带属性过滤时结果为空。原因XML根节点声明了默认命名空间所有子节点都属于某个URI而XPath里的无前缀名称匹配的是空命名空间所以查不到。这是XML解析最常见的边界问题不是MSXML的bug。解决先打印根节点documentElement-namespaceURI确认有值后调用doc-setProperty(_bstr_t(SelectionNamespaces), _variant_t(Lxmlns:def 命名空间URI L));然后用//def:item来查询。注意命名空间URI可能带单引号赋值时如果字符串包含单引号外层用双引号否则会被解析器截断。5.6 DLL里调用MSXML导致宿主进程崩溃现象在DLL里封装了一个XML读写函数宿主程序调用了几次之后崩溃或者第一次调用成功第二次就内存访问冲突。原因DLL加载时使用了静态链接的CRT而宿主程序用的是另一套CRT两边在释放COM字符串、BSTR时内存堆不一致。还有一种可能是DLL没有在DllMain里初始化COM而是让每个导出函数自己CoInitialize多个线程进来就乱了。解决DLL里尽量使用动态链接到MD运行时的配置在每个导出函数内部自己CoInitializeEx并配对CoUninitialize。如果DLL和宿主都调用了MSXML不要把IXMLDOMDocumentPtr作为跨模块接口返回给宿主而是封装成不透明指针。这个问题和MSXML本身关系不大但表现为“在DLL里解析XML不稳定”容易被甩锅给解析器。6. 进阶调试与验证用日志和最小用例锁定XML解析问题6.1 写一个XML样本自检工具当你手头有一批XML要解析与其在业务代码里到处打日志不如先写一个十几行的自检工具把每个文件的结构和错误信息一次性输出。这个工具的核心就是前面第2章的WalkNode再加一个统计节点数的计数器。void DumpXmlFile(const wchar_t* path) { IXMLDOMDocumentPtr doc; if (!LoadXmlFile(path, doc)) return; wprintf(Lroot: %ls\n, (wchar_t*)(_bstr_t)doc-documentElement-nodeName); WalkNode(doc-documentElement, 1); }如果文件很多用FindFirstFile遍历目录对每个文件调用DumpXmlFile把输出重定向到日志文件。通过这种方式我能在几秒内发现哪批文件里混入了非标准节点或者哪个文件的编码和预期不符。自检工具的作用不是修bug而是让你在修改主业务前知道输入到底长什么样避免带着错误的假设排查。6.2 用parseError定位错误行列解析失败时parseError里的line和linepos直接指向出错行列但很多人只看了reason。reason经常是英文的“The character , hexadecimal value 0x… cannot be normalized”没有行列时根本不知道是哪个字符。这段代码可以放在所有load失败后IXMLDOMParseErrorPtr err doc-parseError; wprintf(LerrorCode: %ld\n, err-errorCode); wprintf(Lline: %ld, linepos: %ld\n, err-line, err-linepos); wprintf(Lreason: %ls\n, (wchar_t*)(_bstr_t)err-reason); wprintf(LsourceText: %ls\n, (wchar_t*)(_bstr_t)err-srcText);srcText返回出错行附近的原文如果是一大行压缩的XML这一行会很长但至少能看到出错位置前后的片段。我习惯把这个错误转成字符串拼进日志模块而不是用printf输出到控制台因为服务场景下控制台不存在。6.3 一个教训去年我维护过一个导出工具反复出现“XML加载失败”的错误当时只打印了错误码但没打行列花了很长时间怀疑是MSXML版本问题。后来把line和linepos打出来才发现是某个用户把属性值里的写成了中文全角符号导致XML格式不合法。从此之后我给自己定了一个规矩任何load失败的地方至少记录errorCode、line、linepos、srcText四样东西少了任何一样都可能把排查方向带偏。这个习惯救过我很多次也希望帮到你。本文还有配套的精品资源点击获取
Visual C++读写XML不靠三方库：用MSXML原生实现解析与序列化
简介一份面向 Visual C 开发者的 XML 解析与读写原生源码包强调无需安装任何第三方库即可编译运行特别适合希望深入理解 XML 底层解析机制、愿意脱离框架依赖的 C/C 学习者也适合需要在轻量级工程中快速集成 XML 读写能力的开发者参考。压缩包共 18 个文件、约 46KB涵盖 7 个 C 源文件、5 个头文件、3 个 XML 样例文件同时附有解决方案、项目工程配置与文本说明文档源码、工程骨架与样本数据相互配套可直接编译运行验证。已有 189 人浏览学习。内容围绕 DOM 节点遍历、属性读取、元素创建与追加、文本转义、序列化输出以及格式校验等 XML 处理完整流程展开配合示例数据便于实际跑通并观察读写结果。整体体积小、模块边界清晰既可作为原生 XML 编程的入门模板也能在此基础上快速改造为轻量级数据交换组件。1. 不装三方库Visual C读写XML到底靠什么很多人一听到“Visual C读写XML”第一反应是去找TinyXML、Xerces-C或者NuGet上拉一个包其实Windows系统目录里早就躺着一个能跑十几年的原生解析器——MSXML。它在系统里以COM组件形式存在从VC 6.0时代就有到现在的Visual Studio 2022都不需要额外安装三方库也不存在Redistributable缺失的问题直接调COM接口就能完成解析和序列化。这篇笔记就围绕“纯原生源代码”这个思路讲清楚怎么用MSXML在VC项目里读写XML以及不想依赖第三方库时哪些坑值得提前避开。适合那些需要快速集成、交付环境不能随意装运行时、或者被三方库许可证折腾过的开发者。2. 用MSXML实现XML读取从加载DOM到遍历节点的完整代码2.1 为什么选MSXML而不是自己写解析器在开始写代码之前先回答一个最容易被问的问题既然标题强调“纯原生源代码”为什么不干脆自己写一个解析器我见过不少同事用fgetc加状态机去啃XML最后都在换行折叠、CDATA和实体转义上撞墙。一个合法的XML里可以出现![CDATA[not-tag]]这样的整段文本也可以出现#x4E2D;这样的数字字符引用自己的状态机很难把所有情况覆盖完而且一旦遇到非UTF-8编码的输入往往连第一个?xml声明都读不对。MSXML是Windows操作系统自带的COM组件从Windows 2000之后的系统里都有它不了解它的人总觉得这是“又引入一个依赖”其实它本来就系统级存在。Visual C项目里用#import指令就能引用它的类型库不需要下载任何SDK包也不需要在目标机器上装运行时这正好符合“不装三方库”的约束。更重要的是它原生支持XPath能用一句selectSingleNode定位到几十层深的节点这是手写解析器短期内赶不上的能力。选型上我一般分两步如果项目只需要读取、修改、另存XML且文件在几十MB以内DOM最合适API简单、修改方便如果文件超过百MB或者要求边读边丢弃已经处理过的节点再上SAX流式解析。下面的代码主要围绕DOM展开因为这是日常最高频的场景。2.2 初始化COM与加载XML文件的最小代码先写一个最基础的加载函数。这里用#import msxml6.dll生成智能指针代码看起来干净也不用到处写Release。#include windows.h #include comdef.h #import msxml6.dll using namespace MSXML2; bool LoadXmlFile(const wchar_t* filePath, IXMLDOMDocumentPtr doc) { HRESULT hr doc.CreateInstance(__uuidof(DOMDocument60)); if (FAILED(hr)) { printf(CreateInstance failed: 0x%08X\n, hr); return false; } doc-async VARIANT_FALSE; VARIANT_BOOL ok doc-load(_variant_t(filePath)); if (ok ! VARIANT_TRUE) { IXMLDOMParseErrorPtr err doc-parseError; printf(load failed: code%ld line%ld pos%ld reason%ls\n, err-errorCode, err-line, err-linepos, (wchar_t*)(_bstr_t)err-reason); return false; } return true; }CreateInstance(__uuidof(DOMDocument60))创建的是MSXML6.0的DOMDocument对象。__uuidof从#import生成的头文件里拿到CLSID运行时会向COM注册表查询并创建实例。如果你用的是VC 6.0或者目标系统很老可以把msxml6.dll改成msxml3.dll并把DOMDocument60改成DOMDocument30其余代码几乎一致。async必须设为FALSE否则load可能立即返回而解析还在后台进行下一个语句就开始访问空文档。doc-load()接收的是_variant_t这里传入文件路径。它内部会根据文件头BOM和XML声明自动识别编码所以UTF-8、UTF-16、GB2312都能正确处理。返回的VARIANT_BOOL为TRUE才表示解析成功。失败时从parseError里拿错误码、行号和原因这个信息后面调试会一直用到。调用前务必初始化COM线程模型int main() { CoInitialize(NULL); // 每个使用COM的线程都要调用 IXMLDOMDocumentPtr doc; if (LoadXmlFile(Ltest.xml, doc)) { printf(loaded OK\n); } CoUninitialize(); return 0; }CoInitialize(NULL)默认把当前线程设为单线程单元STA。如果是在工作线程里解析建议改用CoInitializeEx(NULL, COINIT_MULTITHREADED)并且别忘了在函数末尾CoUninitialize()。这个初始化很容易漏漏掉后CreateInstance会返回REGDB_E_CLASSNOTREG让你误以为是MSXML没装好其实是COM没启动。2.3 遍历节点、读取属性与文本的写法加载成功只是第一步更常用的是把整棵树扫一遍。下面这个递归函数会打印每个元素、属性和文本节点代码里用的都是DOM标准属性不依赖具体文件名。void WalkNode(IXMLDOMNodePtr node, int depth) { if (!node) return; if (node-nodeType NODE_ELEMENT) { _bstr_t name node-nodeName; for (int i 0; i depth; i) wprintf(L ); wprintf(L%ls\n, (wchar_t*)name); IXMLDOMNamedNodeMapPtr attrs node-attributes; if (attrs ! NULL) { for (long i 0; i attrs-length; i) { IXMLDOMNodePtr attr attrs-item(i); _variant_t v attr-nodeValue; v.ChangeType(VT_BSTR); _bstr_t attrVal v.bstrVal; for (int j 0; j depth 1; j) wprintf(L ); wprintf(Lattr: %ls %ls\n, (wchar_t*)(_bstr_t)attr-nodeName, (wchar_t*)attrVal); } } IXMLDOMNodeListPtr children node-childNodes; for (long i 0; i children-length; i) { WalkNode(children-item(i), depth 1); } } else if (node-nodeType NODE_TEXT) { _variant_t v node-nodeValue; v.ChangeType(VT_BSTR); _bstr_t text v.bstrVal; if (text.length() 0) { for (int i 0; i depth; i) wprintf(L ); wprintf(Ltext: %ls\n, (wchar_t*)text); } } }判断nodeType是最稳妥的方式因为文本节点的nodeName返回的是#text直接拿名称过滤会漏掉空白节点。attributes只对元素节点有效但这里已经用NODE_ELEMENT保护了。属性节点的值是_variant_t不能直接交给_bstr_t先ChangeType(VT_BSTR)再取bstrVal否则在64位编译下可能读取到错误的偏移量。这个细节我建议直接固化到自己的代码模板里省得每次踩一遍。如果你只需要某一层的节点不需要递归可以用childNodes配合item(i)来遍历。要注意MSXML里的IXMLDOMNodeList下标从0开始和C的习惯一致。2.4 常用查询接口selectNodes与XPath以前我手写查找函数时每次都要递归判断节点名后来发现MSXML自带XPath一句就能取代几十行循环。void QueryItems(IXMLDOMDocumentPtr doc) { IXMLDOMNodeListPtr list doc-selectNodes(_bstr_t(L//item[enabled1]/name)); for (long i 0; i list-length; i) { IXMLDOMNodePtr nameNode list-item(i); _bstr_t nodeText nameNode-text; wprintf(Lname: %ls\n, (wchar_t*)nodeText); } }这里//item表示任意深度下的item节点[enabled1]是属性过滤/name取子节点。selectNodes返回的是所有匹配节点组成的集合selectSingleNode只返回第一个。如果你的XML里带了命名空间比如根节点写了xmlnshttp://example.com/ns直接写//item会查不到任何内容。这时候需要先设置selectionNamespacesdoc-setProperty(_bstr_t(LSelectionNamespaces), _variant_t(Lxmlns:nshttp://example.com/ns)); // 然后用带前缀的XPath IXMLDOMNodePtr node doc-selectSingleNode(_bstr_t(L//ns:item[ns:id1001]));setProperty必须在执行查询之前调用命名空间前缀随便起只要映射到正确的URI就行。MSXML对XPath的大小写是敏感的Item和item是两个不同的路径属性名也区分大小写这个和在浏览器里写XPath的习惯不太一样我在第一次用老生成的数据时吃过亏。3. 原生写XML构建节点、序列化到文件的三条路径3.1 创建DOMDocument并构建根节点读会了就得会写。很多项目里“写XML”不是把一段字符串直接丢进文件而是要修改配置然后保存回去。用DOM创建文档和节点的顺序有讲究先建文档再建声明最后建根元素。IXMLDOMDocumentPtr doc; doc.CreateInstance(__uuidof(DOMDocument60)); IXMLDOMNodePtr decl doc-createProcessingInstruction( _bstr_t(Lxml), _bstr_t(Lversion\1.0\ encoding\UTF-8\)); doc-appendChild(decl); IXMLDOMElementPtr root doc-createElement(_bstr_t(Lconfig)); doc-appendChild(root); IXMLDOMElementPtr item doc-createElement(_bstr_t(Litem)); item-setAttribute(_bstr_t(Lid), _variant_t(1001)); root-appendChild(item);createProcessingInstruction的第一个参数固定是xml第二个参数是声明字符串注意这里的引号要写成转义后的\。声明节点必须通过appendChild挂在文档节点下而且位置必须是第一个否则输出文件不符合“先声明后根元素”的规范。createElement只能创建没有父节点的元素最后用root-appendChild(item)把它挂到根下。DOM的好处是孩子顺序完全由append的顺序决定不用手动维护标签闭合。这段代码里我没有手动拼config之类的字符串原因是MSXML会自动做转义。手动拼容易漏掉和后面解析时会报“无效字符”之类的错误排查半天才发现是数据本身带了特殊符号。3.2 添加子节点、属性、文本的API顺序给元素添加文本有两种做法它们的副作用不一样许多教程没提过这个区别。// 方式一创建文本节点后追加适合混合内容 IXMLDOMTextPtr text doc-createTextNode(_bstr_t(L单价100)); item-appendChild(text); // 方式二直接设置text属性会替换该元素下所有子节点 item-Puttext(_bstr_t(L替换后的内容));方式一借助createTextNode文本里的会被序列化成lt;读回来时又是原始字符这个过程MSXML自动完成。方式二Puttext是快捷方法适合只保留纯文本的叶子节点。如果元素下面已经有子元素先用Puttext会把它们全冲掉所以要在没有其他子节点时使用。需要同时设置多个子节点或文本节点时老老实实用appendChild按顺序加。添加属性时要注意setAttribute的第二个参数是VARIANT你可以传整数、字符串、布尔值。传字符串时必须包成_bstr_t否则编译器会把它当成const wchar_t*之外的类型导致匹配到错误的重载。写成item-setAttribute(_bstr_t(Lid), _variant_t(1001))大家都能看懂但如果传的是宽字符串最好写成item-setAttribute(_bstr_t(Lname), _variant_t(_bstr_t(Ldemo)))避免隐式转换的意外。3.3 保存到文件的编码选择UTF-8与GB2312保存是写XML最直接的成败点。我遇到过很多次代码里怎么写的都对保存完中文全变问号最后发现是XML声明编码和文件实际存储编码不一致。HRESULT hr doc-save(_variant_t(Loutput.xml)); if (FAILED(hr)) { printf(save failed: 0x%08X\n, hr); }save到文件路径时MSXML会读取文档里XML声明中的encoding属性并按这个编码去写文件。所以只要在createProcessingInstruction里写了encodingUTF-8保存出来的就是UTF-8。如果你写的是encodingGB2312它会用系统代码页转成GB2312。没有声明时MSXML会按系统默认ANSI代码页处理在简体中文系统上可能是GBK一旦换到英文系统保存中文就乱了。注意save到文件时会根据XML声明写编码所以创建文档时就要把encoding写对。还有一个容易被忽略的点doc-xml属性返回的是UTF-16字符串。如果你在调试时把它直接写进一个ANSI文件中文内容会变成类似“浣犲ソ”的乱码。所以不要拿xml属性绕过save自己去写文件除非你明确知道自己在做编码转换。save方法自己处理编码是性价比最高的做法。3.4 流式写入SAXXMLWriter与手动拼字符串的取舍DOM适合中小型文档但如果要生成几十万行的订单文件把所有节点都建立为COM对象内存会很可观。MSXML还提供了一个SAX风格的写入器SAXXMLWriter它不建DOM树而是把开始标签、文本、结束标签逐段输出。这个方向需要自己管理状态的推进代码量明显增加常见做法是封装一个小类在回调里把接收到的内容写到自己的std::wstring缓冲区。但说实话如果只是写文件而不是做复杂转换多数项目直接用DOM加save就够了性能瓶颈通常在编码转换和磁盘IO而不在DOM节点分配。有一种情况我建议直接拼字符串XML结构固定、数据量小、且要求零COM依赖的嵌入式或测试环境。比如生成一个只有两三个节点的简单配置std::wstring BuildConfigXml(const std::wstring value) { std::wstring xml L?xml version\1.0\ encoding\UTF-8\?\r\n; xml Lconfig\r\n; xml L value; xml EscapeXml(value); xml L/value\r\n; xml L/config\r\n; return xml; }这里的EscapeXml需要自己实现替换、、、和。你自己拼字符串省掉了COM对象创建但对转义、编码、换行风格都要负责。我不建议把这种方法用在无法预见内容的场景里因为遇到注释、CDATA、处理指令时手拼代码很快变成一团乱麻。标题既然写的是“纯原生源代码”我更倾向于把它理解为“用系统自带的MSXML来读写而不是非得自己解析”。4. 纯原生实现的边界大文件、编码、字符集与性能4.1 大文件为什么不要用loadXML内存与栈的坑loadXML和load是两回事。loadXML接收一个包含完整XML文本的BSTR也就是说你要先把整个文件读进内存再传给MSXMLMSXML又会在内存里建立DOM树等于文件数据被复制了两次。一个20MB的文件用ANSI读入变成40MB的宽字符DOM树节点再膨胀几倍轻松超过200MB。在小内存机器上这种膨胀是你肉眼可见的卡顿来源。我一般处理超过100MB的XML时改用SAX读取。MSXML的SAX2接口和Java里那套很像注册一个内容处理器在startElement和characters回调里处理当前节点处理完就扔。这样内存里永远只有当前层级。代价是API使用复杂度高不少且不能随机访问节点。如果你只需要提取某些字段而不是修改后保存SAX是稳妥选择。下面是最小的SAX回调骨架重点是告诉你接口签名实际使用时还要实现所有纯虚函数才能编译class XmlHandler : public ISAXContentHandler { public: HRESULT STDMETHODCALLTYPE startElement( const wchar_t* /*namespaceURI*/, int /*namespaceURILength*/, const wchar_t* localName, int localNameLength, const wchar_t* qName, int qNameLength, ISAXAttributes* /*attributes*/) override { wprintf(Lstart: %.*s\n, qNameLength, qName); return S_OK; } // startPrefixMapping, endElement, characters, ignorableWhitespace, // processingInstruction, documentLocator, resetState // 这些接口都要按声明实现并返回S_OK };用ISAXXMLReader的putContentHandler挂接上面的实例然后parseURL或parse输入流。这个方案相比DOM省掉的是节点对象占用的内存但你的处理函数里如果大量保存数据内存也可能涨回去。所以SAX适合“读了就处理处理完就丢”的流水线场景。4.2 读写时最常见的编码翻车点BOM、UTF-16、转义先说BOM。MSXML从文件加载时会读文件最前面的几个字节判断编码。UTF-8的EF BB BF它是认的UTF-16的FF FE或FE FF它也认。但如果你用程序生成的XML文件没有BOM同时文件里也没有?xml encoding...声明MSXML默认按UTF-8还是系统ANSI处理这是一个历史包袱。稳妥做法是无论手动拼字符串还是用DOM创建都明确写上encodingUTF-8这样不依赖BOM。再说UTF-16。loadXML接受的是BSTRBSTR本身是UTF-16Windows宽字符编码。如果你从磁盘读到一个UTF-8的字节流直接强转成const wchar_t*塞给loadXML就会把每个字节对当成一个字符中文直接变成乱码。正确做法是要么用load传文件路径要么自己把UTF-8字节流转成UTF-16的宽字符串再调loadXML。许多“MSXML中文乱码”的求助帖根源就在这里。还有一个隐藏的坑是宽窄字符混合。MSXML的API全是宽字符如果你项目里用了char*保存文件名或数据必须用MultiByteToWideChar转成wchar_t*再传入。尤其是UTF-8的数据直接赋值给_bstr_t会按ANSI转得到的宽字符串是错的。我习惯封装一个Utf8ToWString的小函数把所有外部输入统一成宽字符串后再交给MSXML。转义问题容易被忽略的是CDATA。CDATA区块里的内容不需要转义和但]]这个字符序列仍然不允许出现。如果你用createCDATASection创建CDATA内容里一旦包含]]序列化时会自动拆分或报错。另外属性值不能包含未转义的空白符和引号DOM的setAttribute会帮你转义但如果你用put_text设置文本再把它当属性导出可能会漏掉。4.3 性能对比DOM、SAX、手动解析的实测结论我没有办法在这里给出一个公认的数字因为性能依赖文件结构、节点数量、编码和机器但一个经验结论值得说DOM在节点数小于10万时解析耗时通常在几十毫秒到几百毫秒而手动写的状态机如果只提取一个字段可能只要几毫秒一旦遇到大文件DOM的浪费成倍放大SAX则能保持平稳的内存曲线。具体的取舍可以看这张表方案内存随机访问修改XML适用场景DOM较高支持支持配置文件、中小型数据交换SAX低不支持不支持日志、大文件、流式处理手写解析最低看实现很难固定结构、格式严格可控看起来手写解析很诱人但它的开发成本不只是写一个忽略空格的扫描器还要处理实体表、CDATA、注释、DTD甚至数字字符引用。我见过有人写了两个月解析器结果遇到一个!DOCTYPE声明就直接废了。选择手写解析之前先确认你的输入集永远不会出现这些情况。4.4 何时值得自己写一个极简解析器有一种场景我会毫不犹豫地推荐手写工具链里的“伪XML”。比如某些老旧系统输出的日志类似recordtime2024-01-01/timenametest/name/record没有命名空间、没有CDATA、没有实体一行一条格式严格。这时候用DOM建树反而是杀鸡用牛刀用一个正则或者简单的字符串查找就能提取time和name。但即使写极简解析器也要处理两个基本问题一个是被提取的值里可能包含或必须验证它们不会破坏提取逻辑另一个是文件里如果出现跨行的文本使用逐行读取会出错。我会先把整个文件读进内存然后逐个找和的索引用std::wstring::find循环取子串。这种方法没有尝试处理自闭合标签和嵌套所以只能用于扁平结构。最后还要在代码里留注释说明这个解析器不能用于生产环境的通用XML避免后来人拿它去解析任意文件。5. 避坑指南Visual C读写XML的常见问题与排查5.1 CreateInstance返回REGDB_E_CLASSNOTREG现象用MSXML6创建DOMDocument60时CreateInstance返回0x80040154中文错误信息是“没有注册类”。原因最常见不是MSXML没装而是当前线程没有初始化COM。MSXML是COM组件必须先CoInitialize。另一个次要原因是系统太老Windows XP SP2之前没有MSXML6或者安装的精简版系统把MSXML组件去掉了。解决在调用CreateInstance前先调用CoInitialize(NULL)并检查返回值。如果确认初始化还不行改用MSXML3#import msxml3.dll并把__uuidof(DOMDocument60)替换成__uuidof(DOMDocument30)。注意MSXML3和MSXML6的ProgID都不一样代码里不要混用。5.2 程序退出时内存不释放或卡住现象程序反复创建DOM文档处理XML长时间运行后内存只升不降或者退出时在COM对象释放阶段卡住几秒。原因DOM节点对象和文档对象存在循环引用比如你取了doc-documentElement之后又把这个元素挂到了另一个文档下或者把节点的ownerDocument缓存到全局变量导致引用计数无法归零。智能指针虽然能自动释放但循环引用依然会让对象在全局析构阶段才被回收。解决用完节点后主动置空尤其是全局或成员变量。nodePtr NULL; docPtr NULL;顺序上先释放子节点再释放文档。不要在函数退出前保留IXMLDOMElementPtr等局部智能指针的副本。另外加载后立即把async设为FALSE也能避免后台线程持有文档引用。5.3 解析后取到的文本前面带空格或乱码现象使用node-text读取元素内容发现结果里混入了缩进的换行和空格或者从属性值取出的字符串在转换为wchar_t*后显示乱码。原因text属性返回的是该元素下所有文本节点连接后的结果包括格式化用的空白文本节点例如a\n bx/b\n/a在a元素上取text会得到“\n x\n”。乱码则是_variant_t转BSTR时没有ChangeType(VT_BSTR)直接读了bstrVal或者把_bstr_t当成了窄字符输出。解决只对叶子元素调用text或用node-childNodes-length判断是否没有元素子节点对于属性值先v.ChangeType(VT_BSTR); _bstr_t val v.bstrVal;再使用。输出宽字符串用wprintf(L%ls)不要用printf(%s)MSXML里全是宽字符。5.4 保存文件后中文变成问号现象代码在调试窗口里看到节点内容都是中文doc-save(_variant_t(Lout.xml))写完再用记事本打开变成“????”。原因XML声明没有写encodingMSXML默认按系统ANSI代码页写文件。在简体中文系统上是GBK记事本按UTF-8打开就会乱码或者声明里写了encodingUTF-8但实际系统代码页不是UTF-8MSXML在编码转换时用替代字符填了问号。解决把声明写成version1.0 encodingUTF-8并确保保存路径文件本身没有以UTF-16的wchar_t字节直接写入。如果你自己用CFile写文件要把宽字符串转成UTF-8字节再写不要直接写wchar_t数组。最简单的验证方法用十六进制编辑器看文件头UTF-8无BOM时头部是3C 3F 78 6D即?xm不应该出现FF FE字节序标记。5.5 XPath查询结果为空换一种写法又能查到现象同样的XML用//item查不到但用/*/*能查到或者带属性过滤时结果为空。原因XML根节点声明了默认命名空间所有子节点都属于某个URI而XPath里的无前缀名称匹配的是空命名空间所以查不到。这是XML解析最常见的边界问题不是MSXML的bug。解决先打印根节点documentElement-namespaceURI确认有值后调用doc-setProperty(_bstr_t(SelectionNamespaces), _variant_t(Lxmlns:def 命名空间URI L));然后用//def:item来查询。注意命名空间URI可能带单引号赋值时如果字符串包含单引号外层用双引号否则会被解析器截断。5.6 DLL里调用MSXML导致宿主进程崩溃现象在DLL里封装了一个XML读写函数宿主程序调用了几次之后崩溃或者第一次调用成功第二次就内存访问冲突。原因DLL加载时使用了静态链接的CRT而宿主程序用的是另一套CRT两边在释放COM字符串、BSTR时内存堆不一致。还有一种可能是DLL没有在DllMain里初始化COM而是让每个导出函数自己CoInitialize多个线程进来就乱了。解决DLL里尽量使用动态链接到MD运行时的配置在每个导出函数内部自己CoInitializeEx并配对CoUninitialize。如果DLL和宿主都调用了MSXML不要把IXMLDOMDocumentPtr作为跨模块接口返回给宿主而是封装成不透明指针。这个问题和MSXML本身关系不大但表现为“在DLL里解析XML不稳定”容易被甩锅给解析器。6. 进阶调试与验证用日志和最小用例锁定XML解析问题6.1 写一个XML样本自检工具当你手头有一批XML要解析与其在业务代码里到处打日志不如先写一个十几行的自检工具把每个文件的结构和错误信息一次性输出。这个工具的核心就是前面第2章的WalkNode再加一个统计节点数的计数器。void DumpXmlFile(const wchar_t* path) { IXMLDOMDocumentPtr doc; if (!LoadXmlFile(path, doc)) return; wprintf(Lroot: %ls\n, (wchar_t*)(_bstr_t)doc-documentElement-nodeName); WalkNode(doc-documentElement, 1); }如果文件很多用FindFirstFile遍历目录对每个文件调用DumpXmlFile把输出重定向到日志文件。通过这种方式我能在几秒内发现哪批文件里混入了非标准节点或者哪个文件的编码和预期不符。自检工具的作用不是修bug而是让你在修改主业务前知道输入到底长什么样避免带着错误的假设排查。6.2 用parseError定位错误行列解析失败时parseError里的line和linepos直接指向出错行列但很多人只看了reason。reason经常是英文的“The character , hexadecimal value 0x… cannot be normalized”没有行列时根本不知道是哪个字符。这段代码可以放在所有load失败后IXMLDOMParseErrorPtr err doc-parseError; wprintf(LerrorCode: %ld\n, err-errorCode); wprintf(Lline: %ld, linepos: %ld\n, err-line, err-linepos); wprintf(Lreason: %ls\n, (wchar_t*)(_bstr_t)err-reason); wprintf(LsourceText: %ls\n, (wchar_t*)(_bstr_t)err-srcText);srcText返回出错行附近的原文如果是一大行压缩的XML这一行会很长但至少能看到出错位置前后的片段。我习惯把这个错误转成字符串拼进日志模块而不是用printf输出到控制台因为服务场景下控制台不存在。6.3 一个教训去年我维护过一个导出工具反复出现“XML加载失败”的错误当时只打印了错误码但没打行列花了很长时间怀疑是MSXML版本问题。后来把line和linepos打出来才发现是某个用户把属性值里的写成了中文全角符号导致XML格式不合法。从此之后我给自己定了一个规矩任何load失败的地方至少记录errorCode、line、linepos、srcText四样东西少了任何一样都可能把排查方向带偏。这个习惯救过我很多次也希望帮到你。本文还有配套的精品资源点击获取
