爬蟲實戰技巧-抓取源的選擇

抓取源的選擇對于抓取至關重要，直接關係著抓取的可行性與工作量。選擇合理的抓取源不僅僅能夠節約開發時間，避免很多坑，同時對數據的質量也有一定的保證。

我們要討論的是：對于同一個數據來源，從哪個入口進行抓取，Web端，App端，Wap端？抑或是其他的一些途徑。

這里的Wap是于Web形成對應并區分，指的是移動端Web，并不是狹義的WAP。

很多同志一說到抓取，就想到Web，HTML，然后各種Xpath，正則模板。這是比較複雜累人的方桉，實際上真正的抓取，還有很多其他的方式，這里我們就即將談到，希望看完這篇文章對大家有所幫助。

總結與結論

選擇哪個數據源抓取？

1. 哪個平臺方便哪個
2. 哪個看起來複雜選擇哪個

一般地，我們選擇的優先級降序排列爲：

各平臺內置入口 > Wap（手機瀏覽器） > 自家手機APP > 自家PC > Web

其中，PC端與手機APP無明顯優先級區分，這個排列視抓取團隊對平臺Crack的熟悉程度而定。

怎麼理解上面說的兩點呢？

這個不用舉例子，就能很好的理解。我們從兩個方面來分析：

1. 數據質量的好壞，不僅僅指數據內容的豐富，同時也包含對后期抽取工作的友好度
2. 后期踩坑的多少，就是所謂的反爬遭遇戰，越少越好

第二個標題

抓取分類

可分的種類太多了，這里我們按照數據請求認證的方式簡單的劃分一下，以便內容后面的梳理。

1. 需要帳號和密碼登錄

   • 使用Cookie
   • 使用token

2. 只需使用第三方登錄（有些是第三方只是綁定作用，仍然需要注冊帳號，這個通與第一種類型）

   • 使用token
   • 無需token（不知道有沒有這麼不靠譜的）

3. 無需登錄

   • 使用token（請求的合法性校驗，與帳號維度的token不一樣）
   • 無需token

可以看到無需登錄無需token的是最有可能大批量抓取數據，有反爬也最多只能在IP維度來做，這時候我們拼IP量就能搞定了。

需要帳號和密碼登錄的這種我們要儘量去避免，拋開注冊和登錄時的驗證碼不說，有帳號在對方后臺的，你的每一次請求都能被記錄下來，想封你很容易。

第二種，其實可以作爲最優選擇，第一數據基本都是序列化過的，第二依附第三方（騰訊，新浪等）做認證的自身處理會相對薄弱。

來源詳解

Web端

這個應該是大家最爲熟悉的，也是范圍最廣，最容易發現的抓取來源。基本輸入網址后，我們就能找到想要的數據，這可能是數據規劃或者產品提出來的，仍你一張圖，然后上面圈出哪些數據需要被抓取到。

一般地，數據會通過兩種方式從后臺展示給用戶：

1. 后臺直接將數據內容渲染在HTML中
2. AJAX異步請求獲得數據，在前端渲染

區別方式很簡單，右鍵查看源碼，或者在瀏覽器網址前面，鍵入:view-source:，在HTML源碼中能找到你想要的數據的話那就是第一種方式，如果要抓，那直接拼上URL就完事。

第二種方式又可分為兩種形式，第一種是返回的以JSON形式序列化好的數據；還有一種是比較坑的后臺程序員寫的（這個鍋其實后臺同學不背，主要是前端同學偷懶，想直接要HTML），返回的依然是HTML的片段。對于抓取而言，這兩者的區別主要是在數據抽取的階段，同時對遭遇反爬的判斷，或者接口變動的發現都有著很明顯的優勢。

實際上，我們左右不了人后臺數據的返回形式，但是我們可以當作參考，用來篩選對我們抓取工作最有利的途徑。

這里無論數據是一次性直接從HTML中返回回來的，還是異步加載的，他們走的都是對方Web端對外接口，通常情況下，這里會有比較嚴格反爬策略，稍微異常就直接跳轉給你驗證碼。

當然，異步返回數據的這種方式，有些會在這里做請求合法性的驗證，你直接把數據請求從瀏覽器發出去，并不能得到真正的數據。

從某個角度來說，這其實是件好事情，因為一般在驗證方面做足了工作的，大部分不太會在反爬上投入太多的精力，這也就是意味著，我們的抓取速度從某個角度來說，是能夠得到保證。

順便提下，不要看到異步加載的數據第一反應就是上headless瀏覽器這種去渲染出html然后又去抽內容。與其花個把小時去寫腳本，還不如花些時間，研究研究他后臺數據的接口，有沒有數據請求的驗證，是怎麼驗證，然后用代碼去實現，直接請求接口的數據。不但能大大提高抓取速度，同時還節省了一大堆資源，帶寬、cpu、內存。想想你爲了請求一條幾個字節的評論數，你非得多請求人家服務器幾百Kb的數據下來，何必呢，傷人傷己。

當然有一種情況除外，對方的反爬系統使用靜態資源的請求比例來分析是否是爬蟲，那咱得上phantomjs之流，但也只限于需要帳號才能抓的數據，并且你的帳號數量還極其有限的情況才考慮去用。如果是這種情況，其實也沒必要死磕在從Web端抓了。

