Python爬蟲 —— 基礎

引入

咱們都知道，當前咱們所處的時代是大數據的時代，在大數據時代，要進行數據分析，首先要有數據源，而學習爬蟲，可讓咱們獲取更多的數據源，而且這些數據源能夠按咱們的目的進行採集。

優酷推出的火星情報局就是基於網絡爬蟲和數據分析製做完成的。其中每期的節目話題都是從相關熱門的互動平臺中進行相關數據的爬取，而後對爬取到的數據進行數據分析而得來的。另外一方面，優酷根據用戶實時觀看視頻時的前進，後退等行爲數據，可以推測計算出觀衆的興趣點和愛好點，這樣有助於節目的剪輯和後期的節目方案的編寫。

今日頭條做爲一個新聞推薦類的應用，其內部的新聞數據都是經過爬蟲程序在各個新聞網站進行新聞數據的爬取，而後經過相應的處理和運算將用戶感興趣的新聞話題推送到用戶的手機上。

從就業的角度來講，爬蟲工程師目前來講屬於緊缺人才，而且薪資待遇廣泛較高因此，深層次地掌握這門技術，對於就業來講，是很是有利的。有些人學習爬蟲可能爲了就業或者跳槽。從這個角度來講，爬蟲工程師是不錯的選擇之一。隨着大數據時代的來臨，爬蟲技術的應用將愈來愈普遍，在將來會擁有更好的發展空間。

1、 爬蟲基礎

什麼是爬蟲

爬蟲就是經過編寫程序模擬瀏覽器上網，而後讓其去互聯網上抓取數據的過程。

哪些語言能夠實現爬蟲

​ 1.php：能夠實現爬蟲。php被號稱是全世界最優美的語言（固然是其本身號稱的，就是王婆賣瓜的意思），可是php在實現爬蟲中支持多線程和多進程方面作的很差。

​ 2.java：能夠實現爬蟲。java能夠很是好的處理和實現爬蟲，是惟一能夠與python並駕齊驅且是python的頭號勁敵。可是java實現爬蟲代碼較爲臃腫，重構成本較大。

​ 3.c、c++：能夠實現爬蟲。可是使用這種方式實現爬蟲純粹是是某些人（大佬們）能力的體現，卻不是明智和合理的選擇。

​ 4.python：能夠實現爬蟲。python實現和處理爬蟲語法簡單，代碼優美，支持的模塊繁多，學習成本低，具備很是強大的框架（scrapy等）且一句難以言表的好！沒有可是！

爬蟲的分類

1. 通用爬蟲：

通用爬蟲是搜索引擎（Baidu、Google、Yahoo等）「抓取系統」的重要組成部分。主要目的是將互聯網上的網頁下載到本地，造成一個互聯網內容的鏡像備份。 簡單來說就是儘量的；把互聯網上的全部的網頁下載下來，放到本地服務器裏造成備分，在對這些網頁作相關處理(提取關鍵字、去掉廣告)，最後提供一個用戶檢索接口。

• 搜索引擎如何抓取互聯網上的網站數據？
  • 門戶網站主動向搜索引擎公司提供其網站的url
  • 搜索引擎公司與DNS服務商合做，獲取網站的url
  • 門戶網站主動掛靠在一些知名網站的友情連接中

​ 2. 聚焦爬蟲：聚焦爬蟲是根據指定的需求抓取網絡上指定的數據。例如：獲取豆瓣上電影的名稱和影評，而不是獲取整張頁面中全部的數據值。

robots.txt協議

​ - 若是本身的門戶網站中的指定頁面中的數據不想讓爬蟲程序爬取到的話，那麼則能夠經過編寫一個robots.txt的協議文件來約束爬蟲程序的數據爬取。robots協議的編寫格式能夠觀察淘寶網的robots（訪問www.taobao.com/robots.txt便可）。可是須要注意的是，該協議只是至關於口頭的協議，並無使用相關技術進行強制管制，因此該協議是防君子不防小人。可是咱們在學習爬蟲階段編寫的爬蟲程序能夠先忽略robots協議。

反爬蟲

- 門戶網站經過相應的策略和技術手段，防止爬蟲程序進行網站數據的爬取。

反反爬蟲

- 爬蟲程序經過相應的策略和技術手段，破解門戶網站的反爬蟲手段，從而爬取到相應的數據。

2、 網絡相關基礎

一、HTTP協議

