Python3網(wǎng)絡(luò)爬蟲實戰(zhàn)-15、爬蟲基礎(chǔ)：HTTP基本原理-創(chuàng)新互聯(lián)

在寫爬蟲之前，還是需要了解一些爬蟲的基礎(chǔ)知識，如 HTTP 原理、網(wǎng)頁的基礎(chǔ)知識、爬蟲的基本原理、Cookies 基本原理等。

成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站制作、網(wǎng)站設(shè)計、興寧網(wǎng)絡(luò)推廣、成都微信小程序、興寧網(wǎng)絡(luò)營銷、興寧企業(yè)策劃、興寧品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們大的嘉獎；成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供興寧建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：muchs.cn

那么本章內(nèi)容就對一些在做爬蟲之前所需要的基礎(chǔ)知識做一些簡單的總結(jié)。

HTTP基本原理

在本節(jié)我們會詳細(xì)了解 HTTP 的基本原理，了解在瀏覽器中敲入一個 URL 到獲取網(wǎng)頁內(nèi)容發(fā)生了一個怎樣的過程，了解了這些內(nèi)容，有助于去進(jìn)一步了解爬蟲的基本原理。

1. URI、URL

在了解 HTTP 之前我們先了解一下 URI 和 URL。我們經(jīng)常會聽到 URI 和 URL 兩個術(shù)語，URI 全稱為 Uniform Resource Identifier，即統(tǒng)一資源標(biāo)志符，URL 全稱為 Universal Resource Locator，即統(tǒng)一資源定位符。
舉例來說，https://github.com/favicon.ico，這是 GitHub 的網(wǎng)站圖標(biāo)鏈接，它是一個 URL，也是一個 URI，即有這樣的一個圖標(biāo)資源，我們用 URL/URI 來唯一指定了它的訪問方式，這其中包括了訪問協(xié)議 https、訪問路徑/即根目錄，資源名稱 favicon.ico，通過這樣的一個鏈接我們便可以從互聯(lián)網(wǎng)上找到這個資源，這就是 URL/URI。Python資源分享qun 784758214 ,內(nèi)有安裝包，PDF，學(xué)習(xí)視頻，這里是Python學(xué)習(xí)者的聚集地，零基礎(chǔ)，進(jìn)階，都?xì)g迎

URL 是 URI 的子集，也就是說每個 URL 都是 URI，但不是每個 URI 都是 URL。那么怎樣的 URI 不是 URL 呢？URI 還包括一個子類叫做 URN，它的全稱為 Universal Resource Name，即統(tǒng)一資源名稱。URN 只命名資源而不指定如何定位資源，如 urn:isbn:0451450523，它指定了一本書的 ISBN，可以唯一標(biāo)識這一本書，但是沒有指定到哪里定位這本書，這就是 URN，URL、URN、URI 的關(guān)系可以用圖 2-1 表示如下：

圖 2-1 URL、URN、URI 關(guān)系圖
但是在目前的互聯(lián)網(wǎng)，URN 的使用非常少，所以幾乎所有的 URI 都是 URL，所以一般的網(wǎng)頁鏈接我們可以稱之為 URL，也可以稱之為 URI，我個人習(xí)慣稱之為 URL。

2. 超文本

接下來我們再了解一個概念，超文本。超文本英文名稱叫做 Hypertext，我們在瀏覽器里面看到的網(wǎng)頁就是超文本解析而成的，其網(wǎng)頁源代碼是一系列 HTML 代碼，里面包含了一系列標(biāo)簽，如 img 顯示圖片，p 指定顯示段落等，瀏覽器解析這些標(biāo)簽后便形成了我們平常看到的網(wǎng)頁，而這網(wǎng)頁的源代碼 HTML 就可以稱作超文本。
例如我們在 Chrome 瀏覽器里面打開任意一個頁面，如淘寶首頁，右鍵點擊檢查，或按下快捷鍵 F12 即可打開瀏覽器的開發(fā)者工具，這時我們在 Elements 選項卡即可看到當(dāng)前網(wǎng)頁的源代碼，這些源代碼都是超文本，如圖 2-2 所示：

圖 2-2 源代碼

3. HTTP、HTTPS

