[[385009]]

有一些同學在寫爬蟲的時候，喜歡在Chrome 開發(fā)者工具里面直接復制 XPath，如下圖所示：

他們覺得這樣復制出來的 XPath 雖然長了點，但是工作一切正常，所以頻繁使用。

但我希望大家不要過于依賴這個功能。因為它給出的結(jié)果僅作參考，有時候并不能讓你提取出數(shù)據(jù)。我們來看一個例子。

這是一個非常簡單的HTML 頁面，頁面中有一個表格，表格有一列叫做電話。我現(xiàn)在想把這里面的5個電話提取出來。如果直接使用 Chrome 的復制 XPath 的功能，我們可以得到下面這個 XPath：

/html/body/div/table/tbody/tr[3]/td[4] 

這實際上對應了劉小三這一行的電話字段。那么，我們?nèi)サ魌r后面的數(shù)字，似乎就能覆蓋到所有行了：

/html/body/div/table/tbody/tr/td[4]/text() 

在 XPath Helper 上面運行看看效果，確實提取出了所有的電話號碼，如下圖所示：

但如果你使用 requests 來爬這個網(wǎng)頁，然后使用 XPath 提取電話號碼，你就會發(fā)現(xiàn)什么都提取不到，如下圖所示：

你可能會想，這應該是異步加載導致的問題。表格里面的數(shù)據(jù)是通過 Ajax 后臺加載的，不在網(wǎng)頁源代碼里面。

那么我們打印看看網(wǎng)頁的源代碼：

大家可以看到，數(shù)據(jù)就在網(wǎng)頁源代碼里面，那為什么我們在Chrome 上面通過 XPath Helper 就能提取數(shù)據(jù)，而用 requests 就無法提取數(shù)據(jù)?

實際上，如果大家仔細觀察從 Chrome 中復制出來的 XPath，就會發(fā)現(xiàn)它里面有一個tbody節(jié)點。但是我們的網(wǎng)頁源代碼是沒有這個節(jié)點的。

這就要說到 Chrome 開發(fā)者工具里面顯示的 HTML 代碼，跟網(wǎng)頁真正的源代碼之間的區(qū)別了。很多人分不清楚這兩者的區(qū)別，所以導致寫出的 XPath 匹配不到數(shù)據(jù)。

當我們說到網(wǎng)頁源代碼的時候，我們指的是在網(wǎng)頁上右鍵，選擇“顯示網(wǎng)頁源代碼”按鈕所查看到的 HTML 代碼，如下圖所示：

這個查看源代碼的頁面長成下圖所示的這樣：

注意地址欄，是以view-source:開頭的。這才是網(wǎng)頁真真正正的源代碼。

而Chrome 的開發(fā)者工具里面的Element標簽所顯示的源代碼，長成下面這樣：

這兩個地方的HTML代碼可能是不一樣的，而且在現(xiàn)代化的網(wǎng)站中，這兩個地方的 HTML大概率是不一樣的。當我們使用 requests 或者 Scrapy 時，拿到的是第一種情況的源代碼，這才是網(wǎng)頁真正的源代碼。而在開發(fā)者工具里面的 HTML 代碼，是經(jīng)過 Chrome 瀏覽器修飾甚至大幅度增刪后的 HTML 代碼。當網(wǎng)站有異步加載時，JavaScript 可以輕易在這里增加、刪除非常多的內(nèi)容。即使網(wǎng)站沒有異步加載，如果網(wǎng)站原始的 HTML 代碼編寫不夠規(guī)范，或者存在一些錯漏，那么 Chrome 瀏覽器會自動糾錯和調(diào)整。

以本文的例子來說，在 HTML 的官方規(guī)范里面，表格的正文確實應該包在標簽里面。但現(xiàn)在大多數(shù)情況下，前端開發(fā)者都會省略這個標簽，所以真正的源代碼里面是沒有這個標簽的。而 Chrome 會自動識別到這種情況，然后自動加上這個標簽，所以在開發(fā)者工具里面看到的 HTML 代碼是有這個標簽的。

當你寫爬蟲的時候，不僅僅是 Chrome 開發(fā)者工具里面復制的 XPath 僅作參考，甚至這個開發(fā)者工具里面顯示的 HTML 代碼也是僅作參考。你應該首先檢查你需要的數(shù)據(jù)是不是在真正的源代碼里面，然后再來確定是寫 XPath 還是抓接口。如果是寫 XPath，那么更應該以這個真正的源代碼為準，而不是開發(fā)者工具里面的 HTML 代碼。

本文轉(zhuǎn)載自微信公眾號「未聞Code」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系未聞Code公眾號。