快速、轻量级的 XML 解析器 [关闭]

Posted 2023-02-26

【中文标题】快速、轻量级的 XML 解析器 [关闭]

【英文标题】：Fast, lightweight XML parser [closed]

【发布时间】：2011-01-09 05:19:54

【问题描述】：

我有一个特定格式的 XML 文档，我将被推送。该文档将始终为同一类型，因此非常严格。

我需要对其进行解析，以便将其转换为 JSON（嗯，这是一个稍微有点混蛋的版本，以便其他人可以将它与 DOJO 一起使用）。

我的问题是，我应该使用非常快速的轻量级（不需要 SAX 等）XML 解析器（有什么想法吗？）还是自己编写，基本上转换为 StringBuffer 并在数组中旋转？基本上，在幕后我假设所有 html 解析器都将通过字符串（或内存缓冲区）旋转并解析，并在通过的过程中产生输出。

谢谢

编辑

xml 将在 3/4 行到最大 50 行之间（极端）..

【问题讨论】：

试试 vtd-xml 你不会后悔的..

Small, minimalistic and fast XML library for Java? 的可能重复项

【参考方案1】：

这实际上取决于您要解析的 XML 类型。当已经有东西可以为你完成这项工作时，我不会编写你自己的解析器。

SAX/DOM 的选择实际上取决于您要解析的内容，请参阅此处了解如何决定使用哪一个：

http://geekexplains.blogspot.com/2009/04/sax-vs-dom-differences-between-dom-and.html

即使您不使用 SAX/DOM，仍然有一些简单的选项可供您使用，看看 Simple :)

http://simple.sourceforge.net/

您可能还想考虑 STaX。

【讨论】：

谢谢，我看看简单的

【参考方案2】：

您真的需要解析/操作 XML 文档中的任何数据吗？如果没有，您可以只创建使用 XSLT。非常简单，非常快。

【讨论】：

XSLT 旨在转换 XML，因此使用它转换为 JSON 是个好主意。

【参考方案3】：

您必须使用 XML 吗？

我发现我自己的自定义文本格式比使用任何现成包的 XML 或 JSON 都快得多——它们很快，但是通过控制我自己的格式并只进行字符串解析，我能够缩短时间与最快的 XML 实现相比减半。

显然，这仅在您完全负责格式并且可能不适合您的情况时才有效，但对于这种情况下的任何其他人：不要认为 XML 是您拥有的绝对最快的选择。不是。

【参考方案4】：

在后端解析并公开 JSON 可能是正确的方法，这样您就可以拥有可以轻松与其他来源集成的通用 JSON 数据，但是如果您有一个简单的消息并且这是您认为的唯一地方您将使用 JSON，您可以尝试解析客户端。 Dojo 有一个experimental client-side XML parser

【参考方案5】：

不，您不应该为此尝试编写自己的 XML 解析器。

SAX 本身非常轻量级和快速，所以我不知道为什么认为它太多了。此外，使用字符串缓冲区实际上比使用 SAX 的可伸缩性要小得多，因为 SAX 不需要您将整个 XML 文件加载到内存中来使用它。我使用 SAX 解析数千兆字节的 XML 文件，而在 32 位机器上使用字符串缓冲区是无法做到的。

如果您有小文件并且不需要担心性能，请考虑使用 DOM。 Java 的实现使用起来可能有点烦人（您使用 DocumentBuilder 创建文档，它来自 DocumentBuilderFactory）

从文件创建文档的代码如下所示：

Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new FileInputStream("file.xml"));

（请注意，如果您需要解析多个文件，保留对文档构建器的引用会加快处理速度）

然后您使用org.w3c.dom.Document 中的函数来读取或操作内容。例如getElementsByTagName() 返回具有特定标签名称的所有元素。

【讨论】：

我怀疑Joe所说的“轻量级”是指“易于使用”； SAX 的面向回调的 API 不是最友好的。

如果可以的话，我会多加点这个。 SAX 是在 Java 中读取 XML 的最有效方式。您将很难编写出更好的正确 XML 解析器。我认为应该可以编写回调来直接生成 JSON。如果翻译很少，那么它可能非常小。

@Michael Borgwardt：我认为使用 DOM 会比编写自己的解析器更容易:)

但是 DOM肯定不是轻量级的。对于这种从一种格式到另一种格式的翻译，SAX 是理想的选择。做对了，你就可以处理那些永远不适合内存的文件。 （在这种情况下你不需要它，但这不是重点。:)）

@PSpeed：恕我直言，SAX 并不理想，因为 SAX 的事件驱动方法比拉解析方法（kXML 解析器或类似的）更难理解和使用。

【参考方案6】：

也许您应该看看 kXML 2，这是一个专为受限环境设计的小型 XML 拉解析器，用于访问、解析和显示支持 Java 2 Micro Edition 的设备的 XML 文件。它也适用于 Java SE/EE ;-)。因为它是为微型版设计的，所以它非常轻量级（占用空间小），恕我直言，它非常易于使用（比 SAX/DOM 等东西容易得多）。

根据我自己使用 kXML 2 的经验：我用它来解析大于 1 GB 的 XML 文件 - ***转储，我对性能/内存消耗等非常满意。

最后 ;-) - 链接：http://kxml.sourceforge.net/kxml2/

【讨论】：

谢谢，。会看看 :) 因为我们在某个时候也需要一个移动版本

【参考方案7】：

使用真正的 XML 解析器。如果你不这样做，当事情发生变化时，你可能会被咬。该文档可能“非常严格”，但在两年的时间里，某些东西可能会被重构，它会改变结构，以便使用 XML 解析器解析为相同的数据结构并破坏自制字符串解析器。

【讨论】：

我明白你的意思，但已经在不同的领域（即链中的下一步）他们已经从纯 json 更改位以满足那里的要求。

因此，not-really-JSON 解析器设置为失败，但没有必要通过使用 not-really-XML 解析器引入相同的问题来使问题复杂化。跨度>

【参考方案8】：

您可以使用 Dom4j/xstream 将 xml 读取为等效的 java modal，然后使用 JSONLIB 转换为 JSON。

【讨论】：

+ Dom4j 有类似 SAX 的 API，但更简单。