我們在前面了解了 URI 和 URL，例如淘寶的首頁：https://www.taobao.com/，在 URL 的開頭會有 http 或 https，這個就是訪問資源需要的協(xié)議類型，有時我們還會看到 ftp、sftp、smb 開頭的 URL，那么這里的 ftp、sftp、smb 都是指的協(xié)議類型。在爬蟲中，我們抓取的頁面通常就是 http 或 https 協(xié)議的，我們在這里首先來了解一下這兩個協(xié)議的含義。
HTTP 的全稱是 Hyper Text Transfer Protocol，中文名叫做超文本傳輸協(xié)議，HTTP 協(xié)議是用于從網(wǎng)絡(luò)傳輸超文本數(shù)據(jù)到本地瀏覽器的傳送協(xié)議，它能保證傳送高效而準(zhǔn)確地傳送超文本文檔。HTTP 由萬維網(wǎng)協(xié)會（World Wide Web Consortium）和 Internet 工作小組IETF（Internet Engineering Task Force）共同合作制定的規(guī)范，目前廣泛使用的是 HTTP 1.1 版本。
HTTPS 的全稱是 Hyper Text Transfer Protocol over Secure Socket Layer，是以安全為目標(biāo)的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，簡稱為 HTTPS。
HTTPS 的安全基礎(chǔ)是 SSL，因此通過它傳輸?shù)膬?nèi)容都是經(jīng)過 SSL 加密的，它的主要作用可以分為兩種：

• 是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?/li>
• 確認(rèn)網(wǎng)站的真實性，凡是使用了 https 的網(wǎng)站，都可以通過點擊瀏覽器地址欄的鎖頭標(biāo)志來查看網(wǎng)站認(rèn)證之后的真實信息，也可以通過 CA 機構(gòu)頒發(fā)的安全簽章來查詢。

現(xiàn)在越來越多的網(wǎng)站和 APP 都已經(jīng)向 HTTPS 方向發(fā)展。例如：

• 蘋果公司強制所有 iOS App 在 2017 年 1 月 1 日 前全部改為使用 HTTPS 加密，否則 APP 就無法在應(yīng)用商店上架。谷歌從 2017 年 1 月推出的 Chrome 56 開始，對未進(jìn)行 HTTPS 加密的網(wǎng)址鏈接亮出風(fēng)險提示，即在地址欄的顯著位置提醒用戶“此網(wǎng)頁不安全”。
• 騰訊微信小程序的官方需求文檔要求后臺使用 HTTPS 請求進(jìn)行網(wǎng)絡(luò)通信，不滿足條件的域名和協(xié)議無法請求。

而某些網(wǎng)站雖然使用了 HTTPS 協(xié)議還是會被瀏覽器提示不安全，例如我們在 Chrome 瀏覽器里面打開 12306，鏈接為：https://www.12306.cn/，這時瀏覽器就會提示“您的連接不是私密連接”這樣的話，如圖 2-3 所示：

圖 2-3 12306 頁面
這是因為 12306 的 CA 證書是中國鐵道部自己頒發(fā)給自己的，而這個證書是不被官方機構(gòu)認(rèn)可的，所以這里證書驗證就不會通過而提示這樣的話，但是實際上它的數(shù)據(jù)傳輸依然是經(jīng)過 SSL 加密的。我們?nèi)绻廊∵@樣的站點就需要設(shè)置忽略證書的選項，否則會提示 SSL 鏈接錯誤，在后文會進(jìn)行詳細(xì)說明。

4. HTTP請求過程

我們在瀏覽器中輸入一個 URL，回車之后便會在瀏覽器中觀察到頁面內(nèi)容，實際上這個過程是瀏覽器向網(wǎng)站所在的服務(wù)器發(fā)送了一個 Request，即請求，網(wǎng)站服務(wù)器接收到這個 Request 之后進(jìn)行處理和解析，然后返回對應(yīng)的一個 Response，即響應(yīng)，然后傳回給瀏覽器，Response里面就包含了頁面的源代碼等內(nèi)容，瀏覽器再對其進(jìn)行解析便將網(wǎng)頁呈現(xiàn)了出來，模型如圖 2-4 所示：

