我第一次接觸XPath是在2007年，但最近才開始對它產(chǎn)生興趣。以前在大多數(shù)情況下我都會盡量避免使用它，而當我不得不嘗試使用它時，每次都以失敗告終。那時XPath對我來說并沒有什么意義。

但是后來我遇到了一個特殊的解析問題（對CSS選擇器來說過于復雜，而用手工代碼的話又過于簡單），于是我決定再嘗試一次XPath。令我感到驚喜的是，這的確行得通，而且很有用。

以下是我的親身經(jīng)歷

我遇到的問題

假設(shè)你管理一個歌詞網(wǎng)站，為了維持一致的閱讀體驗，你要收集每行歌詞的第一個單詞。如果歌詞使用純文本格式保存，那么可以直接用下面的代碼來實現(xiàn)。

lyrics.gsub!(/^./) { |character| character.upcase } 

但是如果歌詞被保存肯html格式就沒有這么簡單了，因為dom結(jié)構(gòu)本身并沒有”行”的概念，所以沒有辦法使用一個簡單的正則表達式來識別行。

所以我們要做的第一件事情是定義什么是dom結(jié)構(gòu)中的“行的起點”，下面是兩個簡單的例子：

• <p>標簽中第一個文本節(jié)點
• <br>后面的第一個文本節(jié)點

就像下面這樣:

<p>This is the beginning of a line.This is too.</p> 

但是除此之外我們可能還要處理嵌套的行內(nèi)元素：

<p><em>This</em> is the beginning of a line. <strong>This is not.</strong></p> 

常規(guī)的解決方案

我想到的第一個解決方法是用Ruby寫一個方法來掃描dom中所有相關(guān)的部分并遞歸找出所有符合條件的節(jié)點。其中用到了幾個輕量級的css選擇器：

def each_new_line(document)  
  document.css('p').each { |p| yield first_text_node(p) }  
  document.css('br').each { |br| yield first_text_node(br.next) }  
end  
   
def first_text_node(node)  
  if node.nil? then nil  
  elsif node.text? then node  
  elsif node.children.any? then first_text_node(node.children.first)  
  end  
end 

這是一個比較合理的解決方案，但是11行的代碼似乎有點兒長。有點兒殺雞用牛刀的感覺，僅僅為了獲得dom的節(jié)點而用上Ruby的迭代器和條件語句感覺有點兒犯不上。應該有更好的辦法吧？

終于說到正題了（XPath）

XPath有一下幾個原因容易讓人困惑。第一點是網(wǎng)上幾乎沒有可以參考的東西（W3Schools！就不用想了）。RFC已經(jīng)是我找到的最好的文檔了。

第二點是XPath看上去有點兒像CSS。方法名里就有“path”，所以我總是假設(shè)XPath的表達式中的 / 和CSS選擇器中的 > 是一個意思。

document.xpath('//p/em/a') == document.css('p > em > a')  

其實，XPath表達式包含了許多簡寫，如果我們想要弄清楚上面代碼運行時究竟發(fā)生了什么就必須要弄清楚這些簡寫。下面是用全拼寫出來的相同的表達式：

/descendant-or-self::node()/child::p/child::em/child::a/  

這個XPath表達式和上面的CSS選擇器的作用是一樣的，但并不像我之前假設(shè)的那樣。一個XPath表達式是由一個或多個被 / 分割的定位步（location steps）組成。表達式中的第一個 / 代表了文檔（document）的根節(jié)點。每個定位步都表明了已經(jīng)被匹配的節(jié)點并傳達一下三條信息：

我想從當前的位置移動到哪？

答案是軸（Axis），是可選的。默認的軸是child，表示“當前被選中節(jié)點的所有子節(jié)點”。在上面的例子中，descendant-or-self是第一個定位部的軸，表示“所有當前被選中的節(jié)點和他們所有的子節(jié)點”。大部分XPath規(guī)范中定義的軸都有像“descendant-or-self”這樣的語義化的名字。

我想要選擇什么類型的節(jié)點？

選擇的內(nèi)容是由節(jié)點測試來指定的，這也是每個定位步中不可缺少的部分。在我們之前的例子中，node()匹配的是全部類型；text（）匹配到的是文本節(jié)點；element()只能匹配到元素，并必須指明節(jié)點名稱（像p,em等），節(jié)點名稱必填。

可能增加額外的過濾器嗎？

也許我們只想選擇當前所有節(jié)點的第一個子元素或只想選則有href屬性的<a>標簽。對于此類斷言（assertion），我們可以使用謂詞（predicates）根據(jù)額外的遍歷樹（additional tree traversals）來過濾出符合條件的節(jié)點。這樣我們就可以根據(jù)這些節(jié)點的屬性（children, parents, or siblings）來過濾出符合條件的節(jié)點。