Wap端

這個并不是所有你想抓的站點都會有的，像一些政府的基本沒有，好在大部分的商業公司都有這條產品線，畢竟這是流量最高，入侵性最低的流量入口了；比如，新浪微博、雪球、喜馬拉雅等等，他們都有自己手機Wap端產品。

那Wap端對比Web端優勢在哪里呢？
答案是，結構化的數據接口的存在可能性更大！

由于移動端網絡的特殊性，所以一般只要稍微靠譜點的產品，都會將Wap端涉及成異步加載數據的方式，儘量減小請求的大小，降低請求的發送頻率，

在抓取前期，做抓取源的選擇時，要區分到底有沒有Wap端其實很簡單，兩種方式：

1. 手機瀏覽器直接打開
2. 瀏覽器調試工具，選擇模擬移動設備

這個時候你看到的頁面如果很“友好”，那基本上就可以說明他是獨立與Web端的，存在數據接口的可能性會更大。當然，也有響應式的前端設計，就一套前端代碼，基本這種肯定有單獨的數據接口，和Web端一樣。

上面提到了，這個的優點就是，可能具有結構化的數據接口，方便抓取與抽取工作。與此同時，從反反爬的角度來說，我據經驗猜測IP的次數上線會稍高與Web端，這一點沒有可靠的依據，畢竟在反爬引擎中，這隻是一個配置的事情，甚至是動態的無需人爲干預，做反爬的同志們可以斧正。

不管怎樣，具有單獨的數據接口，這一點已經足夠支撐我們從這里著手抓取的工作。

手機端

按照主流平臺，一般我們特指iOS與Android，我們不會像搞安全的同志們一樣，都去研究，我們選擇成本最低的方向來做，所以一般地，Android的APP是我們的首選。

毋庸置疑，99%的APP都是有單獨的數據接口，其中對于我們想要的數據90%d的是通過HTTP方式進行傳輸，其馀的是TCP。TCP這個涉及協議分析這一塊，耗時耗力，基本抓取不會考盧直接從請求中去拿數據，后面我會詳細地介紹這種的數據應該怎麼去拿。

基本上，HTTP接口的數據，咱們抓個包就能知道接口是什麼樣子，需要哪些驗證參數。
一般情況下，不會直接一個光著的HTTP露在外面，請求里面會帶著各種Key，Token什麼的，這些邏輯的處理都是在APP的代碼里，所以咱們得花時間去逆向他的代碼。

上面說的還是理想情況下，絕大多數的商業公司的產品，數據接口都走的是HTTPS，如果僅僅是如此那也不打緊，咱們該抓包抓包；但是哇，有那麼一波靠譜的系統設計在一些公司里，給這些接口套了雙向驗證，咱沒法通過中間人的方式去抓包了，因爲證書不對，他不認，直接拒絕連接，這個時候我們必定只有一條逆向之路了。

上面羅嗦了半天，無非就是，APP端有接口好，封IP可能性較低，但是哇，耗時耗力，但是如果能一天夠定各種驗證，找到接口的請求方式那還是很劃算的。

平臺入口

最典型的微信里面的入口，很多公司的產品會使用微信登錄，或者直接在公衆號里面提供入口。從一個角度來說，這等同于Wap端的產品，但是區別在于，很多產品是直接通過微信去登錄驗證的，直接可以避免注冊登錄的過程。微信小程序這個我目前還沒有涉及到過，暫時不做討論。

優點還是那兩個，數據格式好，被封概率低；缺點也很明顯，走大平臺的驗證邏輯，Crack起來很不好做，但是，大廠是靠譜，可是小公司可能會是豬隊友，人騰訊明明給了那麼幾進無懈可擊的認證方桉，愣是在自己后臺有涉及漏洞，那這個絕對是數據最優的選擇。

比如，微信用于認證跳轉的URL類似于https://open.weixin.qq.com/connect/oauth2/authorize?appid=wxe74839f******&redirect_uri=http://xx.xxx.com&response_type=code&scope=snsapi_base&state=456&connect_redirect=1#wechat_redirect，經過這個URL認證過的請求，就相當于登錄過了。現在有不少公司的產品，從微信入口進去會獲得比Web端更好的內容體驗，這自然也會是抓取的福音，畢竟傳統Web登錄繁瑣，反爬嚴格。

對比分析

這里用一個表格記錄各項指標分數，以做對比：

PC客戶端個人暫時還沒有遇到真正的數據抓取，之前幾款要麼是內嵌WebView的，要麼是直接讀取臨時文件就能搞定的，這里不納入個人評價。

論述結束

這一篇算是囉哩囉唆半天，實際沒有說到什麼很技巧的東西，后面會從這里談到的內容，從實際例子出發去分析，怎麼做，如何做。

前言

根據前面所列的大綱，我們即將會講到《數據抓包的方式與方法》。希望我繼續寫的請自行處理，不希望的請通過一些方式聯繫我：

1. 微信: rustgolang
2. 微博[當作IM]: 我愛問財