C++ 实现解析XML TinyXML讲解
用mingw32-make前修改一下makefile文件,改为如下
# DEBUG can be set to YES to include debugging info, or NO otherwise(不是DEBUG)
DEBUG := NO
# PROFILE can be set to YES to include profiling info, or NO otherwise
PROFILE := NO
# TINYXML_USE_STL can be used to turn on STL support. NO, then STL
# will not be used. YES will include the STL files.(使用STL,选择的话，则可以使用std::string)
TINYXML_USE_STL := YES
一、TinyXml的特点
TinyXml是一个基于DOM模型的、非验证的轻量级C 解释器。
1. SAX和DOM
目前XML的解析主要有两大模型：SAX和DOM。
其中SAX是基于事件的，其基本工作流程是分析XML文档，当发现了一个新的元素时，产生一个对应事件，并调用相应的用户处理函数。这种方式占用内存少，速度快，但用户程序相应得会比较复杂。
而DOM（文档对象模型），则是在分析时，一次性的将整个XML文档进行分析，并在内存中形成对应的树结构，同时，向用户提供一系列的接口来访问和编辑该树结构。这种方式占用内存大，速度往往慢于SAX，但可以给用户提供一个面向对象的访问接口，对用户更为友好。
2. 验证和非验证
对 于一个特定的XML文档而言，其正确性分为两个层次。首先是其格式应该符合XML的基本格式要求，比如第一行要有声明，标签的嵌套层次必须前后一致等等， 符合这些要求的文件，就是一个合格的XML文件，称作well-formatted。但除此之外，一个XML文档因其内容的不同还必须在语义上符合相应的 标准，这些标准由相应的DTD文件或者Schema文件来定义，符合了这些定义要求的XML文件，称作valid。
因此，解析器也分为两种，一种是验证的，即会跟据XML文件中的声明，用相应的DTD文件对XML文件进行校验，检查它是否满足DTD文件的要求。另一种是忽略DTD文件，只要基本格式正确，就可以进行解析。
就我所知，验证的解析器通常都是比较重量级的。TinyXml不支持验证，但是体积很小，用在解析格式较为简单的XML文件，比如配置文件时，特别的合适。
二、 TinyXml的构建和使用
1. 获取
TinyXml首页在http://www.grinninglizard.com/tinyxml/index.html，从这里可以找到最新版本的源代码，目前的版本是 2.4.3 (截至2006.5.17).
2.构建
TinyXml 在构建时可以选择是否支持STL，选择的话，则可以使用std::string，所以通常应在Windows上，TinyXml的源码包里提供了VC6的 工程文件，直接用它就可以生成两个静该打开这个选项。态库（带STL和不带STL），非常容易。唯一需要注意的是，默认生成的库是单线程的，如果用在多线 程的项目中，需要改动一下配置，生成相应的多线程库。
在Unix平台上，TinyXml的源码包里只提供了一个Makefile，对于典型 的Linux系统，或装了gcc和gmake的其他Unix，这个Makefile足够用了，我在RH9和RHEL4上测试，简单的make就成功了。需 要注意的有以下几点：默认的编译是不支持STL的，可以通过编辑Makefile的TINYXML_USE_STL := NO那一行，把NO改成YES就可以支持STL了；还有默认只生成了一个测试程序，没有生成任何库，如果要生成静态库的话，可以用ar命令，将生成的几个 目标文件打包就行了，如果要生成动态库，则需要加上-fpic参数重新编译。
3. 使用
构建了相应的库之后，在 使用了它们的工程中，只要在连接时把他们连上就行了。需要注意的是，如果需要STL支持，在编译用到了TinyXml的文件时，需要定义一个宏 TIXML_USE_STL，对gcc，可以使用参数-DTIXML_USE_STL，对cl.exe（VC），可以使用参数 /DTIXML_USE_STL，如果嫌麻烦，可以直接定义在 tinyxml.h文件里。
三、 TinyXml的编程模型
1.类之间的关系
TinyXml实现的时DOM访问模型，因此提供了一系列的类对应XML文件中的各个节点。主要类间的关系如下图所示：
TiXmlBase：其它类的基类，是个抽象类
TiXmlNode：表示一个节点，包含节点的一般方法，如访问自节点、兄弟节点、编辑自身、编辑子节点
TiXmlDocument：表示整个XML文档，不对应其中某个特定的节点。
TiXmlElement：表示元素节点，可以包含子节点和TiXmlAttribute
TiXmlComment：表示注释
TiXmlDeclaration：表示声明
TiXmlText：表示文本节点
TiXmlUnknown：表示未知节点，通常是出错了
TiXmlAttribute：表示一个元素的属性
下面是一个简单的例子：
<?xml version="1.0" encoding="utf-8" ?>
<!-This is only a sample-->
<book>
<name>TinyXml How To</name>
<price unit="RMB">20</price>
<description>Some words…</description>
</ book >
整个文档，对应TiXmlDocument
book,name,price, description，都对应TiXmlElement
第一行对应一个TiXmlDeclaration
第二行对应一个TiXmlComment
"TinyXml How To"对应一个TiXmlText
unit则是price的一个TiXmlAttribute
这些类与XML文件中的相应元素都有很好的对应关系，因此相信参照TinyXml的文档，可以很容易的掌握各个方法的使用。
2. 需要注意的问题
各类之间的转换
由 于各个节点类都从TiXmlNode继承，在使用时常常需要将TiXmlNode*类型的指针转换为其派生类的指针，在进行这种转换时，应该首先使用由 TiXmlNode类提供的一系列转换函数，如ToElement(void)，而不是c 的dynamic_cast
检查返回值
由于TinyXml是一个非校验的解析器，因此当解析一个文件时，很可能文件并不包含我们预期的某个节点，在这种情况下，TinyXml将返回空指针。因此，必须要对返回值进行检查，否则将很容易出现内存访问的错误。
如何重头建立一个XML文件
先建立一个TiXmlDocument对象，然后，载入某个模板，或者直接插入一个节点作为根节点，接着就可以像打开一个已有的XML文件那样对它进行操作了。
四、总结
TinyXml 最大的特点就是它很小，可以很方便的静态连接到程序里。对于像配置文件、简单的数据文件这类文件的解析，它很适合。但是由于它是非验证的，因此需要在程序 里做许多检查工做，加重了程序编写的负担。因此对于复杂的XML文件，我觉得最好还是用验证的解析器来处理。
转自：http://www.2cto.com/kf/201010/75944.html
注
自从W3C建立了DOM标准 (W3C DOM)之后，以及DOM和浏览器兼容之后，DOM在实际应用中越来越广泛。
DOM是Document Object Model的简称，中文名称为文档对象模型。它的主要作用是建立网页与 Script 或程序语言沟通的桥梁。
我们平时可操作及建立文件的属性、方法及事件都以并且用“对象”来展现（例如，document 就代表“文件本身”这个对象，table 对象则代表 HTML 的表格对象等等）。这些对象可以由当今大多数的浏览器以 Script 来取用。
DOM 常用来和JavaScript交互，也就是说程序以 JavaScript写成，但使用 DOM 来存取页面及其元素。它们两者之间的结合非常紧密，甚至可以说如果没有DOM，我们在使用javascript的时候是不可想象的，因为我们每解析一个节点一个元素都要耗费很多精力，DOM 本身是设计为一种独立的程序语言，以一致的 API 存取文件的结构表述；当然除了JavaScript，DOM可还可以与任何程序语言共同运作，如C/C++、VB、VBS。
在和JavaScript进行交互的时候，DOM主要用来解析XML文档，当你的应用程序需要不断地导航、修改文档或随机地一次访问整个文档时，我们一般就使用DOM来解析。
在使用DOM进行解析的时候，它在内存中构建起一棵完整的解析树，借此实现对整个XML文档的全面、动态访问。也就是说，它的解析是有层次的，即将所有的html中的元素都解析成树上层次分明的节点，然后我们可以对这些节点进行增删改查等操作，这是对DOM模型的作用的最完善的总结。
和SAX不同，SAX是顺序解析的，与DOM相比，SAX解析器能提供更好的性能优势，它提供对XML文档内容的有效低级访问。
SAX模型最大的优点是内存消耗小，因为整个文档无需一次加载到内存中，这使SAX解析器可以解析大于系统内存的文档。另外，你无需像在DOM中那样为所有节点创建对象。最后，SAX“推”模型可用于广播环境，能够同时注册多个ContentHandler，并行接收事件，而不是在一个管道中一个接一个地进行处理。但是SAX的一些缺点使它的流行性不如DOM。
DOM的使用非常简单。你可以随机地访问XML文档，由于整个树都构建在内存中，因此可以通过DOM API修改这些节点，例如增加一个子节点或修改、删除一个节点。
不过，虽然内存树结构提供了很好的导航支持，但仍有一些解析策略问题需要仔细考虑。首先，整个XML文档必须一次解析完成，不可能只做部分解析；其次是效率问题，在内存中加载整个文档和构建完整树结构的成本很高，尤其当文档非常大的时候。典型地，DOM树的容量比文档容量要大一个数量级，所以它要消耗大量内存；第三，一般的DOM节点类型在互操作性上有优势，但对于对象类型绑定也许不是最好的。
