c++ - 我应该在 C++ 中使用什么 XML 解析器？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。



Improve this question




我有 XML 文档需要解析和/或我需要构建 XML 文档并将它们写入文本(文件或内存)。由于 C++ 标准库没有用于此的库，我应该使用什么？

注:这是一个明确的、C++-FAQ 风格的问题。所以是的，它是其他人的拷贝。我并没有简单地挪用那些其他问题，因为他们往往会问一些更具体的问题。这个问题比较笼统。

Answer 1

就像使用标准库容器一样，您应该使用什么库取决于您的需要。这是一个方便的流程图:

所以第一个问题是这样的:你需要什么？
我需要完全的 XML 合规性
好的，所以您需要处理 XML。不是玩具 XML，真正的 XML。您需要能够读取和写入所有 XML 规范，而不仅仅是低层、易于解析的部分。您需要命名空间、文档类型、实体替换等。完整的 W3C XML 规范。
下一个问题是:您的 API 是否需要符合 DOM 或 SAX？
我需要精确的 DOM 和/或 SAX 一致性
好的，所以您确实需要 API 是 DOM 和/或 SAX。它不能只是一个 SAX 风格的推送解析器，或者一个 DOM 风格的保留解析器。在 C++ 允许的范围内，它必须是实际的 DOM 或实际的 SAX。
你已经选择:
Xerces
那是你的选择。它几乎是唯一具有完整(或接近 C++ 允许)DOM 和 SAX 一致性的 C++ XML 解析器/编写器。它还具有 XInclude 支持、XML Schema 支持和大量其他功能。
它没有真正的依赖。它使用 Apache 许可证。
我不关心 DOM 和/或 SAX 一致性
你已经选择:
LibXML2
LibXML2 提供了一个 C 风格的接口(interface)(如果这真的困扰你，去使用 Xerces)，尽管该接口(interface)至少在某种程度上是基于对象的并且易于包装。它提供了许多功能，例如 XInclude 支持(带有回调，以便您可以告诉它从何处获取文件)、XPath 1.0 识别器、RelaxNG 和 Schematron 支持(尽管错误消息还有很多不足之处)，以及等等。
它确实依赖于 iconv，但可以在没有这种依赖的情况下进行配置。虽然这确实意味着您将拥有一组更有限的可能的文本编码，但它可以解析。
它使用 MIT 许可证。
我不需要完全符合 XML
好的，所以完全符合 XML 对您来说并不重要。您的 XML 文档要么完全在您的控制之下，要么保证使用 XML 的“基本子集”:没有 namespace 、实体等。
那么什么对你来说很重要？下一个问题是:在您的 XML 工作中，对您来说最重要的事情是什么？
最大的 XML 解析性能
您的应用程序需要尽可能快地将 XML 转换为 C++ 数据结构。
你已经选择:
RapidXML
这个 XML 解析器正是它上面所说的:快速 XML。它甚至不处理将文件拉入内存；如何发生取决于你。它处理的是将其解析为一系列您可以访问的 C++ 数据结构。它执行此操作的速度与逐字节扫描文件所需的速度一样快。
当然，天下没有免费的午餐。与大多数不关心 XML 规范的 XML 解析器一样，Rapid XML 不涉及 namespace 、DocType、实体(字符实体和 6 个基本 XML 实体除外)等。所以基本上是节点、元素、属性等等。
此外，它是一个 DOM 风格的解析器。因此，它确实要求您阅读所有文本。但是，它不会复制任何文本(通常)。 RapidXML 获得大部分速度的方式是通过就地引用字符串。这需要您进行更多的内存管理(您必须在 RapidXML 查看它时保持该字符串处于事件状态)。
RapidXML 的 DOM 是最基本的。您可以获得事物的字符串值。您可以按名称搜索属性。就是这样。没有将属性转换为其他值(数字、日期等)的便捷函数。你只是得到字符串。
RapidXML 的另一个缺点是编写 XML 很痛苦。它要求您对字符串名称进行大量显式内存分配以构建其 DOM。它确实提供了一种字符串缓冲区，但这仍然需要您进行大量明确的工作。它当然有用，但使用起来很痛苦。
它使用 MIT 许可证。它是一个只有头文件的库，没有依赖项。