圖 2-4 模型圖
此處客戶端即代表我們自己的 PC 或手機瀏覽器，服務(wù)器即要訪問的網(wǎng)站所在的服務(wù)器。
為了更直觀地地說明這個的過程，我們在這里用 Chrome 瀏覽器的開發(fā)者模式下的 Network 監(jiān)聽組件來做下演示，它可以顯示訪問當(dāng)前請求網(wǎng)頁時發(fā)生的所有網(wǎng)絡(luò)請求和響應(yīng)。
打開 Chrome 瀏覽器，右鍵點擊檢查，或按下快捷鍵 F12 即可打開瀏覽器的開發(fā)者工具，我們在這里訪問百度：http://www.baidu.com/，輸入該 URL，敲擊回車訪問這個頁面，觀察一下在這個過程中發(fā)生了怎樣的網(wǎng)絡(luò)請求，這時我們可以看到在 Network 頁面的下方出現(xiàn)了一個個的條目，那么這一個條目就代表一次發(fā)送 Request 和接收 Response 的過程，如圖 2-5 所示：

圖 2-5 Network 面板
我們觀察第一個網(wǎng)絡(luò)請求，即 www.baidu.com，如圖 2-6 所示：

圖 2-6 網(wǎng)絡(luò)請求記錄
這一個條目的各列分別代表：

• 第一列 Name，即 Request 的名稱。一般會用URL的最后一部分內(nèi)容當(dāng)做名稱。
• 第二列 Status，即 Response 的狀態(tài)碼。這里顯示為 200，代表 Response 是正常的，通過狀態(tài)碼我們可以判斷發(fā)送了 Request 之后是否得到了正常的 Response。
• 第三列 Type，即 Request 請求的文檔類型。這里為 document，代表我們這次請求的是一個 HTML 文檔，內(nèi)容就是一些 HTML 代碼。
• 第四列 Initiator，即請求源。用來標(biāo)記 Request 是由哪個對象或進(jìn)程發(fā)起的。
• 第五列 Size，即從服務(wù)器下載的文件和請求的資源大小。如果是從緩存中取得的資源則該列會顯示 from cache。
• 第六列 Time，即發(fā)起 Request 到獲取到 Response 所用的總時間。
• 第七列 Timeline，即網(wǎng)絡(luò)請求的可視化瀑布流。我們點擊這個條目即可看到其更詳細(xì)的信息，如圖 2-7 所示：

圖 2-7 詳細(xì)信息
首先是 General 部分，Request URL 為 Request 的 URL，Request Method 為請求的方法，Status Code 為響應(yīng)狀態(tài)碼，Remote Address 為遠(yuǎn)程服務(wù)器的地址和端口，Referrer Policy 為 Referrer 判別策略。
再繼續(xù)往下看可以看到有一個 Response Headers 和一個 Request Headers，這分別代表響應(yīng)頭和請求頭，請求頭里面帶有許多請求信息，例如瀏覽器標(biāo)識、Cookies、Host 等信息，這是 Request 的一部分，服務(wù)器會根據(jù)請求頭內(nèi)的信息判斷請求是否合法，進(jìn)而作出對應(yīng)的響應(yīng)，返回 Response，那么在圖中看到的 Response Headers 就是 Response 的一部分，例如其中包含了服務(wù)器的類型、文檔類型、日期等信息，瀏覽器接受到 Response 后，會解析響應(yīng)內(nèi)容，進(jìn)而呈現(xiàn)網(wǎng)頁內(nèi)容。
下面我們分別來介紹一下請求 Request 和響應(yīng) Response 都包含了哪些內(nèi)容，在這里進(jìn)行對其組成進(jìn)行總結(jié)：

5. Request

Request，即請求，由客戶端向服務(wù)端發(fā)出。可以將 Request 劃分為四部分內(nèi)容：Request Method、Request URL、Request Headers、Request Body，即請求方式、請求鏈接、請求頭、請求體。

Request Method

請求方式，請求方式常見的有兩種類型，GET 和 POST。
我們在瀏覽器中直接輸入一個 URL 并回車，這便發(fā)起了一個 GET 請求，請求的參數(shù)會直接包含到 URL 里，例如百度搜索 Python，這就是一個 GET 請求，鏈接為：https://www.baidu.com/s?wd=Py...，URL 中包含了請求的參數(shù)信息，這里參數(shù) wd 就是要搜尋的關(guān)鍵字。POST 請求大多為表單提交發(fā)起，如一個登錄表單，輸入用戶名密碼，點擊登錄按鈕，這通常會發(fā)起一個 POST 請求，其數(shù)據(jù)通常以 Form Data 即表單的形式傳輸，不會體現(xiàn)在 URL 中。

GET 和 POST 請求方法有如下區(qū)別：

