XPath查询结果顺序
对于 另一个问题，我创建了一些与 XML 相关的代码，这些代码可以在我的开发机器上运行，但不能在我之前测试过的 viper 键盘上运行将其添加到我的答案中。
我可以将问题简化为 DOMXPath::query() 返回的节点顺序在我的系统和键盘之间不同。
XML:
当我查询所有文本节点 //child::text()< /code> 结果不同：
#0: This is some
#1: , fine.
#2: text
我的机器：
#0: This is some
#1: text
#2: , fine.
我对 xpath 没有那么丰富的经验，但我确实理解为什么会发生这种情况以及它如何可能影响 PHP 实现的返回顺序。
编辑：
进一步测试表明，两个系统之间的LIBXML_VERSION有所不同：
Viper Codepad: 20626 (2.6.26; 6 Jun 2006)
My Machine...: 20707 (2.7.7; 15 Mar 2010)
For another question I have created some XML related code that works on my development machine but not on viper codepad where I tested it before adding it to my answer.
I could reduce my problem to the point that the order of nodes returned by DOMXPath::query() differs between my system and the codepad.
XML: <test>This is some <span>text</span>, fine.</test>
When I query all textnodes //child::text() the result differs:
#0: This is some
#1: , fine.
#2: text
My Machine:
#0: This is some
#1: text
#2: , fine.
I'm not that experienced with xpath that I do understand why this happens and how it's probably possible to influence the return order with the PHP implementation.
Edit:
Further testing has revealed that LIBXML_VERSION differs between the two systems:
Viper Codepad: 20626 (2.6.26; 6 Jun 2006)
My Machine...: 20707 (2.7.7; 15 Mar 2010)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
从技术上讲，XPath 1.0 返回节点集而不是节点序列。在 XPath 1.0 规范中，没有关于这些节点集的顺序的声明 - 事实上，作为集合，它们没有内在的顺序。
然而，XSLT 1.0 始终按文档顺序处理 XPath 1.0 返回的节点集，并且由于该先例，人们普遍期望当从 XSLT 以外的语言调用 XPath 时，XPath 结果将按文档顺序。然而，规范中没有任何内容可以保证这一点。在 XPath 2.0 中，用户期望成为规范的一部分，并且路径表达式的结果必须按文档顺序排列。
Technically XPath 1.0 returns node-sets rather than node sequences. In the XPath 1.0 specification there is no statement about the order of these node-sets - indeed, being sets, they have no intrinsic order.
However, XSLT 1.0 always processes the node-sets returned by XPath 1.0 in document order, and because of that precedent, there is a widespread expectation that XPath results will be in document order when XPath is invoked from languages other than XSLT. However, there is nothing in the spec to guarantee this. In XPath 2.0 the user expectation becomes part of the spec, and the results of a path expression MUST be in document order.
我可以找到以下错误报告，看起来像这个问题： Bug 363252 - libxml2's 中的接近位置xmlXPathEvalExpression() 于 2006 年 10 月 18 日报告，并确认可追溯到 2006 年 5 月（即 2.6.26 之前）有问题的版本。
这应该已在 libxml2 2.6.27 中修复。
I could find the following bug-report which looks like the issue: Bug 363252 - proximity position in libxml2's xmlXPathEvalExpression() reported 18 Oct 2006 and confirmed dating back since May 2006 which is before the 2.6.26 version in question.
This should have been fixed in libxml2 2.6.27.
它看起来像20626版本中的一个错误：
它首先按文档顺序处理所有子文本节点，然后处理子元素节点的内容。应该是你机器上的结果
It looks like an bug in 20626 version:
It process first all child text nodes in document order, then content of child element nodes. Should be as result on your machine
XPath 是一种查询语言，因此它只能按原样读取 .xml 文档的结构，而不能对其进行修改。这包括节点顺序。然而，在您的第一个示例中，情况并非如此。因此，根据this，这绝对是一个错误。
XPath is a query language, thus it should only read the structure of the .xml document as is and never modify it. This includes the node order. In your first example however this is not true. So this is definitely a bug according to this.
看来 Viper Codepad 并未按深度优先文档顺序返回选定的
text()节点，而是进行广度优先评估。它应该是深度优先遍历。
Saxon、MSXML、Altova XML 均按深度优先顺序返回结果。
It appears that Viper Codepad is not returning the selected
text()nodes in depth first document order, but doing a breadth first evaluation.It is supposed to be a depth first traversal.
Saxon, MSXML, Altova XML each returned the results in a depth-first order.