網路爬蟲（Web Crawler, Spider）就是一個在網路上亂爬的機器人。當然它通常並不是一個實體的機器人，因為網路本身也是虛擬的東西，所以這個“機器人”其實也就是一段程式，並且它也不是亂爬，而是有一定目的的，並且在爬行的時候會蒐集一些資訊。例如 Google 就有一大堆爬蟲會在 Internet 上搜集網頁內容以及它們之間的連結等資訊；又比如一些別有用心的爬蟲會在 Internet 上搜集諸如 foo@bar.com 或者 foo [at] bar [dot] com 之類的東西。除此之外，還有一些定製的爬蟲，專門針對某一個網站，例如前一陣子 JavaEye 的 Robbin 就寫了幾篇專門對付惡意爬蟲的 blog （原文連結似乎已經失效了，就不給了），還有諸如小眾軟體或者 LinuxToy 這樣的網站也經常被整個站點 crawl 下來，換個名字掛出來。其實爬蟲從基本原理上來講很簡單，只要能訪問網路和分析 Web 頁面即可，現在大部分語言都有方便的 Http 客戶端庫可以抓取 Web 頁面，而 HTML 的分析最簡單的可以直接用正規表示式來做，因此要做一個最簡陋的網路爬蟲實際上是一件很簡單的事情。不過要實現一個高質量的 spider 卻是非常難的。
爬蟲的兩部分，一是下載 Web 頁面，有許多問題需要考慮，如何最大程度地利用本地頻寬，如何排程針對不同站點的 Web 請求以減輕對方伺服器的負擔等。一個高效能的 Web Crawler 系統裡，DNS 查詢也會成為急需優化的瓶頸，另外，還有一些“行規”需要遵循（例如 robots.txt）。而獲取了網頁之後的分析過程也是非常複雜的，Internet 上的東西千奇百怪，各種錯誤百出的 HTML 頁面都有，要想全部分析清楚幾乎是不可能的事；另外，隨著 AJAX 的流行，如何獲取由 Javascript 動態生成的內容成了一大難題；除此之外，Internet 上還有有各種有意或無意出現的Spider Trap ，如果盲目的跟蹤超連結的話，就會陷入 Trap 中萬劫不復了，例如這個網站，據說是之前 Google 宣稱 Internet 上的 Unique URL 數目已經達到了 1 trillion 個，因此這個人 is proud to announce the second trillion 。 
不過，其實並沒有多少人需要做像 Google 那樣通用的 Crawler ，通常我們做一個 Crawler 就是為了去爬特定的某個或者某一類網站，所謂知己知彼，百戰不殆，我們可以事先對需要爬的網站結構做一些分析，事情就變得容易多了。通過分析，選出有價值的連結進行跟蹤，就可以避免很多不必要的連結或者 Spider Trap ，如果網站的結構允許選擇一個合適的路徑的話，我們可以按照一定順序把感興趣的東西爬一遍，這樣以來，連 URL 重複的判斷也可以省去。
舉個例子，假如我們想把 pongba 的 blog mindhacks.cn 裡面的 blog 文字爬下來，通過觀察，很容易發現我們對其中的兩種頁面感興趣：
- 文章列表頁面，例如首頁，或者 URL 是
/page/\d+/這樣的頁面，通過 Firebug 可以看到到每篇文章的連結都是在一個h1下的a標籤裡的（需要注意的是，在 Firebug 的 HTML 皮膚裡看到的 HTML 程式碼和 View Source 所看到的也許會有些出入，如果網頁中有 Javascript 動態修改 DOM 樹的話，前者是被修改過的版本，並且經過 Firebug 規則化的，例如 attribute 都有引號擴起來等，而後者通常才是你的 spider 爬到的原始內容。如果是使用正規表示式對頁面進行分析或者所用的 HTML Parser 和 Firefox 的有些出入的話，需要特別注意），另外，在一個 class 為wp-pagenavi的div裡有到不同列表頁面的連結。 - 文章內容頁面，每篇 blog 有這樣一個頁面，例如 /2008/09/11/machine-learning-and-ai-resources/ ，包含了完整的文章內容，這是我們感興趣的內容。
因此，我們從首頁開始，通過 wp-pagenavi 裡的連結來得到其他的文章列表頁面，特別地，我們定義一個路徑：只 follow Next Page 的連結，這樣就可以從頭到尾按順序走一遍，免去了需要判斷重複抓取的煩惱。另外，文章列表頁面的那些到具體文章的連結所對應的頁面就是我們真正要儲存的資料頁面了。
這樣以來，其實用指令碼語言寫一個 ad hoc 的 Crawler 來完成這個任務也並不難，不過今天的主角是 Scrapy ，這是一個用 Python 寫的 Crawler Framework ，簡單輕巧，並且非常方便，並且官網上說已經在實際生產中在使用了，因此並不是一個玩具級別的東西。不過現在還沒有 Release 版本，可以直接使用他們的 Mercurial 倉庫裡抓取原始碼進行安裝。不過，這個東西也可以不安裝直接使用，這樣還方便隨時更新，文件裡說得很詳細，我就不重複了。
Scrapy 使用 Twisted 這個非同步網路庫來處理網路通訊，架構清晰，並且包含了各種中介軟體介面，可以靈活的完成各種需求。整體架構如下圖所示：
綠線是資料流向，首先從初始 URL 開始，Scheduler 會將其交給 Downloader 進行下載，下載之後會交給 Spider 進行分析，Spider 分析出來的結果有兩種：一種是需要進一步抓取的連結，例如之前分析的“下一頁”的連結，這些東西會被傳回 Scheduler ；另一種是需要儲存的資料，它們則被送到 Item Pipeline 那裡，那是對資料進行後期處理（詳細分析、過濾、儲存等）的地方。另外，在資料流動的通道里還可以安裝各種中介軟體，進行必要的處理。
看起來好像很複雜，其實用起來很簡單，就如同 Rails 一樣，首先新建一個工程：
|
1 |
scrapy-admin.py startproject blog_crawl |
會建立一個 blog_crawl 目錄，裡面有個 scrapy-ctl.py 是整個專案的控制指令碼，而程式碼全都放在子目錄 blog_crawl 裡面。為了能抓取 mindhacks.cn ，我們在 spiders 目錄裡新建一個mindhacks_spider.py ，定義我們的 Spider 如下：
|
1 2 3 4 5 6 7 8 9 10 |
from scrapy.spider import BaseSpider class MindhacksSpider(BaseSpider): domain_name = "mindhacks.cn" start_urls = ["http://mindhacks.cn/"] def parse(self, response): return [] SPIDER = MindhacksSpider() |
我們的 MindhacksSpider 繼承自 BaseSpider （通常直接繼承自功能更豐富的scrapy.contrib.spiders.CrawlSpider 要方便一些，不過為了展示資料是如何 parse 的，這裡還是使用 BaseSpider 了），變數 domain_name 和 start_urls 都很容易明白是什麼意思，而 parse 方法是我們需要定義的回撥函式，預設的 request 得到 response 之後會呼叫這個回撥函式，我們需要在這裡對頁面進行解析，返回兩種結果（需要進一步 crawl 的連結和需要儲存的資料），讓我感覺有些奇怪的是，它的介面定義裡這兩種結果竟然是混雜在一個 list 裡返回的，不太清楚這裡為何這樣設計，難道最後不還是要費力把它們分開？總之這裡我們先寫一個空函式，只返回一個空列表。另外，定義一個“全域性”變數 SPIDER ，它會在 Scrapy 匯入這個 module 的時候例項化，並自動被 Scrapy 的引擎找到。這樣就可以先執行一下 crawler 試試了：
|
1 |
./scrapy-ctl.py crawl mindhacks.cn |
會有一堆輸出，可以看到抓取了 http://mindhacks.cn ，因為這是初始 URL ，但是由於我們在 parse 函式裡沒有返回需要進一步抓取的 URL ，因此整個 crawl 過程只抓取了主頁便結束了。接下來便是要對頁面進行分析，Scrapy 提供了一個很方便的 Shell （需要 IPython ）可以讓我們做實驗，用如下命令啟動 Shell ：
|
1 |
./scrapy-ctl.py shell http://mindhacks.cn |
它會啟動 crawler ，把命令列指定的這個頁面抓取下來，然後進入 shell ，根據提示，我們有許多現成的變數可以用，其中一個就是 hxs ，它是一個 HtmlXPathSelector ，mindhacks 的 HTML 頁面比較規範，可以很方便的直接用 XPath 進行分析。通過 Firebug 可以看到，到每篇 blog 文章的連結都是在 h1 下的，因此在 Shell 中使用這樣的 XPath 表示式測試：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
In [1]: hxs.x('//h1/a/@href').extract() Out[1]: [u'http://mindhacks.cn/2009/07/06/why-you-should-do-it-yourself/', u'http://mindhacks.cn/2009/05/17/seven-years-in-nju/', u'http://mindhacks.cn/2009/03/28/effective-learning-and-memorization/', u'http://mindhacks.cn/2009/03/15/preconception-explained/', u'http://mindhacks.cn/2009/03/09/first-principles-of-programming/', u'http://mindhacks.cn/2009/02/15/why-you-should-start-blogging-now/', u'http://mindhacks.cn/2009/02/09/writing-is-better-thinking/', u'http://mindhacks.cn/2009/02/07/better-explained-conflicts-in-intimate-relationship/', u'http://mindhacks.cn/2009/02/07/independence-day/', u'http://mindhacks.cn/2009/01/18/escape-from-your-shawshank-part1/'] |
這正是我們需要的 URL ，另外，還可以找到“下一頁”的連結所在，連同其他幾個頁面的連結一同在一個 div 裡，不過“下一頁”的連結沒有 title 屬性，因此 XPath 寫作
|
1 |
//div[@class="wp-pagenavi"]/a[not(@title)] |
不過如果向後翻一頁的話，會發現其實“上一頁”也是這樣的，因此還需要判斷該連結上的文字是那個下一頁的箭頭 u'\xbb' ，本來也可以寫到 XPath 裡面去，但是好像這個本身是 unicode escape 字元，由於編碼原因理不清楚，直接放到外面判斷了，最終 parse 函式如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
def parse(self, response): items = [] hxs = HtmlXPathSelector(response) posts = hxs.x('//h1/a/@href').extract() items.extend([self.make_requests_from_url(url).replace(callback=self.parse_post) for url in posts]) page_links = hxs.x('//div[@class="wp-pagenavi"]/a[not(@title)]') for link in page_links: if link.x('text()').extract()[0] == u'\xbb': url = link.x('@href').extract()[0] items.append(self.make_requests_from_url(url)) return items |
前半部分是解析需要抓取的 blog 正文的連結，後半部分則是給出“下一頁”的連結。需要注意的是，這裡返回的列表裡並不是一個個的字串格式的 URL 就完了，Scrapy 希望得到的是Request 物件，這比一個字串格式的 URL 能攜帶更多的東西，諸如 Cookie 或者回撥函式之類的。可以看到我們在建立 blog 正文的 Request 的時候替換掉了回撥函式，因為預設的這個回撥函式 parse 是專門用來解析文章列表這樣的頁面的，而 parse_post 定義如下：
|
1 2 3 4 5 |
def parse_post(self, response): item = BlogCrawlItem() item.url = unicode(response.url) item.raw = response.body_as_unicode() return [item] |
很簡單，返回一個 BlogCrawlItem ，把抓到的資料放在裡面，本來可以在這裡做一點解析，例如，通過 XPath 把正文和標題等解析出來，但是我傾向於後面再來做這些事情，例如 Item Pipeline 或者更後面的 Offline 階段。BlogCrawlItem 是 Scrapy 自動幫我們定義好的一個繼承自ScrapedItem 的空類，在 items.py 中，這裡我加了一點東西：
|
1 2 3 4 5 6 7 8 9 |
from scrapy.item import ScrapedItem class BlogCrawlItem(ScrapedItem): def __init__(self): ScrapedItem.__init__(self) self.url = '' def __str__(self): return 'BlogCrawlItem(url: %s)' % self.url |
定義了 __str__ 函式，只給出 URL ，因為預設的 __str__ 函式會把所有的資料都顯示出來，因此會看到 crawl 的時候控制檯 log 狂輸出東西，那是把抓取到的網頁內容輸出出來了。-.-bb
這樣一來，資料就取到了，最後只剩下儲存資料的功能，我們通過新增一個 Pipeline 來實現，由於 Python 在標準庫裡自帶了 Sqlite3 的支援，所以我使用 Sqlite 資料庫來儲存資料。用如下程式碼替換 pipelines.py 的內容：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
import sqlite3 from os import path from scrapy.core import signals from scrapy.xlib.pydispatch import dispatcher class SQLiteStorePipeline(object): filename = 'data.sqlite' def __init__(self): self.conn = None dispatcher.connect(self.initialize, signals.engine_started) dispatcher.connect(self.finalize, signals.engine_stopped) def process_item(self, domain, item): self.conn.execute('insert into blog values(?,?,?)', (item.url, item.raw, unicode(domain))) return item def initialize(self): if path.exists(self.filename): self.conn = sqlite3.connect(self.filename) else: self.conn = self.create_table(self.filename) def finalize(self): if self.conn is not None: self.conn.commit() self.conn.close() self.conn = None def create_table(self, filename): conn = sqlite3.connect(filename) conn.execute("""create table blog (url text primary key, raw text, domain text)""") conn.commit() return conn |
在 __init__ 函式中，使用 dispatcher 將兩個訊號連線到指定的函式上，分別用於初始化和關閉資料庫連線（在 close 之前記得 commit ，似乎是不會自動 commit 的，直接 close 的話好像所有的資料都丟失了 dd-.-）。當有資料經過 pipeline 的時候，process_item 函式會被呼叫，在這裡我們直接講原始資料儲存到資料庫中，不作任何處理。如果需要的話，可以新增額外的 pipeline ，對資料進行提取、過濾等，這裡就不細說了。
最後，在 settings.py 裡列出我們的 pipeline ：
|
1 |
ITEM_PIPELINES = ['blog_crawl.pipelines.SQLiteStorePipeline'] |
再跑一下 crawler ，就 OK 啦！ 最後，總結一下：一個高質量的 crawler 是極其複雜的工程，但是如果有好的工具的話，做一個專用的 crawler 還是比較容易的。Scrapy 是一個很輕便的爬蟲框架，極大地簡化了 crawler 開發的過程。另外，Scrapy 的文件也是十分詳細的，如果覺得我的介紹省略了一些東西不太清楚的話，推薦看他的 Tutorial 。
注：本文開始的那幅圖並不是一個 spider （當然啦！-,-bb），那是出自動畫片《攻殼機動隊》裡的思考戰車Tachikoma （很可愛的！）。