XPath的attribute轴怎么选择属性节点？

xpath中的attribute轴和@符号是一回事，@是attribute::的简写形式，两者功能完全相同；在实际使用中，通过//元素/@属性名可直接选取属性节点，如//div/@id；当需要根据属性值筛选时，可结合谓语使用，如//div[@id=’header’]；而在处理带命名空间的xml属性时，需注意命名空间前缀的影响，可通过local-name()函数绕过前缀限制，确保正确选取目标属性节点。

XPath里要选属性节点，用

attribute

轴，也就是我们平时最常见的那个

@

符号，它就是专门干这事的。简单来说，它能让你从一个元素身上，直接揪出它身上的各种属性，比如

id

、

class

、

href

这些。

解决方案

嗯，既然说到了

attribute

轴，那我们得聊聊它到底怎么用。其实，它非常直观。

当你写

//div

，那是选所有

div

元素对吧？那如果你想看

div

上的

id

属性呢？你就可以写

//div/@id

。这里的

@id

，就是

attribute::id

的简写。它会返回所有

div

元素的

id

属性节点。

举个例子，假设我们有这么一段HTML：

<div id="main-content" class="container">   <a href="/about" data-track="true">关于我们</a>   <input type="text" name="username" value="guest"> </div>

你想选

main-content

这个

div

的

id

属性，可以这样：

//div[@id='main-content']/@id

。 或者，你想拿到所有链接的

href

值，那就

//a/@href

。 甚至更细致点，如果你想选那个

input

的

value

属性，就是

//input/@value

。

它就是这么个逻辑，在元素节点后面跟上

/@属性名

，就直接定位到那个属性了。这比你先选元素再取属性值要直接得多，也更符合XPath的哲学——直接定位你想要的数据。

XPath中的attribute轴和@符号，到底是不是一回事？

很多人刚接触XPath时会有点迷糊，

attribute::

和

@

这俩货，看着不一样，用起来效果却一样。它们本质上就是一回事，

@

是

attribute::

的语法糖，也就是个简写形式。

就像我们平时说话，‘你好’和‘您好’，意思差不多，只是一个更正式点。

attribute::

是XPath标准里定义的完整轴名称，它明确地告诉解析器：‘我要沿着属性轴去寻找节点。’而

@

就是为了方便大家快速书写而设计的。

比如，

//div/attribute::id

和

//div/@id

，这俩表达式选出来的结果是完全一样的。

那什么时候用

attribute::

呢？老实说，在绝大多数情况下，大家都会用

@

，因为它简洁高效。但如果你在写一些非常复杂的XPath表达式，或者想让你的表达式在语义上更明确、更易读，尤其是给那些不那么熟悉XPath简写的人看的时候，用

attribute::

可能会显得更‘正规’一些。但日常开发中，

@

是绝对的主流，几乎没人会去特意写

attribute::

，除非是为了教学或者某种特殊的代码规范。

想选带特定属性值的节点？attribute轴怎么帮你筛选？

光能选属性还不够，我们经常需要根据属性值来筛选元素。比如，我想找到所有

class

是

'button primary'

的按钮，或者

data-id

是某个特定数字的元素。这时候，

attribute

轴就得配合谓语（

[]

里的条件）一起用了。

最常见的用法是这样：

//元素名[@属性名='属性值']

。

例如，要找

id

为

'header'

的

div

：

//div[@id='header']

。 注意了，这里

@id

就代表了

id

这个属性节点，然后我们用

=

来判断它的值是不是

'header'

。

再来个稍微复杂点的： 如果你想找所有

input

标签，并且它的

type

属性是

'text'

，同时

name

属性是

'username'

，你可以这么写：

//input[@type='text' and @name='username']

。 这里的

and

就是逻辑与，意味着两个条件都必须满足。当然，你也可以用

or

（逻辑或），或者

not()

（逻辑非）来组合更复杂的条件。 甚至，如果你想找属性值包含某个子串的，比如

href

属性里包含

'download'

的链接，你可以用

contains()

函数：

//a[contains(@href, 'download')]

。

这种结合谓语的用法，才是

attribute

轴真正强大、灵活的地方，也是我们日常工作中用得最多的场景。

XPath的attribute轴，在处理XML命名空间属性时会遇到什么坑？

说到属性，就不得不提XML里的命名空间（Namespace）。虽然现在很多前端项目都是HTML5，不怎么直接玩XML，但万一哪天你遇到一个用了XHTML或者SVG、MathML之类的XML方言的页面，或者后端返回的XML数据，那命名空间这事儿就得注意了。

比如，你可能会看到这样的属性：

<svg:path d="M..." />

，这里的

svg:

就是一个命名空间前缀。 如果你直接用

//svg:path/@d

，理论上是可行的，但前提是你的XPath解析器（或者说你的代码环境）已经正确地解析并映射了

svg

这个前缀到它对应的URI。如果没映射，或者映射错了，你可能就选不到。 更麻烦的是，有些属性本身就带有命名空间，比如

xml:lang

。直接

@lang

肯定是不行的。

这时候，你可以用

local-name()

函数来忽略命名空间前缀，只匹配属性的本地名称。比如，你想选所有属性名为

lang

的属性节点，不管它有没有命名空间前缀，可以这么写：

//@*[local-name()='lang']

。这里的

*

是通配符，表示任何属性节点。 或者，如果你知道命名空间URI，但不想依赖前缀（因为前缀是可变的），你可以结合

namespace-uri()

函数来精确匹配，但这通常会写得很复杂，比如

//@*[local-name()='attrName' and namespace-uri()='http://example.com/ns']

。

不过说实话，在浏览器环境里，对于HTML DOM，命名空间属性的坑相对少一些，因为浏览器通常会把它们扁平化处理。但如果你在处理纯XML，或者一些特定的XML方言，理解并正确处理命名空间属性是XPath进阶的必修课。这块儿稍微有点绕，但弄明白了就能避免很多头疼的问题。