我們的例子中沒有謂詞，現(xiàn)在讓我們來加一個只匹配有href屬性的<a>標簽：

/descendant-or-self::node()/child::p/child::em/child::a[attribute::href]  

雖然謂詞看上去很像一個括號中的定位步，但是謂詞中的“節(jié)點測試（node test）”部分有比定位步中的節(jié)點測試更多的功能。

#p#

換一個角度來看XPath

與一個增強型的CSS選擇器相比，XPath與JQuery的便利更相似。例如，我們可以把之前的XPath表達式換成JQuery的形式：

$(document).find('*').  
  children('p').  
  children('em').  
  children('a').filter('[href]')  

上面的代碼中，我們用到的JQuery的方法與軸的作用是一樣的：

.children()相當于軸中的child，.find()相當于descendant。 

JQuery方法中的選擇器相當于XPath中的節(jié)點測試，只可惜jQuery不允許選擇文本節(jié)點。

jQuery中的.filter()方法相當于XPath中的謂詞，.children(‘em’)的作用是匹配所有匹配到的<p>標簽中的所有<em>子元素。這樣看來，XPah要比jQuery強大得多。

讓我們回到識別行首的問題

現(xiàn)在我們對XPath的工作原理已經(jīng)有了深入的了解，下面來用它解決之前提到的問題。首先我們先把問題簡化一下，只尋找每段的第一個文本節(jié)點：

/descendant-or-self::node()/child::p/child::text()[position()=1]  

上面的代碼的作用依次是：

• 1.尋找文檔中的所有節(jié)點
• 2.尋找這些節(jié)點的所有為<p>的子節(jié)點
• 3.尋找這些<p>的文本子節(jié)點
• 4.只保留這些節(jié)點中符合條件的第一個元素

注意position() function 在代碼中表示的是每個<p>中的第一個文本子節(jié)點而不是整個文檔中的第一個<p>的文本子節(jié)點。

接下來，為了找到<p>中被嵌套得很深的文本節(jié)點，我們把child換成descendant

/descendant-or-self::node()/child::p/descendant::text()[position()=1]  

接下來是識別換行的問題，首先我們給這一長串代碼折下行（因為太長了），XPath是允許這樣做的。加入換行的識別后，代碼如下：

/descendant-or-self::node()/  
child::br/  
following-sibling::node()[position=1]/  
descendant-or-self::text()[position()=1]  

每一行代碼的意思分別是:

• 1.找到所有節(jié)點
• 2.找到到這些節(jié)點的<br>子節(jié)點
• 3.找到這些<br>的下一個同級節(jié)點
• 4.如果上面取到的不是文本節(jié)點，則取它們的子節(jié)點中的第一個文本節(jié)點

這樣一來我們就可以同時選出<p>中和<br>后的新的一行。下面我們以上的代碼合并成一個表達式：

(/descendant-or-self::node()/child::p|  
/descendant-or-self::node()/child::br/following-sibling::node()[position=1])/  
descendant-or-self::text()[position()=1]  

最后我們把簡寫替換進去：

(//p|//br/following-sibling::node()[position=1])/  
 descendant-or-self::text()[position=1]  

這樣我們就把一個復雜的概念用一個簡單的表達式表示出來了。如果我們想加入更多的對行的操作，只需要往實現(xiàn)匹配的代碼中加入更多的元素名稱就可以了。

我們究竟能從中獲得什么？

既然我們能用相對易懂的Ruby來實現(xiàn)為什么還要選擇XPath呢？

大多數(shù)情況下，Ruby是用來編寫高水平代碼的，例如商業(yè)邏輯，整合應用組件，描述復雜的領(lǐng)域模型。從中可以看出最好的Ruby代碼是用來描述意圖而非用于實現(xiàn)。所以用Ruby來做一些低水平或與應用無關(guān)的事情（遍歷dom樹來找指定屬性的節(jié)點）讓人蛋疼。

XPath的其中一個優(yōu)勢是它的速度：XPath的遍歷是通過libxml實現(xiàn)的，而原生代碼的速度是非常快的。對于我上面舉的例子，與Ruby的實現(xiàn)相比，XPath實際上要慢得多。我猜導致這個情況的原因是對于<br>標簽的下一個元素的查找。因為在這個動作中實際上是先篩選出了<br>后面的所有與之同級的元素然后才過濾出其中的第一個。

所以XPath快慢與否取決于你的使用方式，但是上手有點兒難。這是一個專門用來讓你使用簡潔的慣用表達式來遍歷dom的工具。

原文鏈接： rapgenius   翻譯： 伯樂在線 - 楊帥

譯文鏈接： http://blog.jobbole.com/58160/