一晚上做了一个xpath终结者：xpath-helper-plus

前言

作为一个资深『xpath』提取工程师，想要快速从页面中拿到数据，肯定需要借助一些工具，
而最初接触的就是xpath-helper这块浏览器插件。使用一段时间后，发现笔者有一些特别的需求，想在此基础上扩展一下。
于是乎就学习了如何开发chrome插件？如何使用自己属性的vue来开发？经过双休一顿文档、gayhub了解之后，有了这样一款工具。

问题

xpath-helper2.0.2原生是支持按住shift后通过鼠标来定位选择元素，并输出xpath语法，但是这种方式出来的xptah语法并不友好。

比如说我想拾取掘金的某个文章标题：

/html/body/div[@id=‘__nuxt’]/div[@id=‘__layout’]/div[@id=‘juejin’]/div[@class=‘view-container container’]/main[@class=‘container main-container with-view-nav’]/div[@class=‘view timeline-index-view’]/div[@class=‘timeline-container’]/div[@class=‘timeline-content’]/aside[@class=‘index-aside aside’]/div[@class=‘signin-tip signin’]/div[@class=‘first-line’]/button[@class=‘btn signin-btn’]/span[@class=‘btn-text’]

它出来了一个xpath语法，这个xpath语法是从DOM根节点开始逐一向下(源码是从下至上)来拼接的。这样就会变成十分地冗余。
虽然它的确能够精准定位到我们想要的元素，但是一旦把这样的xpath语法复制到代码里，是十分可怕的。

当然还有一部分程序员热衷于选择使用chrome原生的元素复制成xpath。

出来的结果是：

//*[@id=“juejin”]/div[1]/main/div/div/div/aside/div[1]/div[1]/button/span

显然以上两种方案都有其问题：语法冗余、毫无可读性。

解决

笔者给出的解决方案是在xpath-helper基础上，增加一个辅助功能，它可以最大化精简xpath语法，一旦发现其语法能够识别到该元素就不再继续往上查找。而是立刻返回。

//span[@class=‘btn-text’]

并且它也可以友好的转为css选择器语法：

span.btn-text

我们可以在chrome的元素中检查这个语法：

• xpath:
  
• css:
  

实现

xpath-helper-plus其核心API均来自于xpath-helper。

笔者在此基础上增加了一些额外的功能，比如：精简xpath语句、转化CSS选择器。

与原有的xpath helper不同的是，这次chrome插件采用Vue3+vite来开发，面向组件，通过vite打包成chrome插件规范的文件目录结构。
未来可能会提供更多的功能。或者在此基础上开发其他插件。

开源

https://github.com/mic1on/xpath-helper-plus