• GET 方式請求中參數(shù)是包含在 URL 里面的，數(shù)據(jù)可以在 URL 中看到，而 POST 請求的 URL 不會包含這些數(shù)據(jù)，數(shù)據(jù)都是通過表單的形式傳輸，會包含在 Request Body 中。
• GET 方式請求提交的數(shù)據(jù)最多只有 1024 字節(jié)，而 POST 方式?jīng)]有限制。

所以一般來說，網(wǎng)站登錄驗證的時候，需要提交用戶名密碼，這里包含了敏感信息，使用GET方式請求的話密碼就會暴露在URL里面，造成密碼泄露，所以這里最好以POST方式發(fā)送。文件的上傳時，由于文件內(nèi)容比較大，也會選用POST方式。
我們平常遇到的絕大部分請求都是 GET 或 POST 請求，另外還有一些請求方式，如 HEAD、PUT、DELETE、OPTIONS、CONNECT、TRACE，我們簡單將其總結(jié)如下：

Request URL

顧名思義，就是請求的網(wǎng)址，即統(tǒng)一資源定位符，用 URL 可以唯一確定我們想請求的資源。

Request Headers

請求頭，用來說明服務(wù)器要使用的附加信息，比較重要的信息有 Cookie、Referer、User-Agent 等，下面將一些常用的頭信息說明如下：

• Accept，請求報頭域，用于指定客戶端可接受哪些類型的信息。
• Accept-Language，指定客戶端可接受的語言類型。
• Accept-Encoding，指定客戶端可接受的內(nèi)容編碼。
• Host，用于指定請求資源的主機 IP 和端口號，其內(nèi)容為請求 URL 的原始服務(wù)器或網(wǎng)關(guān)的位置。從 HTTP 1.1 版本開始，Request 必須包含此內(nèi)容。
• Cookie，也常用復(fù)數(shù)形式 Cookies，是網(wǎng)站為了辨別用戶進(jìn)行 Session 跟蹤而儲存在用戶本地的數(shù)據(jù)。Cookies 的主要功能就是維持當(dāng)前訪問會話，例如我們輸入用戶名密碼登錄了某個網(wǎng)站，登錄成功之后服務(wù)器會用 Session 保存我們的登錄狀態(tài)信息，后面我們每次刷新或請求該站點的其他頁面時會發(fā)現(xiàn)都是保持著登錄狀態(tài)的，在這里就是 Cookies 的功勞，Cookies 里有信息標(biāo)識了我們所對應(yīng)的服務(wù)器的 Session 會話，每次瀏覽器在請求該站點的頁面時都會在請求頭中加上 Cookies 并將其發(fā)送給服務(wù)器，服務(wù)器通過 Cookies 識別出是我們自己，并且查出當(dāng)前狀態(tài)是登錄的狀態(tài)，所以返回的結(jié)果就是登錄之后才能看到的網(wǎng)頁內(nèi)容。
• Referer，此內(nèi)容用來標(biāo)識這個請求是從哪個頁面發(fā)過來的，服務(wù)器可以拿到這一信息并做相應(yīng)的處理，如做來源統(tǒng)計、做防盜鏈處理等。
• User-Agent，簡稱 UA，它是一個特殊字符串頭，使得服務(wù)器能夠識別客戶使用的操作系統(tǒng)及版本、瀏覽器及版本等信息。在做爬蟲時加上此信息可以偽裝為瀏覽器，如果不加很可能會被識別出為爬蟲。
• Content-Type，即 Internet Media Type，互聯(lián)網(wǎng)媒體類型，也叫做 MIME 類型，在 HTTP 協(xié)議消息頭中，使用它來表示具體請求中的媒體類型信息。例如 text/html 代表 HTML 格式，image/gif 代表 GIF 圖片，application/json 代表 Json 類型，更多對應(yīng)關(guān)系可以查看此對照表：http://tool.oschina.net/commons。

因此，Request Headers 是 Request 等重要組成部分，在寫爬蟲的時候大部分情況都需要設(shè)定 Request Headers。

Request Body

即請求體，一般承載的內(nèi)容是 POST 請求中的 Form Data，即表單數(shù)據(jù)，而對于 GET 請求 Request Body 則為空。
例如在這里我登錄 GitHub 時捕獲到的 Request 和 Response 如圖 2-8 所示：

