本文主要是介绍[经验总结]利用MSXML在不同DOM树之间拷贝结点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
首先还是看一段代码:
写这段代码的目的是想从不同XML/HTML 文件抽取信息拼接成一个打印页面(HTML),类似于报表打印的功能。 实现利用XPath语句提取源路径中的所有子结点，将其添加到目标路径下。实现时遇到两个难点，第一个是IXMLDOMDocument不支持命名空间，也就是说IXMLDOMDocument类型的文档结点对象不支持带命名空间的路径导航。微软的东西做得很奇怪，//Xpath 这个路径居然可以深入到带命名空间的路径中查找查找，这是与XPath标准不符合的，但却能方便用//anyNode 这样的方式提取带命名空间的结点。我们用到selectNodes，所以提取属性结点时需要在最后加一个text()函数。另外需要注意的是从当前结点出来访问路径需要加一个点（.)，不然会根结点开始访问。 每二个难点跨DOM树添加结点，没想到appendChild直接支持这个功能，只不过调用方式比较特殊，非得在后面加个NULL参数。被添加的结点其命名空间 不变。
最近经常用MSXML，相对于以前使用的Libxml，这一套API设计得还是比较方便，但是因为微软一贯的传统不开放源代码，很多细节文档中说不清或者干脆不提及，所以实现过程有1／3的时间是在与这些未知的细节斗争。还是怀念使用Libxml的日子，花一下午时间研究研究Libxml库的基本数据结构，以前遇到问题就能迎韧而解，还能根据实际情况灵活调用API。因为开源，所以能对其数据结构、实现方式做心中有数，进而能心中有沟壑，键下自风云。
突然又想起Eric Raymond笔下的那个猪小兵:" 一切都要比他想的费时和痛苦。在程序库表面光鲜的示例程序下，正在重用的组件似乎在一些边界情况下表现得无法预料或具有破坏性－－而这些边界情况在他的代码中常遇到。小兵经常奇怪写程序库的家伙是怎么想的。但他没法知道，因为组件的文档不全－－那些文档是技术文员写的，他们既不是程序员，想问题的方式也不像程序员。他也不能通过阅读源码来了解程序究竟是干什么的，因为程序库是处于专有许可证下不透明的目标码。“
Windows程序员遇到很多麻烦（编码效率和质量方面）和猪小兵一样的，这些问题归根结底是透明性。微软提供的API都缺乏透明性，很多人捧着MSDN沾沾自喜，却不知项目的灾难来自那里。我们无法修正不通内情的东西。实际上，任何规模大一些的API，如果无法看到源代码，是无法正确使用的。只有文档，还不能指导实践。文档并不能传达代码的所有细微差别之处，而“魔鬼”恰巧是隐藏在细节之中。
抱怨归抱怨，工作还是得干好。Windows的闭源开发方式应该也有一定规律，接下来得看看别人是怎么做的。
这篇关于[经验总结]利用MSXML在不同DOM树之间拷贝结点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
