答案：XPath中comment()函数用于选择注释节点，与text()不同，前者提取内的内容，后者获取元素内的文本；可通过//comment()获取所有注释，或结合轴、谓词和字符串函数精确筛选目标注释。
XPath中，
comment()
函数专门用来选择文档中的注释节点。它就像一个过滤器，只把那些被
<!-- ... -->
包裹起来的内容找出来，而忽略元素、属性或文本节点。
解决方案
说实话，处理XML或HTML里的注释节点，XPath的
comment()
函数是个非常直接的工具。它不关心注释里面写了什么，只要是注释，它就能帮你抓出来。
最基础的用法，如果你想获取文档中所有的注释节点，无论它们藏在哪里，直接用
//comment()
就行了。这就像在整个文档里撒网，所有符合“注释”这个条件的，都会被捞上来。
<!-- 这是一个全局注释 --> <root> <element> <!-- 元素内部的注释 --> <item>内容</item> </element> <!-- root下的另一个注释 --> </root>
对应上面的XML，
//comment()
会返回三个注释节点。
如果你只想获取特定元素下的注释，那路径就得具体一点。比如，只想找
<element>
元素下面的注释，可以写成
/root/element/comment()
。这会只返回“元素内部的注释”那个节点。
有时候，我们不光要找到注释，可能还想看看它里面写了什么。XPath的强大之处在于，找到节点后，你还能对其内容进行判断。虽然
comment()
本身只是选择节点，但你可以通过谓词（
[]
）来进一步筛选。比如，你想找内容包含特定文本的注释，就可以这么写：
//comment()[contains(., '特定文本')]
。这里的
.
代表当前节点（也就是注释节点）的字符串值。
这听起来简单，但在实际操作中，注释的内容往往很随意，可能包含换行符、多余空格，甚至是一些非标准字符。所以，精确匹配有时候会是个小挑战。我的经验是，如果注释内容是人工维护的，那往往不那么规范，需要多尝试几种匹配方式。
如何精确筛选特定内容的注释节点？
要精确筛选特定内容的注释节点，光靠
comment()
本身是不够的，我们需要结合XPath的字符串函数和谓词来做文章。这就像给你的渔网加上了更细的网眼，只捕捞你真正想要的“鱼”。
最常用的方法就是使用
contains()
函数。比如，你有一个注释写着
<!-- 用户信息：张三 -->
，你想找到所有包含“用户信息”的注释，可以这样写：
//comment()[contains(., '用户信息')]
。这里的点号
.
代表当前注释节点的内容。
但如果你的注释内容很长，或者有多种变体，比如
<!-- User Info: John Doe -->
和
<!--用户信息：李四-->
，你可能需要更灵活的匹配方式。XPath 2.0及更高版本提供了
matches()
函数，它支持正则表达式，这简直是精确匹配的利器。例如，
//comment()[matches(., '用户(信息|数据)')]
可以匹配包含“用户信息”或“用户数据”的注释。不过，要注意的是，很多老旧的XPath解析器（比如一些浏览器内置的）可能只支持XPath 1.0，那就用不了
matches()
了。
还有一种情况，注释内容可能包含多余的空格或者换行符。例如：
<!-- 这是一个 多行注释 -->
如果你直接用
contains(., '多行注释')
，通常是没问题的，因为XPath在处理字符串值时会把这些空白字符都包含进去。但如果你想匹配一个非常精确的字符串，比如“多行注释”，而注释里实际是“ 多行注释 ”（前面有空格），那你就得小心了。有时候，我会先用
normalize-space()
函数来清理注释内容的空白，再进行匹配，比如
//comment()[contains(normalize-space(.), '多行注释')]
。这样可以避免因为空白字符导致的匹配失败。但也要考虑实际情况，如果注释里故意留白是为了格式，那么
normalize-space()
可能会破坏你的意图。
所以，我的建议是，在编写匹配规则时，先仔细检查目标注释的实际内容，包括其内部的空白和换行符，再选择最合适的函数。
XPath的comment()与文本节点选择有何不同，何时使用它们？
comment()
和
text()
是XPath中两个非常重要但又截然不同的节点类型函数，它们各自有明确的职责。简单来说，
comment()
是找
<!-- ... -->
这种形式的注释，而
text()
是找元素标签之间或属性值里的纯文本内容。它们俩是“井水不犯河水”的。
比如说，你有这样的XML：
<product> <!-- 商品描述 --> 这是商品的具体描述。 <price>100</price> </product>
如果你用
//product/comment()
，你会得到“商品描述”那个注释节点。 但如果你用
//product/text()
，你会得到“这是商品的具体描述。”这部分文本。注意，
text()
只会返回直接子文本节点，像
<price>100</price>
里面的“100”就不是
<product>
的直接文本子节点，你需要用
//product/price/text()
才能取到它。
什么时候用哪个呢？这取决于你的目标。
-
使用
comment()
： 当你需要获取文档中那些不直接参与数据结构、但可能包含元信息、调试信息、版权声明或者其他非结构化备注时。例如，网页抓取时，有些网站会把一些动态加载的URL或者API密钥放在注释里；或者在XML配置文件中，开发者会用注释来解释某个配置项的用途。这时候，
comment()
就是你的首选。它帮你把那些“悄悄话”找出来。
-
使用
text()
： 当你需要提取元素内部的实际数据内容时。这是最常见的用法，比如从网页上抓取文章标题、商品价格、用户评论等。
text()
关注的是用户可见或业务逻辑相关的文本信息。
它们最大的不同在于语义和结构角色。注释是对文档的解释或备注，不属于文档的“内容”本身；而文本节点就是文档的“内容”。混淆它们会导致你获取到错误的数据，或者错过重要的信息。我的看法是，理解它们的本质差异，才能在复杂的文档结构中游刃有余地提取所需信息。有时候，一个元素内部既有文本又有注释，比如
<div><!-- 注释 -->一些文本</div>
，你需要分别使用
comment()
和
text()
来获取它们。
处理复杂或嵌套结构中的注释节点有哪些高级技巧？
处理复杂或嵌套结构中的注释节点，不仅仅是找到它们，更重要的是理解它们与周围元素的相对位置和上下文关系。这就像在地图上找一个地标，不光要知道地标的名字，还要知道它在哪个街区，旁边有什么建筑物。
一个常见场景是，你可能想找到某个特定元素“前面”或者“后面”的注释。XPath提供了轴（axes）来描述节点之间的关系。
-
preceding-sibling::comment()
： 查找当前节点之前的所有同级注释节点。比如，你想找到一个
<title>
元素前面紧挨着的注释，可以这样写：
//title/preceding-sibling::comment()[1]
（
[1]
表示取最近的那个）。
-
following-sibling::comment()
： 查找当前节点之后的所有同级注释节点。类似地，
//title/following-sibling::comment()[1]
会找到紧跟在
<title>
后面的注释。
这在处理一些前端框架生成的HTML时特别有用，它们可能在组件的开始或结束位置插入注释，用于调试或标记。
再复杂一点，如果注释不在同级，而是在某个祖先或后代中，但你又想根据某个特定的元素来定位它，那就要结合路径和谓词了。例如，你想找到所有包含“重要”字样的注释，但这些注释必须是某个
<section id="main">
元素内部的，不论它嵌套多深：
//section[@id="main"]//comment()[contains(., '重要')]
。这里
//
表示“任意后代”，它能穿透多层嵌套。
有时候，注释可能作为某个元素的第一个或最后一个子节点出现。你可以用
*[1]
或
last()
这样的位置谓词来定位：
//div/comment()[1]
：获取
div
下的第一个子注释节点。
//div/comment()[last()]
：获取
div
下的最后一个子注释节点。
另一个比较有意思的场景是，注释本身可能包含一些看起来像路径或者ID的信息。比如：
<!-- related-to: product-id-123 -->
。你可以提取这个“product-id-123”然后用它来做进一步的查询。这通常涉及到在XPath结果上进行字符串处理，或者在XPath 2.0+中使用更复杂的正则匹配来提取子串。
我的经验告诉我，处理这些“隐藏”在注释里的信息，关键在于灵活运用XPath的轴、谓词和字符串函数。它们能让你像外科医生一样精准地定位和提取信息，即使这些信息被包裹在看似无关的注释里。但切记，注释的内容结构往往不规范，所以你的XPath表达式可能需要比处理标准元素内容时更具容错性。
评论（已关闭）
评论已关闭