圖 2-8 詳細(xì)信息
在登錄之前我們填寫了用戶名和密碼信息，提交時就這些內(nèi)容就會以 Form Data 的形式提交給服務(wù)器，此時注意 Request Headers 中指定了 Content-Type 為 application/x-www-form-urlencoded，只有設(shè)置 Content-Type 為 application/x-www-form-urlencoded 才會以 Form Data 形式提交，另外我們也可以將 Content-Type 設(shè)置為 application/json 來提交 Json 數(shù)據(jù)，或者設(shè)置為 multipart/form-data 來上傳文件。
下面列出了 Content-Type 和 POST 提交數(shù)據(jù)方式的關(guān)系：

Content-Type	提交數(shù)據(jù)方式
application/x-www-form-urlencoded	Form表單提交
multipart/form-data	表單文件上傳提交
application/json	序列化Json 數(shù)據(jù)提交
text/xml	XML數(shù)據(jù)提交

在爬蟲中如果我們要構(gòu)造 POST 請求需要注意這幾種 Content-Type，了解各種請求庫的各個參數(shù)設(shè)置時使用的是哪種 Content-Type，不然可能會導(dǎo)致 POST 提交后得不到正常的 Response。
以上便是對 Request 各部分內(nèi)容的解釋。

6. Response

Response，即響應(yīng)，由服務(wù)端返回給客戶端。Response 可以劃分為三部分，Response Status Code、Response Headers、Response Body。

Response Status Code

響應(yīng)狀態(tài)碼，此狀態(tài)碼表示了服務(wù)器的響應(yīng)狀態(tài)，如 200 則代表服務(wù)器正常響應(yīng)，404 則代表頁面未找到，500 則代表服務(wù)器內(nèi)部發(fā)生錯誤。在爬蟲中，我們可以根據(jù)狀態(tài)碼來判斷服務(wù)器響應(yīng)狀態(tài)，如判斷狀態(tài)碼為 200，則證明成功返回數(shù)據(jù)，再進(jìn)行進(jìn)一步的處理，否則直接忽略。
下面用表格列出了常見的錯誤代碼及錯誤原因：

狀態(tài)碼	說明	詳情
100	繼續(xù)	請求者應(yīng)當(dāng)繼續(xù)提出請求。服務(wù)器已收到請求的一部分，正在等待其余部分。
101	切換協(xié)議	請求者已要求服務(wù)器切換協(xié)議，服務(wù)器已確認(rèn)并準(zhǔn)備切換。
200	成功	服務(wù)器已成功處理了請求。
201	已創(chuàng)建	請求成功并且服務(wù)器創(chuàng)建了新的資源。
202	已接受	服務(wù)器已接受請求，但尚未處理。
203	非授權(quán)信息	服務(wù)器已成功處理了請求，但返回的信息可能來自另一來源。
204	無內(nèi)容	服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。
205	重置內(nèi)容	服務(wù)器成功處理了請求，內(nèi)容被重置。
206	部分內(nèi)容	服務(wù)器成功處理了部分請求。
300	多種選擇	針對請求，服務(wù)器可執(zhí)行多種操作。
301	永久移動	請求的網(wǎng)頁已永久移動到新位置，即永久重定向。
302	臨時移動	請求的網(wǎng)頁暫時跳轉(zhuǎn)到其他頁面，即暫時重定向。
303	查看其他位置	如果原來的請求是 POST，重定向目標(biāo)文檔應(yīng)該通過 GET 提取。
304	未修改	此次請求返回的網(wǎng)頁未修改，繼續(xù)使用上次的資源。
305	使用代理	請求者應(yīng)該使用代理訪問該網(wǎng)頁。
307	臨時重定向	請求的資源臨時從其他位置響應(yīng)。
400	錯誤請求	服務(wù)器無法解析該請求。
401	未授權(quán)	請求沒有進(jìn)行身份驗證或驗證未通過。
403	禁止訪問	服務(wù)器拒絕此請求。
404	未找到	服務(wù)器找不到請求的網(wǎng)頁。
405	方法禁用	服務(wù)器禁用了請求中指定的方法。
406	不接受	無法使用請求的內(nèi)容響應(yīng)請求的網(wǎng)頁。
407	需要代理授權(quán)	請求者需要使用代理授權(quán)。
408	請求超時	服務(wù)器請求超時。
409	沖突	服務(wù)器在完成請求時發(fā)生沖突。
410	已刪除	請求的資源已永久刪除。
411	需要有效長度	服務(wù)器不接受不含有效內(nèi)容長度標(biāo)頭字段的請求。
412	未滿足前提條件	服務(wù)器未滿足請求者在請求中設(shè)置的其中一個前提條件。
413	請求實體過大	請求實體過大，超出服務(wù)器的處理能力。
414	請求 URI 過長	請求網(wǎng)址過長，服務(wù)器無法處理。
415	不支持類型	請求的格式不受請求頁面的支持。
416	請求范圍不符	頁面無法提供請求的范圍。
417	未滿足期望值	服務(wù)器未滿足期望請求標(biāo)頭字段的要求。
500	服務(wù)器內(nèi)部錯誤	服務(wù)器遇到錯誤，無法完成請求。
501	未實現(xiàn)	服務(wù)器不具備完成請求的功能。
502	錯誤網(wǎng)關(guān)	服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。
503	服務(wù)不可用	服務(wù)器目前無法使用。
504	網(wǎng)關(guān)超時	服務(wù)器作為網(wǎng)關(guān)或代理，但是沒有及時從上游服務(wù)器收到請求。
505	HTTP 版本不支持	服務(wù)器不支持請求中所用的 HTTP 協(xié)議版本。

