应用MSXML的DOM模型处理XML-xml 模型

DOM模型在MSXML类库中的主要表现为把XML文件导入内存，形成一个IXMLDOMDocument，再把其中的每一个部件都用一个接口对应起来。因为还没用MSXML进行过XSLT格式化XML文件，所以这相关的也只好避而不谈了。先来个有XML基本部件的文本：

   (1)＜?xml version='1.0' encoding='GB2312'?＞
　　(2)＜?xml-stylesheet type='text/xsl' href='/expert/Xsl/2.xsl'?＞
　　(3)＜body＞
　　(4)　　＜code1 id=”text”＞文本＜/code＞
　　(5)　　＜code2 id=”cdata”＞
　　(6)　　＜![CDATA[
　　(7)　　这里是CDATA的内容，可以放类似’＜’等可能会和XML控制信息有冲突的内容
　　(8)　　]]＞
　　(9)　　＜/code＞
　　(10)＜/body＞

为了表述方便，在第一列都放上了行号。首先从(1)~(10)够成了一个Document，在MSXML中对应IXMLDOMDocument接口；(1)行、(2)行对应MSXML中的接口为IXMLDOMProcessingInstruction；(3)行到(10)行则为一个Root Element，对应的接口为IXMLDOMElement，(3)里面包含的多个也是element，不过是body的下一层element。需要注意的是Root只能有一个，Root下面无论多深，理论上允许无数多个(?),且允许名称重复；(4)和(5)里面各有一个id=”?”这是一个attribute（注意：(1)和(2)行version;encoding;type;href等也是），对应MSXML里的IXMLDOMAttribute；(4)里面的“文本”看起来和(7)这一行是差不多的，都是文本信息，很多人以为都可以通过get_text()直接得到（不久以前我也以为），其实是错的。对于“文本”是可以通过(4)这个element直接get_text()获取，对应于IXMLDOMText，但如果在(5)这个element直接get_text()就会出错，原因？CDATA是区别于“文本”的另外一种类型，对应于IXMLDOMCDATASection，如何获取，后面再提。现在整个XML的基本框架似乎出来了：






＜IXMLDOMDocument＞
　　＜IXMLDOMProcessingInstruction /＞
　　＜IXMLDOMProcessingInstruction /＞
　　＜IXMLDOMElement (根，只能有一个)＞
　　 ＜IXMLDOMElement IXMLDOMAttribute＞
　　IXMLDOMText
　　＜/ IXMLDOMElement ＞
　　 ＜IXMLDOMElement IXMLDOMAttribute＞
　　IXMLDOMCDATASection
　　＜/ IXMLDOMElement ＞
　　＜IXMLDOMElement＞
　　＜/IXMLDOMDocument＞

但是，看看很多关于MSXML的教程用到另外一个接口IXMLDOMNode，这个怎么回事?和上面的IXMLDOMElement有什么关系?前面用了这么长时间的MSXML经常就是在这个地方弄混，以至无所进展，最近要在C++Builder5下面使用XML解析，可是没有TXMLDocument控件，想自己封装一下MSXML的一些使用才发现其中的奥妙。在DOM模型中把包括Document、ProcessingInstruction、Attribute、Element、TextNode、CDATASection等都看作是一个个Node，在MSXML中实现接口的时候表现为这些对象都是从Node派生出来的，要理解Node和这一些接口的关系关键是要看清楚各接口之间的派生关系。为什么要添加这一个Node接口呢？目的是为了使XML各要素之间联结起来，不至于松散。
再加上另外两个接口IXMLDOMNodeList和IXMLDOMNamedNodeMap。其中IXMLDOMNamedNodeMap主要使用在联结同一个Element的各Attribute，因为同一个Element的Attribute必须保证两两不能冲突，而IXMLDOMNodeList则用于联结其他的几个要素ProcessingInstruction、Element、TextNode、CDATASection等，而这几个要素比如Element，在同一个层是允许相同名称重复出现的。上面的联结并没有包括Document这个Node，因为Document是整个XML的第一个Node，不可能也不允许出现在IXMLDOMNodeList和IXMLDOMNamedNodeMap下面。这段说法我也算是经过代码证实过的吧！把MSXML的Document作为第一个Node，然后通过NamedNodeMap编历该层的所有Attribute，再通过NodeList递归循环下一层的所有Node。可以看到这样的一个树状结构（其中的attribute在该行括号列出，缩进表示所在层）：




#document
　　xml (version;encoding)
　　xml-stylesheet (type; href)
　　body
　　 code1 (id)
　　#text
　　 code2 (id)
　　#cdata-section

从上面打印出来的信息可以看出TextNode，CDATASection是当作Element的下一层Node来处理的。get_text()只是为了方便使用TextNode的一个捷径，对CDATASection通过get_text()访问会出错，则可考虑通过下一层Node的第一个Node来获取。方法：




MSXML::IXMLDOMNodePtr child;
　　child = parent->childNodes->get_item(0);
　　if (child != NULL)
　　text = child->get_nodeValue();

在递归循环的时候，通常我们并不能预知这一个Node是什么类型的。为了知道这一个Node是Element还是TextNode，或者其他类型，可以通过IXMLDOMNode::nodeType来获取，这是一个枚举类型，有如下取值（从这也可以看出，上面这个XML文本并没有涵盖XML所有要素）：