有一个RapidXML "GitHub patch"这使它也可以与命名空间一起使用。

我关心性能但不那么关心
是的，性能对您很重要。但也许你需要一些不那么简单的东西。也许可以处理更多 Unicode 的东西，或者不需要那么多用户控制的内存管理。性能仍然很重要，但你想要一些不那么直接的东西。
你已经选择:
PugiXML
从历史上看，这是 RapidXML 的灵感来源。但是这两个项目已经出现分歧，Pugi 提供更多功能，而 RapidXML 则完全专注于速度。
PugiXML 提供 Unicode 转换支持，因此如果您有一些 UTF-16 文档并希望将它们阅读为 UTF-8，Pugi 将提供。如果您需要那种东西，它甚至还有一个 XPath 1.0 实现。
但 Pugi 的速度仍然相当快。与 RapidXML 一样，它没有依赖项，并在 MIT 许可证下分发。
阅读大量文件
您需要阅读以千兆字节为单位的文档。也许您是从 stdin 获取它们，并由其他一些进程提供的。或者您正在从大量文件中读取它们。管他呢。关键是，您需要的是不必为了处理它而一次将整个文件读入内存。
你已经选择:
LibXML2
Xerces 的 SAX 风格的 API 将在这种情况下工作，但 LibXML2 在这里是因为它更容易使用。 SAX 风格的 API 是一种推送 API:它开始解析一个流，然后触发您必须捕获的事件。您被迫管理上下文、状态等。读取 SAX 样式 API 的代码比人们希望的要分散得多。
LibXML2 的 xmlReader object 是一个 pull-API。您要求转到下一个 XML 节点或元素；你没有被告知。这允许您按照您认为合适的方式存储上下文，以在代码中比一堆回调更具可读性的方式处理不同的实体。
备择方案
Expat
Expat 是一个著名的 C++ 解析器，它使用拉解析器 API。它是由詹姆斯克拉克写的。
它的当前状态是事件的。最新版本是 2.2.9，发布于 (2019-09-25)。
LlamaXML
它是 StAX 风格的 API 的实现。它是一个拉式解析器，类似于 LibXML2 的 xmlReader解析器。
但它自 2005 年以来就没有更新过。再说一次，Caveat Emptor。
XPath 支持
XPath 是一种用于查询 XML 树中元素的系统。这是一种使用标准化语法通过公共(public)属性有效命名元素或元素集合的便捷方式。许多 XML 库都提供 XPath 支持。
这里有有效的三种选择:

LibXML2 :它提供完整的 XPath 1.0 支持。同样，它是一个 C API，所以如果这让您感到困扰，还有其他选择。

PugiXML :它还支持 XPath 1.0。如上所述，与 LibXML2 相比，它更像是 C++ API，因此您可能更喜欢它。

TinyXML : 它不支持 XPath，但有 TinyXPath 提供它的库。 TinyXML 正在转换为 2.0 版，这对 API 进行了重大更改，因此 TinyXPath 可能无法与新 API 一起使用。与 TinyXML 本身一样，TinyXPath 也是在 zLib 许可下分发的。

完成工作
所以，您不关心 XML 的正确性。性能对您来说不是问题。流媒体无关。您想要的只是将 XML 放入内存并允许您再次将其粘贴回磁盘的东西。你关心的是API。
您需要一个 XML 解析器，它体积小、易于安装、易于使用，并且小到与最终可执行文件的大小无关。
你已经选择:
TinyXML
我把 TinyXML 放在这个位置，因为它和 XML 解析器一样易于使用。是的，它很慢，但它简单明了。它有很多方便的功能来转换属性等等。
在 TinyXML 中编写 XML 没有问题。你只是 new一些对象，将它们连接在一起，将文档发送到 std::ostream ，大家都很开心。
还有一些围绕 TinyXML 构建的生态系统，具有对迭代器更友好的 API，甚至在它之上分层的 XPath 1.0 实现。
TinyXML 使用 zLib 许可证，它或多或少是具有不同名称的 MIT 许可证。