• 官方概念：

  HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。（雖然童鞋們將這條概念都看爛了，可是也沒辦法，畢竟這就是HTTP的權威官方的概念解釋，要想完全理解，請客觀目移下側......）

• 白話概念：

  HTTP協議就是服務器（Server）和客戶端（Client）之間進行數據交互（相互傳輸數據）的一種形式。咱們能夠將Server和Client進行擬人化，那麼該協議就是Server和Client這兩兄弟間指定的一種交互溝通方式。你們都看過智取威虎山中楊子榮和土匪們之間說的黑話吧：

  - 土匪：蘑菇，你哪路？什麼價？（什麼人？到哪裏去？）
  - 楊子榮：哈！想啥來啥，想吃奶來了媽媽，想孃家的人，孩子他舅舅來了。（找同行）
  - 楊子榮：拜見三爺！
  - 土匪：天王蓋地虎！（你好大的膽！敢來氣你的祖宗？）
  - 楊子榮：寶塔鎮河妖！（要是那樣，叫我從山上摔死，掉河裏淹死。）
  - 土匪：野雞悶頭鑽，哪能上天王山！（你不是正牌的。）
  - 楊子榮：地上有的是米，喂呀，有根底！（老子是正牌的，老牌的。）
  - 土匪：拜見過阿媽啦？（你從小拜誰爲師？）
  - 楊子榮：他房上沒瓦，非否非，否非否！（不到正堂不能說。）
  - 土匪：嘛哈嘛哈？（之前獨幹嘛？）
  - 楊子榮：正晌午說話，誰尚未家？（許大馬棒山上。）
  - 土匪：好叭噠！（內行，是把老手）
  - 楊子榮：天下大耷拉！（不吹牛，闖過大隊頭。）
  - 座山雕：臉紅什麼？
  - 楊子榮：神采飛揚！
  - 座山雕：怎麼又黃了？
  - 楊子榮：防冷，塗的蠟！
  - 座山雕：曬噠曬噠。（誰指點你來的？）
  - 楊子榮：一座玲瓏塔，面向青寨背靠沙！（是個道人。）

  是否是看到這裏，有得童鞋終於知道了傳說中的‘天王蓋地虎’是真正含義了吧。此黑話其實就是楊子榮和土匪之間進行交互溝通的方式（協議）。

• HTTP工做原理：

  HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

• HTTP四點注意事項：

  • HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

  • HTTP是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

  • HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。

  • HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

• HTTP之URL：

  HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息

  URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。如下面這個URL爲例，介紹下普通URL的各部分組成：*http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name**從上面的URL能夠看出，一個完整的URL包括如下幾部分：

　　- 協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符*

　　- 域名部分：該URL的域名部分爲「www.aspxfans.com」。一個URL中，也可使用IP地址做爲域名使用

　　- 端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口

　　- 虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/news/」

　　- 文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「index.asp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

　 - 錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分

　 - 參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「boardID=5&ID=24618&page=1」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符。

• HTTP之Request：

  客戶端發送一個HTTP請求到服務器的請求消息包括如下組成部分：

　 報文頭：常被叫作請求頭，請求頭中存儲的是該請求的一些主要說明（自我介紹）。服務器據此獲取客戶端的信息.　

# 常見的請求頭：

-  accept:瀏覽器經過這個頭告訴服務器，它所支持的數據類型
-  Accept-Charset: 瀏覽器經過這個頭告訴服務器，它支持哪一種字符集　　　　　　　　
-  Accept-Encoding：瀏覽器經過這個頭告訴服務器，支持的壓縮格式　　　　　　　　
-  Accept-Language：瀏覽器經過這個頭告訴服務器，它的語言環境　　　　　　　　
-  Host：瀏覽器經過這個頭告訴服務器，想訪問哪臺主機　　　　　　　　
-  If-Modified-Since: 瀏覽器經過這個頭告訴服務器，緩存數據的時間　　　　　　　
-  Referer：瀏覽器經過這個頭告訴服務器，客戶機是哪一個頁面來的 防盜鏈　　　　　　　
-  Connection：瀏覽器經過這個頭告訴服務器，請求完後是斷開連接仍是何持接　　　　　　　
-  X-Requested-With: XMLHttpRequest 表明經過ajax方式進行訪問*
-  User-Agent：請求載體的身份標識

　　報文體：常被叫作請求體，請求體中存儲的是將要傳輸/發送給服務器的數據信息。

• HTTP之Response：

  服務器回傳一個HTTP響應到客戶端的響應消息包括如下組成部分：