NODE_ELEMENT (1)
　　NODE_ATTRIBUTE (2)
　　NODE_TEXT (3)
　　NODE_CDATA_SECTION (4)
　　NODE_ENTITY_REFERENCE (5)
　　NODE_ENTITY (6)
　　NODE_PROCESSING_INSTRUCTION (7)
　　NODE_COMMENT (8)
　　NODE_DOCUMENT (9)
　　NODE_DOCUMENT_TYPE (10)
　　NODE_DOCUMENT_FRAGMENT (11)
　　NODE_NOTATION (12)

#p#
好了，下面应该可以把“XML文件的处理思考”里面出现的一些问题一个个罗列出来了吧：
问题一：最大的问题，通过路径来找到比较深入的一个节点
在这篇文章中通过递归调用函数来实现这个功能，完全没有必要，算是多此一举了。DOM模型中自身带的IXMLDOMNode::SelectSingleNode和IXMLDOMNode::SelectNodes（XPath）实现了比这个递归调用更完美的功能。简单说一下SelectSingleNode的使用方法(msdom是IXMLDOMDocument实例)




MSXML::IXMLDOMNodePtr parent, child;
　　parent = msdom->documentElement;
　　//child为code1类型Element
　　child = parent->selectSingleNode(“/code1”);
　　//child为code1的id类型Attribute
　　child = parent->selectSingleNode(“/code1@id”);
　　//child名为code1且Attribute id=’text’的那个Element类型Element
　　child = parent->selectSingleNode(“/code1@[id=’text’]”);

…其它高深点的用法待后研究，为XPath相关。
问题二：C++ Builder6里面的TXMLDocument并不单纯是对MSXML的封装
为了在C++ Builder 5下面封装出一个类似的控件来，找了一些相关资料，发现MSXML、OpenXML等DOM模型的解析器都是同一套接口（希望我没有弄错），只是内部实现不同。TXMLDocument通过设置Ventor可以设置使用不同的解析器，但是在C++Builder里面使用方法却是完全相同的。默认好像是使用MSXML解析，比较优劣，MSXML需在客户端注册较新的msxml.dll类库；SAX的需要附带较大的dll；OpenXML因为是直接使用一个.pas文件编译，直接生成到了可执行文件。
问题三：在文章中遍历NodeList使用了IEnum接口
有点杀鸡用牛刀之嫌，现在的遍历可以这样：




for (int i = 0; i ＜ nodelist-＞get_length(); i++)
　　{
　　child = nodelist-＞get_item((long)i);
　　name = child-＞get_nodeName();
　　}

想想原来做的时候应该也用过这个方法，不过当时不知道Node和Element之间的关系，胡乱执行下面这样的转换所以转换出的element == NUL，就以为此路不通。
IXMLDOMElementPtr element = (IXMLDOMNodePtr)node;
问题三：到后来补的一段appendChild的操作，将createElement出来的Element直接转换成Node再appendChild。其实，这应该是最基础的一个C++知识，关键是要看清MSXML实现的Com里面也带有了C++的这种技巧。
现在再来看看C++ Builder 5里面怎么解决没有TXMLDocument控件，要使用MSXML类库有什么办法。
最开始想到的是使用import语句的方法，即
#import "C:Windowssystem32MSXML.DLL" named_guids
可是，import进来能生成tlb和tlh文件，进行编译却无法通过，总提示缺少了些什么，或有一些函数未能导出来（对了，可以在VC++里面import，然后复制生成的tlb和tlh到C++Builder项目）。于是，直接使用C++ Builder里面自带的TVariant类进行COM实例化，调用函数，属性（OleFunction，OlePropertyGet，OlePropertySet）等。例：




TVariant varMSDOM = CreateOleObject(“MSXML.DOMDocument”);
varMSDOM.OleFunction(L“load”, L”c:tmp.xml”);
TVariant varDoc = varMSDOM.OlePropertyGet(“documentElement”);

直觉是这种调用方法是会比import进来的调用速度要慢。差别好像是import直接通过虚函数表查找函数指针进行调用；OleFunction这些则通过IDispatch接口的invoke函数，间接调用，而且不能调用import进来name_guids的那些函数，如get_nodeName(BSTR *)。不管怎么样，通过TVariant还是基本能够满足要求，函数的调用。
然后，突然发现C++ Builder的Project上有个Import From Type Library的菜单，也尝试一下。tlb和tlh文件都生成了，加入工程编译一下，能够通过，不过tlh里面的定义，和调用方法却和VC里面的import进来有些不同：
1. VC里面的实例化直接用智能指针如：




MSXML::IXMLDOMDocumentPtr msdom;
msdom.CreateInstance(__uuidof(MSXML::DOMDocument));

C++Builder里面的实例化，则通过另外一个编译器封装的对象来实现




TCOMIXMLDOMDocument i_xmldocument = CoDOMDocument::Create();
IXMLDOMDocumentPtr msdom = (IXMLDOMDocumentPtr) i_xmldocument;

TCOMIXMLDOMDocument的定义在MSXML2_TLB.h里面可以找到




typedef TComInterface　TCOMIXMLDOMDocument;

2. C++Builder里面也有IXMLDOMDocumentPtr msdom，可是这个指针却不能直接用于判断是否等于NULL，编译器会提示错误，而应改为：
if ((IXMLDOMDocument *)msdom == NULL)
上面在C++Builder下面使用MSXML的经验，延伸到其它类型的COM的自动化(automation)，应该是不会有什么问题的！不是吗？
【编辑推荐】

在ASP.NET中使用Treeview控件和XML
如何利用Scala简化XML处理
通过Java编程处理XML服务定义