xpath中的union运算符和|符号功能等价，均用于合并节点集且结果按文档顺序排列、无重复节点，核心区别在于版本支持与语法风格：|是xpath 1.0及以上版本都支持的传统联合操作符，而union是xpath 2.0及以上版本引入的更易读的关键词形式；在实际使用中，若需兼容xpath 1.0环境（如xslt 1.0或浏览器中的document.evaluate），必须使用|，而在明确支持xpath 2.0+的环境中可选择union以提升代码可读性；联合操作广泛应用于聚合不同路径或条件的节点，例如选取多种标题标签、收集分散的价格信息、整合多区域内容或合并满足不同属性条件的元素，从而增强xpath查询的灵活性与表达能力。
XPath中的
union
运算符和
|
符号，本质上它们都用于执行节点集的联合操作，也就是将两个或多个节点集合并成一个不包含重复节点的新节点集。核心区别在于，
|
是XPath 1.0及后续版本都支持的传统语法，而
union
关键词则是在XPath 2.0及更高版本中引入的，作为一种更显式、更易读的替代方案。你可以理解为，它们是同一功能在不同XPath版本中的两种表达方式。
解决方案
当我们需要从XML/HTML文档中选取满足不同条件的节点集合时，联合操作符就显得尤为重要。无论是使用
|
还是
union
，其目的都是为了聚合结果。例如，如果你想同时选取页面中的所有
<h1>
和
<h2>
标题，你可以写成
//h1 | //h2
，或者在XPath 2.0+的环境下写成
//h1 union //h2
。
从功能层面讲，两者是等价的：它们都会遍历第一个节点集，然后遍历第二个节点集，将所有唯一的节点（即没有在之前节点集中出现过的节点）添加到结果集中。最终的节点集会按照文档顺序（document order）排列。这种合并能力极大地增强了XPath查询的灵活性和表达力，尤其是在处理结构不规则或需要从多个路径收集信息的场景下。
举个例子，假设我们有一个商品列表，有些商品的描述在
<description>
标签里，有些在
<summary>
标签里，我们想一次性获取所有这些描述：
//product/description | //product/summary
或者（XPath 2.0+）：
//product/description union //product/summary
这两种写法都会返回所有商品的描述和摘要节点，且不会有重复。
XPath 1.0和XPath 2.0+版本对联合操作的支持有何不同？
谈到版本差异，这确实是理解
|
和
union
的关键所在。XPath 1.0，作为最广泛使用的XPath版本，它只支持且仅支持
|
作为节点集联合的运算符。这意味着，如果你正在使用的XPath处理器是基于XPath 1.0标准的（比如XSLT 1.0处理器，或者一些老旧的XML解析库），那么
union
关键词是无法识别的，会直接导致语法错误。
而XPath 2.0及后续版本（如XPath 3.0、3.1）则对语法进行了扩展。它们不仅继续支持传统的
|
符号，还引入了
union
这个关键词。引入
union
的主要考量，我认为更多是出于代码可读性和语义清晰度的考虑。在某些复杂的表达式中，
|
可能会与布尔逻辑运算符
or
产生视觉上的混淆（尽管它们的作用域和优先级完全不同），而
union
作为一个明确的关键词，能更直观地表达“合并”的意图。
所以，核心差异在于兼容性：如果你需要确保你的XPath表达式在所有XPath 1.0环境中都能正常工作，那么
|
是唯一的选择。如果你明确知道你的运行环境是XPath 2.0或更高版本，并且你倾向于更具描述性的语法，那么
union
是一个不错的选择。实际使用中，由于XPath 1.0的普及程度，
|
依然是更常见的写法。
在实际开发中，何时选择使用
|
|
，何时选择
union
操作符？
在日常开发中，选择
|
还是
union
，往往取决于你所处的具体环境和团队的编码习惯，但通常会有一些倾向性。
我个人在大多数情况下会倾向于使用
|
。主要原因很简单：兼容性。很多现有的系统、工具链和库仍然停留在XPath 1.0的时代，或者至少对XPath 1.0有最好的支持。例如，如果你在浏览器环境中使用JavaScript的
document.evaluate
方法，它通常是基于XPath 1.0的实现。如果你在XSLT 1.0转换中编写XPath，也只能用
|
。因此，为了最大化兼容性和减少不必要的麻烦，
|
几乎是我的默认选择。它简洁，而且几乎无处不在。
然而，也有一些场景我会考虑
union
：
- 明确的XPath 2.0+环境：如果我确定项目或工具链完全支持XPath 2.0或更高版本（例如，使用XSLT 2.0/3.0处理器，或者某些现代的XML处理框架），并且代码的可读性是首要考量时，
union
可以提供更清晰的语义。它读起来更像自然语言，对于不熟悉XPath符号的团队成员来说，可能更容易理解其意图。
- 团队规范：如果团队内部有明确的编码规范，规定在XPath 2.0+项目中使用
union
以保持一致性，那么我也会遵循。
- 避免视觉混淆：虽然
|
和
or
在XPath中有不同的优先级和上下文，但它们共享同一个符号。在极少数情况下，如果一个非常复杂的表达式中同时包含逻辑OR操作，并且你觉得
|
可能会让读者产生一瞬间的视觉混淆，那么使用
union
可以完全避免这种可能性。但这通常不是一个强烈的驱动因素。
总的来说，如果你不确定环境版本，或者追求最广泛的兼容性，
|
是安全且高效的选择。如果你处于一个现代、明确支持XPath 2.0+的环境，并且注重代码的可读性，那么
union
是一个值得考虑的替代方案。
联合操作在复杂XPath查询中的实际应用场景是什么？
联合操作符在处理现实世界中那些结构不规则、信息分散或需要多条件筛选的数据时，简直是XPath的瑞士军刀。它的核心价值在于“聚合”——将原本散落在不同路径或满足不同条件的节点收集到一起。
以下是一些我经常会遇到的实际应用场景：
-
收集不同层级的标题或内容块： 在一个网页或文档中，标题可能不仅仅是
<h1>
到
<h6>
，还可能有一些特殊的
<div>
或
<section>
被用作内容区域的标题。如果我需要提取所有这些“标题”，我可以这样写：
//h1 | //h2 | //div[@class='section-title']
这能让我一次性抓取到所有这些不同标签但功能相似的节点。
-
处理内容结构的多样性： 比如在一个产品详情页，商品的“价格”信息可能有时在
<span class="price">
里，有时在
<strong id="current-price">
里。为了确保能捕获到价格，无论它藏在哪里，联合操作符就派上用场了：
//span[@class='price'] | //strong[@id='current-price']
这避免了写多条独立的XPath，然后手动合并结果的繁琐。
-
从文档的不同区域收集特定信息： 假设一个新闻页面，文章正文在
<div id="article-body">
里，而相关的图片描述可能在
<div id="gallery-caption">
里。如果我想获取所有段落（
p
标签）和图片描述（
figcaption
标签），我可以：
//div[@id='article-body']//p | //div[@id='gallery-caption']//figcaption
这样，我能在一个查询中，从文档的不同逻辑区域抽取我感兴趣的特定类型节点。
-
根据不同属性值进行筛选并合并： 在一个用户列表中，我可能想选取所有状态为“active”的用户，以及所有角色为“admin”的用户，即便他们可能不是同一个集合：
//user[@status='active'] | //user[@role='admin']
这会返回所有活跃用户和所有管理员用户，如果某个用户既活跃又是管理员，他只会出现一次。
-
处理可选或替代的路径： 有时，一个特定的数据项可能存在于多个可能的路径之一。例如，一个联系电话可能在
<contact/phone>
，也可能在
<contact/mobile>
。为了获取所有电话号码：
//contact/phone | //contact/mobile
这些例子都体现了联合操作符在处理复杂、非标准化或多源数据时的强大能力。它允许我们以一种声明式的方式，高效地聚合来自不同路径或满足不同条件的节点，从而简化查询逻辑，提高XPath表达式的灵活性和鲁棒性。
评论（已关闭）
评论已关闭