python爬蟲入門基本知識
基礎知識
HTTP協(xié)議
我們?yōu)g覽網(wǎng)頁的瀏覽器和手機應用客戶端與服務器通信幾乎都是基于HTTP協(xié)議，而爬蟲可以看作是一個另類的客戶端，它把自己偽裝成瀏覽器或者手機應用客戶端，按照自己的邏輯貪婪的向服務器索取數(shù)據(jù)，如何向服務器索取數(shù)據(jù)，所以了解HTTP協(xié)議就顯得很有必要了。
HTTP協(xié)議中文名稱是超文本傳輸協(xié)議，是一個基于請求與響應模式的、無狀態(tài)的、應用層的協(xié)議，?；赥CP的連接方式。請求和響應模式很好理解，客戶端發(fā)送請求，服務器響應客戶端的請求，就像學校食堂打菜一樣，你和打菜阿姨說要哪份菜，她才會給你盛哪份菜。
無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務器不需要先前信息時它的應答就較快。形象點說，可以把服務器看成是沒有記憶的大學食堂打飯打菜，在每次請求中，阿姨并不知道你之前有沒有打過菜，也不知道你是不是合法的學生，所以你只能一邊舉著學生證一邊和阿姨說我要這個菜，阿姨看到你的學生證后才會給你打菜，而這個學生證就是你每次需要重傳的數(shù)據(jù)信息。
當我們在瀏覽器地址欄中輸入http://www.bilibili.com 并敲入回車后，瀏覽器會構(gòu)造HTTP請求發(fā)送到服務器，在收到服務器的HTTP響應后，瀏覽器會解析頁面，繼續(xù)向服務器請求圖片、視頻、js腳本等數(shù)據(jù)，直到頁面加載完成，最終展示給我們的就是B站主頁了。這是我用Fiddler抓的包，展示的是HTTP最原生的面貌，接下來我就根據(jù)這張圖具體的講解HTTP協(xié)議，以及寫爬蟲需要關注的一些點。
HTTP請求由三部分組成，分別是: 請求行、消息報頭、請求正文。 在接收和解釋請求消息后，服務器返回一個HTTP響應消息，HTTP響應也是由三個部分組成，分別是：狀態(tài)行、消息報頭、響應正文。
HTTP方法
HTTP請求的請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協(xié)議的版本。請求方法都是大寫，有很多種，常見的有GET POST DELETE PUT，各種方法之間的區(qū)別不大。
這里羅列了一些常用的方法，一般來講，GET表示向服務器請求URI對應的資源，POST表示向服務器提交數(shù)據(jù)，DELETE表示刪除數(shù)據(jù)，PUT表示修改數(shù)據(jù)。但這都是一種約定，沒有強制的要求，如果你碰見用DELETE方法提交數(shù)據(jù)也沒必要大驚小怪。在實際寫爬蟲的過程中，我們只需要按照抓包請求構(gòu)造數(shù)據(jù)即可，沒有必要在意用了什么方法。
報頭字段
重點講解幾個寫爬蟲需要關注的字段
- User-Agent 出現(xiàn)在請求報頭中，表示客戶端的操作系統(tǒng)、瀏覽器型號版本等信息。服務器可以根據(jù)此報頭向客戶端返回不同的頁面以適應客戶端。有些網(wǎng)站(知乎)會校驗此報頭，不填寫或者不主流的報頭都不能拿到正常的頁面。因此自己在寫爬蟲的時候最好將從瀏覽器中拷貝到代碼中。
- Cookie 出現(xiàn)在請求抱頭中，前面我們說過HTTP是基于請求與響應模式并且無狀態(tài)的協(xié)議，之前舉了打菜阿姨的例子，Cookie就相當于每次請求中的學生證，它可以記錄用戶的身份信息。當我們自己寫爬蟲的時候，如果需要登陸，并且登陸又有驗證碼或者短信驗證時，最簡單的方法就是從瀏覽器中把cookie拷貝到爬蟲中，就可以騙過服務器了。
- Set-Cookie 出現(xiàn)在響應抱頭中，讓客戶端更新頁面關聯(lián)的Cookie，還是拿食堂阿姨的例子，如果你的響應報頭有這個字段，意思就是阿姨重新給你了一個學生證，下次打飯你得用最新的學生證，原來的學生證不好使。如果你在模擬瀏覽器或者客戶端登陸，需要將此報頭更新已有的Cookie，不過Scrapy和requests都可以自動更新，因此不需要你再手動設置。
- Content-Type 標明請求正文或者響應正文的格式，客戶端或者服務器會根據(jù)此字段選擇合適的方式解析正文內(nèi)容，以下是一些常見的值
- Content-Length 標明請求正文或者響應正文的長度，在使用requests構(gòu)造請求的時候，我們不需要顯式的加上此字段，requests會根據(jù)請求正文自動計算添加。
- Content-Encoding 在某些情況下，正文會講過壓縮后傳輸，此字段會指明壓縮的類型(gzip和壓縮參數(shù))
- Transfer-Encoding 如果正文內(nèi)容過長，HTTP協(xié)議允許將此字段設置為chunked，然后分塊傳輸響應正文
- Connection 在HTTP1.1之前的版本，不支持持久連接，所謂的持久鏈接意思就是：HTTP協(xié)議一般通過TCP協(xié)議實現(xiàn)，客戶端和服務器經(jīng)過TCP三次握手建立連接，在請求和響應結(jié)束之后，此連接繼續(xù)保持，當之后還有請求的時候，就不需要重新通過三次握手再建立連接，這樣可以極大的降低客戶端和服務器的IO負載。
在自己寫爬蟲的時候，我們可以根據(jù)瀏覽器的抓包數(shù)據(jù)有選擇的添加一些請求報頭，其實大部分情況下都可以直接使用瀏覽器中的請求頭，為了避免不必要的麻煩，盡可能像的模仿瀏覽器總是沒有錯的。
響應碼
響應消息的第一行的狀態(tài)行包括HTTP的協(xié)議版本、狀態(tài)碼、狀態(tài)碼含義。按照約定
- 2xx表示請求成功
- 3xx表示重定向
- 4xx表示客戶端錯誤(403 Forbiden 404 Not Found)
- 5xx表示服務器錯誤(502 網(wǎng)關錯誤)
爬蟲開發(fā)
一般來說開發(fā)爬蟲的過程是這樣的
- 抓包分析獲取數(shù)據(jù)的URL
- 通過python從上一步的URL獲取數(shù)據(jù)
- 從上一步獲取的HTML頁面或者JSON數(shù)據(jù)中解析出感興趣的數(shù)據(jù)
- 存儲數(shù)據(jù)
下面就講解這四個關鍵點
抓包發(fā)包工具
寫爬蟲的第一步就是分析想要的數(shù)據(jù)瀏覽器是通過什么URL拿到的，抓包也就在所難免。最好用的抓包工具當然是谷歌瀏覽器了，右鍵檢查，選中網(wǎng)絡，重新刷新頁面就可以看到加載此網(wǎng)頁所有的HTTP請求了，如果此鏈接有跳轉(zhuǎn)地址，跳轉(zhuǎn)之前的HTTP請求會被清掉，所以記得選上preserve log，尤其是登陸的時候，一般都會有跳轉(zhuǎn)。
再介紹另外兩個HTTP抓包工具——Fiddler和Charles，分別在windows和macos使用。它們可以為我們展示更多HTTP的細節(jié)，將請求和響應都調(diào)至Raw模式下，我們就可以一睹HTTP請求和響應的真實面貌。
通過抓包分析出具體的URL后，想進一步確認自己構(gòu)造的參數(shù)和報頭能否正確獲取到數(shù)據(jù)，應該怎么做呢?不怕，postman可以幫你，你可以很輕松的選擇方法，定義header，添加各種類型的body。
python請求數(shù)據(jù)
講完了基本的HTTP協(xié)議知識后，大家可能會疑問那我該如何模仿瀏覽器或者手機客戶端去向服務器發(fā)送HTTP請求呢?python的原生庫urllib、第三方庫requests、pycurl等都支持HTTP協(xié)議，既然有這么多工具可以用，大家可能就又有疑問該選擇哪個工具了。在此我特地安利大家用一下requests，它讓爬蟲變得如此簡單，讓你再也不用為字符編碼、重定向、cookie、響應解壓縮煩惱了。如果你堅持用原生的庫，那么有以下問題需要你一一解決，這些都是當年自己趟過的坑，絕非危言聳聽。
- 需要自己判斷服務器返回數(shù)據(jù)的編碼格式，如果這個地方你不能正確判斷，那恭喜你之后的每一步，你都必須面對亂碼的問題
- 重定向，urllib不能自動判斷重定向，需要自己解析重定向的鏈接并重新請求
- 如果模擬登陸，你必須要手動保證Cookie正確更新和發(fā)送
- 很多情況下響應正文是壓縮過的，需要做解壓處理
- 對于比較長的響應正文，服務器會將正文分段傳輸，所以還需要你做拼接操作
- 原生的urllib對HTTPS和持久連接都支持不好
當你花了一整天，寫了好幾百行的代碼終于解決上面的問題后，而你旁邊的同事可能早已經(jīng)把數(shù)據(jù)下載完并愉快的約妹子去了。所以用requests吧，兄弟們用了都說好。下面我用兩個例子講解一下如何用requests獲取想要的數(shù)據(jù)，并教你如何解決這些問題：
- 如何發(fā)送不同方法的請求
- 如何保存cookie
- 如何添加代理
- 如何處理編碼問題
B站
假如我想下載B站里面某位小姐姐所有上傳的視頻，應該怎么辦呢?首先你需要找到這位小姐姐的視頻主頁
但是通過谷歌瀏覽器右鍵查看頁面源碼，沒有從html中找到這些視頻的播放信息，唯一的可能就是視頻數(shù)據(jù)是通過js腳本調(diào)用服務器獲取，然后生成的這張頁面。爬蟲小白可能會疑問，難道我需要像瀏覽器一樣分析js腳本，然后模擬js執(zhí)行嗎?其實不用這么復雜，只需要簡單的分析抓包結(jié)構(gòu)，就可以找到請求URL了。
獲取視頻的URL： http://space.bilibili.com/ajax/member/getSubmitVideos?mid=79415852&pagesize=30&tid=0&page=1&keyword=&order=senddate
那么問題又來了，這個URL的其他參數(shù)是干啥的呢?憑經(jīng)驗，mid肯定是這位小姐姐的用戶id，page和pagesize是負責分頁用的，keyword和是用來搜索的關鍵字，order是排序選項，剩下的tid是干啥的呢?其實寫爬蟲很多時候都會遇到這種問題，不知道某個參數(shù)的含義，也不確定正確的取值范圍，需要一些嘗試和運氣，這里我們不管它就好。而返回的字段中有一個aid，那肯定是視頻的id，有這個就可以自己拼接出播放鏈接了。
是不是很簡單，通過response.ok查看請求是否正確返回，因為此接口的數(shù)據(jù)為json格式，直接通過response.json()就可以直接拿到格式化的數(shù)據(jù)。
知乎
雖然現(xiàn)在知乎對未登錄用戶展示的內(nèi)容越來越多，但是仍會有一些限制，用爬蟲模擬登陸可以之后再去爬取數(shù)據(jù)，可以避免很多不必要的麻煩，現(xiàn)在就講一講如何用requests模擬用戶登陸。
還是和之前一樣，在登陸頁面打開谷歌瀏覽器的抓包窗口，輸入用戶名和密碼點擊確定，然后在茫茫請求中找到發(fā)送登陸信息的那個HTTP請求即可，功夫不負有心人，我們終于找到了登陸的請求。
等等，請求里面還有一個_xsrf，這是一個什么鬼參數(shù)，其實呢這是一個防止跨站請求偽造而生成的一個隨機數(shù)，可以通過解析https://www.zhihu.com/#signin 頁面獲取，這一部分我在下面會講解如何HTML獲取數(shù)據(jù)，現(xiàn)在假設我們已經(jīng)拿到這個數(shù)據(jù)了，如何將用戶名和密碼登陸呢?
如果我們想要自動保存Cookie信息，只需要生成一個Session對象，之后所有的請求通過此對象完成，requests會像瀏覽器一樣自動更新cookie信息，并在每次請求的時候加上cookie，因此在成功的發(fā)送post登陸請求之后，就可以用session在保持登陸狀態(tài)請求數(shù)據(jù)了。需要注意的是在請求的時候我特意去掉了Cookie和Content-Length報頭，因為requests會自動加上，所以不需要我們特意關注。
更多關于requests的使用可以查看官方文檔：
英文： http://docs.python-requests.org/en/master/
中文： http://cn.python-requests.org/zh_CN/latest/user/quickstart.html
python解析數(shù)據(jù)
因為個人在解析數(shù)據(jù)的時候遇到過很多編碼的坑，所以在繼續(xù)講解之前告訴大家一些如何避免編碼問題的方法。python2中有兩種字符串：unicode和str，它們分別對應python3中的str和bytes。如何定義這兩種類型的變量在下圖中給大家列出來了。
以python3為例講解這兩種類型的區(qū)別。python3中的str每一個字符可以存儲一個英文字母、一個漢字甚至一個emoji表情，它可以通過特定的編碼方式，例如utf-8或者gbk生成bytes，在不同的編碼格式下，可能需要2-3個字符常能表示一個漢字。bytes可以指定解碼格式解碼生成str，如果指定的解碼格式不匹配，就會導致亂碼問題。為了避免亂碼問題，最好的方式就是使用str，等到需要寫入文件或者數(shù)據(jù)庫的時候，再指定寫入的編碼格式，用好這個準則，我們可以避免百分之九十的編碼問題。
HTTP響應的數(shù)據(jù)格式有很多，例如文本、json、html，對應的解析方式也很多。通用一點，用python內(nèi)置庫正則匹配找到想要的數(shù)據(jù)，但是這種方法相對來說比較麻煩，而且不好維護，比較適合文本類型的數(shù)據(jù)，但HTTP響應正文基本都是json和HTML，這種方式適用面比較窄。
當請求的數(shù)據(jù)是json格式時，我們可以很方便的用requests反序列化返回內(nèi)容，取出感興趣的數(shù)據(jù)。但是當HTTP返回的數(shù)據(jù)是html的時候，我們該如何操作，就像剛才知乎登陸的例子中，如何快速從html中解析想要的數(shù)據(jù)呢?
專門用來解析html的第三方庫有很多，例如beautifulsoup、pyquery。個人推薦使用pyquery，因為它可以使用jquery的方式選取元素，而且支持xpath，以后上手scrapy會很容易。繼續(xù)上面登陸知乎的例子，登陸時需要的_xsrf實際上在 https://www.zhihu.com/#signin 頁面里面，只要先請求到這個頁面，然后解析出_xsrf，配合之前的登陸請求，我們就可以完整的實現(xiàn)用python模擬瀏覽器登陸知乎了。
使用起來是不是相當?shù)暮唵?，我們只要通過谷歌瀏覽器找到對應DOM元素，根據(jù)屬性名就可以非常快速的找到想要的數(shù)據(jù)。需要注意的是response.content和response.text，這都是返回的body正文，但是前者是bytes，后者是str，requests已經(jīng)幫助我們把響應正文按照正確的編碼格式進行了解碼，根據(jù)我們之前的闡述的原則，盡量使用str，所以26這個地方我用的是response.text。
更多關于pyquery的使用可以參考官方文檔： https://pythonhosted.org/pyquery/
存儲數(shù)據(jù)
根據(jù)數(shù)據(jù)量的不同以及數(shù)據(jù)類型的不同，數(shù)據(jù)的存儲選擇也很多。如果爬取的是圖片、音頻、視頻等多媒體文件，直接按照文件形式存儲就好了。如果是一些文本，數(shù)字等數(shù)據(jù)，一般有這么幾種選擇：
- 輸出到屏幕
- 寫入文件(txt csv)
- 寫入數(shù)據(jù)庫 (mysql sqlite mongo)
如果數(shù)據(jù)量非常小，可以選擇直接輸出到屏幕(這種情況貌似也不需要爬蟲)，因為終端存儲的數(shù)據(jù)量很少，而且因為沒有持久化，關閉窗口就意味著數(shù)據(jù)丟失，不建議使用。
在數(shù)據(jù)量小且不愿意折騰數(shù)據(jù)庫的情況下，可以把爬取的數(shù)據(jù)寫入文件，但是這種情況不能隨取隨用，也不方便做數(shù)據(jù)分析，需要手動處理。
當數(shù)據(jù)量較多，而且需要快捷的分析數(shù)據(jù)，推薦使用數(shù)據(jù)庫存儲數(shù)據(jù)，大型的數(shù)據(jù)庫mysql, mongo功能齊全，可以分方便的進行數(shù)據(jù)分析，而且也很容易實現(xiàn)分布式擴展，當你需要多進程甚至多機器運行爬蟲的時候，這些數(shù)據(jù)庫可能是最好的選擇。sqlite相對來說功能要少很多，python原生支持，依賴少，數(shù)據(jù)量不算太大的情況下可以考慮使用。
爬蟲示例
下面給出一個簡單的例子，為大家展示如何使用上述python庫實現(xiàn)一個完整的爬蟲。一些熱門的知乎話題最多有1000條精華回答，這個例子就是爬取這些精品答案。圖示頁面就是回答列表，每頁有二十個答案，最多有五十頁。但是此頁面沒有完整的回答信息，需要通過顯示全部對應的鏈接進入回答詳情頁才能獲取完整的答案，所以我們的爬蟲策略就是通過回答列表找到所有精華回答鏈接，再通過回答鏈接獲取內(nèi)容。而且這些頁面不需要登陸也能訪問，因此可以省去模擬登陸。
開發(fā)環(huán)境
python是跨平臺語言，但不同平臺不同版本的python略微有一些差異，考慮到大家使用windows平臺的較多，我在windows和ubuntu的python3.5驗證過此代碼，其他平臺和其他python版本下可能需要做一些修改。集成開發(fā)環(huán)境推薦使用Pycharm，這是一個跨平臺良心IDE，各大操作系統(tǒng)下都有免費的社區(qū)版本可以下載。
運行代碼
代碼鏈接
https://github.com/LiuRoy/sakura/blob/master/spider/crawl.py
https://github.com/LiuRoy/sakura/blob/master/spider/tables.sql
安裝依賴庫：
- pip install requests pyquery SQLAlchemy
運行代碼：
- python scrawl.py
代碼解釋
通過谷歌瀏覽器抓包分析，可以通過 https://www.zhihu.com/topic/19553155/top-answers?page=2 頁面獲取每個話題不同分頁下的回答鏈接 https://www.zhihu.com/question/27189372/answer/38712987 ，在此頁面中就可以獲取問題、回答、點贊數(shù)、標簽等信息。
因為數(shù)據(jù)量不大，采用sqlite存儲，可以很方便的用命令行或者桌面客戶端查看數(shù)據(jù)。
反爬蟲策略和應對方式
稍微大一些的網(wǎng)站都會有一些反爬蟲策略，簡單一點的根據(jù)User-Agent過濾，例如知乎，我們只需要設置為和瀏覽器相同即可。復雜一點的會限制非登陸用戶，也只需要按照之前例子中的方式登陸，或者干脆先用瀏覽器登陸好，然后在第一次訪問的時候帶上瀏覽器中的cookie就好，實現(xiàn)起來難度不大。但是有不少網(wǎng)站，例如豆瓣和github，在檢測到某一客戶端頻繁訪問后，會直接封鎖ip，這個問題解決起來就相當?shù)募趾偷疤哿恕?/p>
解決方法也挺簡單，我們只需要找到足夠多的代理ip就可以了，只要策略得當，短時間內(nèi)不要過度頻繁的使用同一ip代碼，或者當某一ip地址被封鎖后馬上切換到其他的ip代理，這樣就可以保證高效的爬取數(shù)據(jù)了。那如何找到代理ip并且如何使用了，其實免費的代理ip很多，我們用百度搜索代理ip就可以找到很多網(wǎng)站，例如：http://www.ip181.com/。
找到代理ip后，就可以用上面的方式很輕松的使用代理ip了，但是網(wǎng)上免費的代理ip質(zhì)量不好，很多不可用，而且速度慢、不穩(wěn)定，請求的時候最好設置一下超時時間。我之前在爬github的時候，會專門寫一個爬蟲從這些網(wǎng)站搜集代理ip地址，一旦檢測到被github封鎖，就隨機選取一個代理ip使用，如果發(fā)現(xiàn)代理ip不可用，不斷的更換知道可用的代理ip為止，每個代理ip使用的次數(shù)也會有一定的限制，保證爬蟲在整個執(zhí)行期間不會因為ip封鎖而不可用。
異常及性能
曾經(jīng)我遇到過這樣的狀態(tài)，寫好并運行爬蟲一個小時之后，因為網(wǎng)絡抖動或者某一種特殊的頁面導致解析失敗，整個爬蟲運行終止，這就蛋疼了。如果日志打印不充分，我連運行失敗的原因都清楚，更別說修復問題，即使修復好重新運行，又要花一個小時才能到剛才的進度，費時費力。
爬蟲出現(xiàn)異常的情況實在是太多：網(wǎng)絡抖動、解析頁面失敗、反爬蟲被屏蔽、寫入數(shù)據(jù)異常、代碼邏輯錯誤等等都會導致進程終止，而一般爬蟲需要數(shù)小時甚至數(shù)天數(shù)周的運行，每一次的運行失敗都是時間巨大的浪費。因此一定需要在可能出現(xiàn)異常的地方接住異常，保證爬蟲不會終止，并記錄日志，這些錯誤日志不僅可以快速的幫助我們定位錯誤，在出錯不多的情況下，我們甚至不需要修改代碼重新運行，只需要人肉補全這些數(shù)據(jù)就好。
如果發(fā)現(xiàn)自己的爬蟲運行效率太低，爬取速度太慢，并發(fā)對于提升爬蟲速度是一個不錯解決方案，因為GIL的存在，多進程并發(fā)模式對于python提速更優(yōu)，我們可以使用生產(chǎn)者消費者的模式將爬蟲任務進行拆分，從而實現(xiàn)多進程或者分布式。一般來說可以將HTTP請求的數(shù)據(jù)、解析數(shù)據(jù)、存儲數(shù)據(jù)分別用不同的進程實現(xiàn)，這些進程之間通過消息隊列進行通信，保證每個進程無狀態(tài)，就可以非常容易的實現(xiàn)多進程擴展。即使某一類進程出現(xiàn)異常，也不需要重新啟動所有的進程，只需要修復好代碼重新啟動，就可以實現(xiàn)斷點續(xù)爬了。
一些常用的分布式工具：redis、rabbitmq、scrapy、celery、you-get