Response Headers

響應(yīng)頭，其中包含了服務(wù)器對請求的應(yīng)答信息，如 Content-Type、Server、Set-Cookie 等，下面將一些常用的頭信息說明如下：
Date，標(biāo)識 Response 產(chǎn)生的時間。Last-Modified，指定資源的最后修改時間。Content-Encoding，指定 Response 內(nèi)容的編碼。Server，包含了服務(wù)器的信息，名稱，版本號等。Content-Type，文檔類型，指定了返回的數(shù)據(jù)類型是什么，如text/html 則代表返回 HTML 文檔，application/x-javascript 則代表返回 JavaScript 文件，image/jpeg 則代表返回了圖片。Set-Cookie，設(shè)置Cookie，Response Headers 中的 Set-Cookie即告訴瀏覽器需要將此內(nèi)容放在 Cookies 中，下次請求攜帶 Cookies 請求。Expires，指定 Response 的過期時間，使用它可以控制代理服務(wù)器或瀏覽器將內(nèi)容更新到緩存中，如果再次訪問時，直接從緩存中加載，降低服務(wù)器負(fù)載，縮短加載時間。Resposne Body
即響應(yīng)體，最重要的當(dāng)屬響應(yīng)體內(nèi)容了，響應(yīng)的正文數(shù)據(jù)都是在響應(yīng)體中，如請求一個網(wǎng)頁，它的響應(yīng)體就是網(wǎng)頁的 HTML 代碼，請求一張圖片，它的響應(yīng)體就是圖片的二進(jìn)制數(shù)據(jù)。所以最主要的數(shù)據(jù)都包含在響應(yīng)體中了，我們做爬蟲請求網(wǎng)頁后要解析的內(nèi)容就是解析響應(yīng)體，如圖 2-9 所示：

圖 2-9 響應(yīng)體內(nèi)容
我們在瀏覽器開發(fā)者工具中點擊 Preview，就可以看到網(wǎng)頁的源代碼，這也就是響應(yīng)體內(nèi)容，是解析的目標(biāo)。
我們在做爬蟲時主要解析的內(nèi)容就是 Resposne Body，通過 Resposne Body 我們可以得到網(wǎng)頁的源代碼、Json 數(shù)據(jù)等等，然后從中做相應(yīng)內(nèi)容的提取。Python資源分享qun 784758214 ,內(nèi)有安裝包，PDF，學(xué)習(xí)視頻，這里是Python學(xué)習(xí)者的聚集地，零基礎(chǔ)，進(jìn)階，都?xì)g迎
以上便是 Response 的組成部分。

7. 結(jié)語

本節(jié)我們了解了 HTTP 的基本原理，通過如上描述，我們應(yīng)該對訪問網(wǎng)頁背后的請求和響應(yīng)過程有了大體的認(rèn)識，本節(jié)涉及到的知識點需要好好掌握，在后面分析網(wǎng)頁請求的時候會經(jīng)常用到。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享標(biāo)題：Python3網(wǎng)絡(luò)爬蟲實戰(zhàn)-15、爬蟲基礎(chǔ)：HTTP基本原理-創(chuàng)新互聯(lián)
新聞來源：http://muchs.cn/article0/deihoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、營銷型網(wǎng)站建設(shè)、定制網(wǎng)站、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)