starts-with()函数用于判断字符串是否以指定子串开头，返回布尔值，常用于xpath中精准定位具有固定前缀的动态属性值；其语法为starts-with(String, substring)，第一个参数为待检测字符串，第二个为期望的开头子串；例如//div[starts-with(@id, ‘product-item-‘)]可选中id以“product-item-”开头的所有div元素；该函数区分大小写，需注意大小写匹配问题；与contains()的区别在于，starts-with()仅匹配开头位置，而contains()可匹配子串在任意位置的出现；实际应用中可用于处理动态类名、url筛选及文本内容定位；在处理中文或特殊字符时，只要文档编码正确（如utf-8），通常能正常工作，主要问题多源于编码不一致或隐藏字符干扰。
XPath的starts-with()函数，简单来说，就是用来判断一个字符串是否以另一个指定的字符串开头。它会返回一个布尔值，也就是真（true）或假（false）。这个函数在处理那些有规律但又不完全固定的文本或属性值时，简直是神器。在我日常处理各种网页数据时，它出现的频率非常高，因为它能帮我精准地定位到那些虽然ID或类名有变动，但总有那么一小截是固定前缀的元素。
starts-with()函数的使用与解析
要说starts-with()，它的语法其实挺直观的：starts-with(string, substring)。这里面的string是你想要检查的那个完整字符串，而substring则是你期望它开头的那部分内容。
举个例子吧，假设我们有这么一段html：
<div id="product-item-101" class="item-card">产品A</div> <div id="product-item-202" class="item-card">产品B</div> <span id="ad-banner-1">广告位1</span>
如果我想选中所有ID以“product-item-”开头的div元素，我的XPath表达式就会是这样：//div[starts-with(@id, ‘product-item-‘)]。
这行代码的逻辑就是：找到所有的div元素，然后筛选出那些它们的id属性值是以“product-item-”开头的。这样，无论后面的数字是多少，只要前缀对得上，它就能被选中。这在很多动态加载或者后端自动生成ID的场景下特别有用。
需要注意的是，starts-with()是区分大小写的。也就是说，如果你写starts-with(@class, ‘Item-card’)，它是不会匹配到class=”item-card”的。这一点在实际使用中，尤其是面对不规范的数据源时，是需要特别留心的。有时候为了应对大小写不一致的问题，可能需要结合translate()函数来做大小写转换，但那又是另一个话题了。
starts-with() 与 contains() 有何不同？
这是个经常被问到的问题，也确实是XPath初学者容易混淆的地方。在我看来，它们的核心区别在于“匹配位置”：
- starts-with()：它只关心字符串的开头部分。就像它的名字一样，是不是“以……开始”。如果目标字符串的开头不是你指定的子字符串，那它就直接返回false，不再往后看了。
- contains()：这个函数就宽泛多了，它关注的是字符串任意位置是否包含指定的子字符串。只要目标字符串里有那么一段是匹配的，无论是在开头、中间还是结尾，它都会返回true。
还是用刚才的例子：
- //div[starts-with(@id, ‘product’)] 会选中id=”product-item-101″和id=”product-item-202″。
- //div[contains(@id, ‘item’)] 同样会选中这两个div，因为它俩的ID里都包含了“item”。
- 但是，如果我写//span[starts-with(@id, ‘banner’)]，它什么也选不中，因为id=”ad-banner-1″不是以“banner”开头的。
- 而//span[contains(@id, ‘banner’)] 就能选中id=”ad-banner-1″，因为“banner”确实在它的ID里。
所以，选择哪个函数，完全取决于你的实际需求。如果你知道你想要匹配的模式总是在开头，那么starts-with()无疑是更精确、效率更高的选择。如果你只是想知道某个字符串是否存在于目标中，不管它在哪，contains()就是你的朋友。
如何在实际抓取中有效利用 starts-with()？
在实际的数据抓取或者自动化测试场景中，starts-with()能发挥的作用远不止匹配ID那么简单。
一个非常典型的应用场景是处理动态生成的类名或URL。很多网站为了反爬或者实现某些前端效果，会给元素生成一些带有随机后缀的类名，比如class=”btn-primary-abcdef”、class=”btn-primary-ghijkl”。这时候，你不可能去写死完整的类名，但如果所有的主要按钮都以btn-primary-开头，那//button[starts-with(@class, ‘btn-primary-‘)]就能一网打尽。
再比如，我们想抓取某个网站上所有指向特定产品目录的链接。如果所有的产品页面URL都长这样：https://example.com/products/item-123，https://example.com/products/item-456，那么我就可以用//a[starts-with(@href, ‘https://example.com/products/’)]来精准地筛选出这些链接，而不用担心后面跟着的商品ID是什么。
另外，在处理一些文本内容时，starts-with()也很有用。比如，你可能想找到所有以“优惠活动：”开头的公告，那么//p[starts-with(text(), ‘优惠活动：’)]就能帮你快速定位。当然，这要求文本内容本身比较规范。
它的价值在于，它提供了一种“模糊匹配”的能力，但这种模糊又是有边界的，它只在开头生效。这使得我们能够应对一些数据结构上的不确定性，同时又保持了匹配的精确性。
starts-with() 在处理中文或特殊字符时需要注意什么？
关于starts-with()在处理中文或特殊字符时的表现，我的经验是，在绝大多数现代的XPath解析器中，它对Unicode字符（包括中文、日文、韩文以及各种符号）的支持是相当好的，通常不会出现什么问题。
XPath 1.0规范本身就支持Unicode，所以只要你的xml/HTML文档编码正确（比如UTF-8），并且你的XPath解析器也正确地处理了编码，那么starts-with(‘你好世界’, ‘你好’)会正常返回true。
不过，这里面有几个细微但重要的点需要注意：
- 文档编码一致性：最常见的“坑”其实不是starts-with()函数本身的问题，而是源文档的编码问题。如果HTML文件声称是UTF-8，但实际内容却是GBK编码，或者你在读取文件时没有指定正确的编码，那么解析器在读取字符串时就可能出现乱码，进而导致starts-with()无法正确匹配。这通常是I/O层面的问题，而非XPath函数的问题。
- 特殊字符的转义：极少数情况下，如果你要匹配的substring中包含XPath语法中的特殊字符（如’、”、[、]等），你可能需要进行适当的转义。但这在starts-with()的字符串参数中并不常见，因为通常我们匹配的是字面量。更常见的是在构建整个XPath表达式时需要注意。
- 视觉与实际字符：有时，肉眼看起来一样的字符，在底层编码上可能有所不同。例如，全角空格和半角空格，或者某些看起来一样的连字符。starts-with()会严格按照字符的Unicode码点进行比较。如果你的数据源不规范，可能需要先对字符串进行normalize-space()处理，或者预处理掉一些不可见的控制字符，以确保匹配的准确性。
总的来说，对于中文和大部分常用特殊字符，只要你的环境和数据流是健康的，starts-with()通常都能正常工作，无需过度担心。真正的挑战往往在于数据源本身的“脏”和不一致。