​ 狀態碼：以「清晰明確」的語言告訴客戶端本次請求的處理結果。

# HTTP的響應狀態碼由5段組成： 

-  1xx 消息，通常是告訴客戶端，請求已經收到了，正在處理，別急...
-  2xx 處理成功，通常表示：請求收悉、我明白你要的、請求已受理、已經處理完成等信息.
-  3xx 重定向到其它地方。它讓客戶端再發起一個請求以完成整個處理。
-  4xx 處理髮生錯誤，責任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被受權，禁止訪問等。
-  5xx 處理髮生錯誤，責任在服務端，如服務端拋出異常，路由出錯，HTTP版本不支持等。

​ 相應頭：響應的詳情展現

# 常見的相應頭信息：

-  Location: 服務器經過這個頭，來告訴瀏覽器跳到哪裏
-  Server：服務器經過這個頭，告訴瀏覽器服務器的型號
-  Content-Encoding：服務器經過這個頭，告訴瀏覽器，數據的壓縮格式
-  Content-Length: 服務器經過這個頭，告訴瀏覽器回送數據的長度
-  Content-Language: 服務器經過這個頭，告訴瀏覽器語言環境
-  Content-Type：服務器經過這個頭，告訴瀏覽器回送數據的類型
-  Refresh：服務器經過這個頭，告訴瀏覽器定時刷新
-  Content-Disposition: 服務器經過這個頭，告訴瀏覽器如下載方式打數據
-  Transfer-Encoding：服務器經過這個頭，告訴瀏覽器數據是以分塊方式回送的
-  Expires: -1 控制瀏覽器不要緩存
-  Cache-Control: no-cache 
-  Pragma: no-cache

​ 相應體：根據客戶端指定的請求信息，發送給客戶端的指定數據

三、HTTPS協議　　　

• 官方概念：

  HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協議，HTTPS是在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。

• 白話概念：

  加密安全版的HTTP協議。

• HTTPS採用的加密技術

  一、SSL加密技術

  ​ SSL採用的加密技術叫作「共享密鑰加密」，也叫做「對稱密鑰加密」，這種加密方法是這樣的，好比客戶端向服務器發送一條信息，首先客戶端會採用已知的算法對信息進行加密，好比MD5或者Base64加密，接收端對加密的信息進行解密的時候須要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。這種方式看起來安全，可是仍有潛在的危險，一旦被竊聽，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。所以「共享密鑰加密」這種方式存在安全隱患：

二、非對稱祕鑰加密技術

​ 「非對稱加密」使用的時候有兩把鎖，一把叫作「私有密鑰」，一把是「公開密鑰」，使用非對象加密的加密方式的時候，服務器首先告訴客戶端按照本身給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密之後，服務器接受到信息再經過本身的私有密鑰進行解密，這樣作的好處就是解密的鑰匙根本就不會進行傳輸，所以也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，由於解密過程是對離散對數求值，這可不是垂手可得就能作到的事。如下是非對稱加密的原理圖：

​ 缺點：

​ 第一個是：如何保證接收端向發送端發出公開祕鑰的時候，發送端確保收到的是預先要發送的，而不會被挾持。只要是發送密鑰，就有可能有被挾持的風險。

​ 第二個是：非對稱加密的方式效率比較低，它處理起來更爲複雜，通訊過程當中使用就有必定的效率問題而影響通訊速度

三、https的證書機制

​ 在上面咱們講了非對稱加密的缺點，其中第一個就是公鑰極可能存在被挾持的狀況，沒法保證客戶端收到的公開密鑰就是服務器發行的公開密鑰。此時就引出了公開密鑰證書機制。數字證書認證機構是客戶端與服務器均可信賴的第三方機構。證書的具體傳播過程以下：

​ 1：服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公開密鑰的申請，數字證書認證機構在認清申請者的身份，審覈經過之後，會對開發者申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將密鑰放在證書裏面，綁定在一塊兒

​ 2：服務器將這份數字證書發送給客戶端，由於客戶端也承認證書機構，客戶端能夠經過數字證書中的數字簽名來驗證公鑰的真僞，來確保服務器傳過來的公開密鑰是真實的。通常狀況下，證書的數字簽名是很難被僞造的，這取決於認證機構的公信力。一旦確認信息無誤以後，客戶端就會經過公鑰對報文進行加密發送，服務器接收到之後用本身的私鑰進行解密。

部份內容來源：http://www.javashuo.com/article/p-qmynevqp-gy.html