微信公眾平臺(tái)的信息爬取

1、微信公眾號(hào)的信息獲取分析目錄1微信公眾平臺(tái)背景12采集的方案及難點(diǎn)12.1微信沒有公開的搜索接口12.2常規(guī)思路及問(wèn)題13國(guó)內(nèi)研究現(xiàn)狀23.1提出的方案23.1.1舊方案23.1.2新方案33.2成熟的分布式微信公眾平臺(tái)信息爬取43.3公眾號(hào)信息存儲(chǔ)93.4文章信息存儲(chǔ)94個(gè)人設(shè)想105總結(jié)與展望121微信公眾平臺(tái)背景微信是騰訊公司于 2011 年推出的移動(dòng)社交平臺(tái)，目前已累計(jì)超過(guò) 6億的注冊(cè)用戶。而 2012 年推出的微信公眾平臺(tái)依托于微信的海量用戶也迅速流行起來(lái)，目前該平臺(tái)的注冊(cè)公眾號(hào)賬號(hào)早已超過(guò) 800 萬(wàn)，累計(jì)發(fā)布了超過(guò) 2億的文章。依托大量的移動(dòng)端用戶，微信公眾平臺(tái)推出服務(wù)號(hào)，訂閱號(hào)

2、和企業(yè)號(hào)，通過(guò)這三種賬號(hào)達(dá)到消息推送，信息交流，信息互動(dòng)的目的，且越來(lái)越多的企業(yè)和用戶通過(guò)微信公眾平臺(tái)進(jìn)行網(wǎng)絡(luò)營(yíng)銷，網(wǎng)絡(luò)信息化服務(wù)，網(wǎng)絡(luò)宣傳等， 微信公眾平臺(tái)已經(jīng)成為了繼微博和QQ之后新型網(wǎng)絡(luò)平臺(tái)，平臺(tái)通過(guò)提供私密接口的方式讓微信用戶與服務(wù)端進(jìn)行信息交流與互動(dòng)，這大大節(jié)省了服務(wù)端企業(yè)對(duì)其服務(wù)產(chǎn)品的再包裝和再推廣的費(fèi)用，再加上公眾號(hào)內(nèi)簡(jiǎn)單易操作的界面使大量的用戶對(duì)其青睞有加。所以對(duì)微信公眾平臺(tái)的關(guān)鍵信息爬取，能夠及時(shí)獲取有價(jià)值的信息，為企業(yè)和個(gè)人提供信息指導(dǎo)，對(duì)企業(yè)和個(gè)人的決策做到參考作用。因此對(duì)微信公眾平臺(tái)的信息爬取的研究有重要意義。2采集的方案及難點(diǎn)2.1微信沒有公開的搜索接口由于微信尚未有

3、公開的搜索接口供第三方的搜索引擎爬取，而且微信也未提供官方權(quán)威的微信公眾號(hào)的導(dǎo)航網(wǎng)站或推薦服務(wù)，因此指望完成對(duì)所有微信公眾號(hào)的爬取并不現(xiàn)實(shí)，只能對(duì)指定微信公眾號(hào)的內(nèi)容進(jìn)行爬取。2.2常規(guī)思路及問(wèn)題已知對(duì)所有公眾號(hào)直接爬取占時(shí)不現(xiàn)實(shí)，那么對(duì)微信公眾號(hào)的指定內(nèi)容爬取主要分為如下一些步驟：第一步就是獲得需要爬取的微信公眾號(hào)列表 微信公眾號(hào)列表可以參考那些微信導(dǎo)航站的做法，人工維護(hù)維護(hù)行業(yè)精品微信號(hào)列表。當(dāng)然也可以直接爬取那些微信導(dǎo)航站，但質(zhì)量很差。好在真正高質(zhì)量值得爬取微信公眾號(hào)也就至多上萬(wàn)個(gè)。第二部就是要獲取每一個(gè)微信公眾號(hào)的內(nèi)容入口頁(yè)面。 隨便留意一下某個(gè)微信公眾號(hào)，會(huì)發(fā)現(xiàn)每個(gè)微信公眾號(hào)的“查看

4、歷史消息”中有此公眾號(hào)已發(fā)布的所有微信內(nèi)容，剩下的問(wèn)題是怎樣獲取這個(gè)地址。 一般程序員的思路是通過(guò)抓包、反編譯等手段來(lái)獲取此入口地址。好消息是要獲取此微信公眾號(hào)的入口地址并不復(fù)雜，你會(huì)欣喜發(fā)現(xiàn)此入口地址是一個(gè)普通的網(wǎng)頁(yè)。壞消息是：當(dāng)你多測(cè)試一下，你會(huì)發(fā)現(xiàn)如下問(wèn)題： 1）、此入口地址并不是固定不變的，一天左右就會(huì)變化的，主要是里面的key值。因此指望通過(guò)人工手工抓包一勞永逸地獲取的地址并無(wú)太多實(shí)用價(jià)值 2）、此入口頁(yè)面對(duì)未關(guān)注的用戶只能看第一頁(yè)，需要關(guān)注后才能看后續(xù)頁(yè)面，要獲取后續(xù)頁(yè)面，只能關(guān)注此賬號(hào)，但要人工關(guān)注上萬(wàn)個(gè)來(lái)自更多賬號(hào)的關(guān)注并不現(xiàn)實(shí) 3）、微信對(duì)一個(gè)賬號(hào)關(guān)注的公眾號(hào)數(shù)是有上限限制的

5、 應(yīng)對(duì)此難題最一勞永逸的方案當(dāng)然是反編譯代碼，獲取微信的通信協(xié)議，但就研究結(jié)果來(lái)看，成本過(guò)高，破解的可能性也不大。3國(guó)內(nèi)研究現(xiàn)狀3.1提出的方案3.1.1舊方案 在2015年的時(shí)候微信網(wǎng)頁(yè)版限制還是沒那么嚴(yán)格的, 當(dāng)時(shí)采用的主要思路是使用微信網(wǎng)頁(yè)版, 然后用requests去模擬登陸一下,然后不停的去訪問(wèn)類似下面的接口爬取信息: > 當(dāng)時(shí)為了能讓爬蟲多個(gè)實(shí)例跑, 用了一下 Celery 框架(現(xiàn)在想簡(jiǎn)直智障, 多個(gè)實(shí)例跑直接把程序啟動(dòng)N次就行了啊。摔), 由于是模擬登陸, 所以又寫了一套復(fù)雜的東西去生成二維碼, 然后獲取登陸URL, 具體的模擬登陸原理參考這個(gè) wechat-delete

6、d-friends, 另外相關(guān)的Celery Task里寫的邏輯太復(fù)雜了, 一個(gè)Task里就帶上了 requests斷線重連機(jī)制, 模擬登陸機(jī)制, 解析列表, 解析文章等, 另外由于是web版微信有一套蠻復(fù)雜的sync機(jī)制, 有時(shí)候直接掉線需要再次的去手動(dòng)登陸, 很是麻煩。之后web版微信已經(jīng)無(wú)法的獲取Key了(2016年開始), 此方案就廢棄了。3.1.2新方案 經(jīng)leader提醒, 改了一下架構(gòu), 其中項(xiàng)目的整體結(jié)構(gòu)如下: 微信爬蟲架構(gòu)圖Seeds 是一個(gè)producer, 在此處指通過(guò)某種方式獲取 uin, key, pass_ticket 信息, 思路類似中間人攻擊+解析squid日志

7、 Consumer C1從Q1隊(duì)列中取出seeds后爬取某個(gè)公眾號(hào)的文章列表, 解析后將文章Meta信息放入隊(duì)列Q2 Consumer C2獲取文章原信息后就可以直接做入庫(kù)&爬取操作了 之后可以繼續(xù)加隊(duì)列然后去實(shí)現(xiàn)爬取文章閱讀點(diǎn)贊的相關(guān)數(shù)據(jù)了, 由于有頻率限制。一個(gè)微信號(hào)一天只能最多獲取8000篇文章的閱讀點(diǎn)贊信息 拋棄了Celery和其默認(rèn)選用的RabbitMQ隊(duì)列, 這種東西實(shí)在太重了。改用beanstalkd做消息隊(duì)列 目前的效果是單微信號(hào)每日更新4w左右的公眾號(hào)文章, 如果想繼續(xù)增加數(shù)量可以通過(guò)加機(jī)器來(lái)擴(kuò)展 3.2成熟的分布式微信公眾平臺(tái)信息爬取3.2.1爬取策略分析由于目前微

8、信公眾平臺(tái)并沒有開放官方的Web網(wǎng)站，因此，無(wú)法直接對(duì)微信公眾號(hào)官方網(wǎng)站進(jìn)行采集。然而，搜狗搜索引擎已針對(duì)微信公眾平臺(tái)進(jìn)行資源整合，并提供搜索功能。因此，本系統(tǒng)基于搜狗微信搜索進(jìn)行爬取。在使用 Chrome瀏覽器 Web開發(fā)工具對(duì)搜狗微信搜索網(wǎng)站的網(wǎng)頁(yè)組成結(jié)構(gòu)及特性進(jìn)行分析后發(fā)現(xiàn)，每個(gè)公眾號(hào)賬號(hào)在搜狗微信搜索平臺(tái)都有一個(gè)主頁(yè)。例如，公眾號(hào)“英國(guó)那些事兒”的主頁(yè)網(wǎng)址為： IWs Ftyww Cs Yrq K8-7v QQ_tf Lphc 實(shí)際上，搜狗微信搜索使用 28位字符的 openid參數(shù)對(duì)每個(gè)公眾號(hào)賬號(hào)進(jìn)行唯一標(biāo)識(shí)。而在該主頁(yè)下，有該公眾號(hào)的發(fā)布文章列表，按文章的發(fā)布時(shí)間從近至遠(yuǎn)排序，每頁(yè)

9、 10篇文章，默認(rèn)顯示的第一頁(yè)為最近的 10篇文章，點(diǎn)擊 “查看更多”鏈接后，會(huì)觸發(fā)瀏覽器發(fā)出 Ajax請(qǐng)求以獲取下一頁(yè)內(nèi)容，其URL如下： IWs Ftyww CsYrq K8-7v QQ_tf Lphc&page=2 仔細(xì)觀察上述的URL，可知 openid參數(shù)對(duì)應(yīng)該公眾號(hào)賬號(hào)的 openid， page參數(shù)代表第幾頁(yè)，而 URL的其余內(nèi)容則固定不變。因此，可以通過(guò)不斷地改變page參數(shù)的值，來(lái)獲取該公眾號(hào)所發(fā)布的所有文章。瀏覽器發(fā)出 Ajax請(qǐng)求并獲取到響應(yīng)數(shù)據(jù)后，會(huì)通過(guò) Java Script實(shí)現(xiàn)無(wú)刷新地更新當(dāng)前網(wǎng)頁(yè)內(nèi)容，將獲取到的新的 10篇文章的內(nèi)容信息延伸到當(dāng)前網(wǎng)頁(yè)的南華

10、大學(xué)碩士論文 22底部。每個(gè) URL的HTTP響應(yīng)數(shù)據(jù)，實(shí)質(zhì)上主要是一個(gè) json格式的字符串，其內(nèi)容如下所示： "page":2, "items": 略 "total Items":3035, "total Pages":100 各個(gè)參數(shù)的含義也比較明顯，其中， page 值代表當(dāng)前頁(yè)號(hào)，對(duì)應(yīng) HTTP請(qǐng)求 URL中的 page參數(shù)； total Items值代表該公眾號(hào)所發(fā)布的文章總數(shù)； total Pages值代表可供查詢的最大頁(yè)號(hào)（目前最多只能查詢至 100頁(yè)）； items值代表本次查詢返回的數(shù)據(jù)，其數(shù)據(jù)

11、類型是數(shù)組，數(shù)組的每一個(gè)元素則是一個(gè)xml格式的字符串。并且，能夠從該字符串中提取到關(guān)于這篇文章的標(biāo)題、摘要、封面圖片地址、文章頁(yè)面地址、公眾號(hào)頭像地址等信息。通過(guò)上述的分析可以得知，如果已知某公眾號(hào)賬號(hào)的 openid標(biāo)識(shí)，即可爬取到該公眾號(hào)所發(fā)布的所有文章。因此，為了獲取所有公眾號(hào)的所有文章，就必須獲取到所有公眾號(hào)賬號(hào)的 openid標(biāo)識(shí)。目前，經(jīng)過(guò)探索后發(fā)現(xiàn)，可以通過(guò)以下兩種途徑來(lái)獲取公眾號(hào)賬號(hào)的 openid標(biāo)識(shí)： 第一種途徑是借助搜狗微信搜索首頁(yè)提供的分類導(dǎo)航列表，如熱門、汽車迷、養(yǎng)生堂等導(dǎo)航列表，其 URL地址如下： 其中， digit1取值為 019的數(shù)字，代表導(dǎo)航類別； dig

12、it2為 114的數(shù)字，代表該類別下的第幾頁(yè)內(nèi)容。每一個(gè)導(dǎo)航列表都有大量的文章，文章旁則就有該篇文章的發(fā)布者的主頁(yè)鏈接，從而也就能夠提取出其openid 標(biāo)識(shí)。并且，這些導(dǎo)航列表的內(nèi)容是會(huì)隨時(shí)間而動(dòng)態(tài)更新的。因此，可以定時(shí)地采集這些導(dǎo)航列表頁(yè)面，這樣一來(lái)，當(dāng)經(jīng)過(guò)足夠長(zhǎng)的時(shí)間后，就可以采集到足夠多的公眾號(hào)openid標(biāo)識(shí)。第二種途徑是借助搜狗微信搜索的文章搜索功能，可以通過(guò)輸入某個(gè)關(guān)鍵字如“搞笑”進(jìn)行搜索。搜索結(jié)果中會(huì)包含大量由不同公眾號(hào)賬號(hào)發(fā)布的文章，而文章旁也有其發(fā)布公眾號(hào)的主頁(yè)鏈接，從而也就可以提取出其 openid標(biāo)識(shí)。而且，搜索結(jié)果中往往會(huì)包含數(shù)萬(wàn)條結(jié)果，因此可以快速地獲取到大量的公眾

13、號(hào) openid標(biāo)識(shí)?？紤]到目前微信公眾平臺(tái)認(rèn)證賬號(hào)已經(jīng)超過(guò) 800萬(wàn)，總數(shù)較大，對(duì)所有公眾號(hào)進(jìn)行爬取需要較長(zhǎng)時(shí)間，故需要按照某種原則來(lái)設(shè)定公眾號(hào)的爬取先后順序。第一種途徑是通過(guò)各個(gè)類別的導(dǎo)航頁(yè)面來(lái)采集公眾號(hào)，導(dǎo)航頁(yè)面的公眾號(hào)往往是熱門賬號(hào)，故本文采用第一種途徑，優(yōu)先爬取這些熱門公眾號(hào)。3.2.2爬取流程設(shè)計(jì)本文主要是使用節(jié)第一種途徑來(lái)采集微信公眾號(hào)的 openid標(biāo)識(shí)，再進(jìn)行文章的采集。整個(gè)系統(tǒng)中，主要涉及有以下 4種類型的 URL： IWs Ft2hz LQ_Ra TIXp5B5ti0Yx Lw IWs Ft2hz LQ_Ra TIXp5B5ti0Yx Lw&page=1 A4ND

14、Iz Nj Qz NQ=&mid=206132589&idx=1&sn=feea5e7f33bf1cfe18b71f25d495f27c&3rd=Mz A3MDU4NTYz Mw=&scene=6#rd 其中，第一種類型的 URL 為某個(gè)導(dǎo)航類別下某一頁(yè)的地址；第二種類型的URL 為某個(gè)公眾號(hào)的主頁(yè)地址；第三種類型的 URL 為某個(gè)公眾號(hào)所發(fā)布的文章的某一頁(yè)的地址；第四種類型的 URL 為某篇文章的地址。 本文將這 4 種類型的 URL 分別稱為 init 類型（種子 URL）、index 類型（主頁(yè) URL）、page 類型（文章分頁(yè) URL）、msg

15、 類型（文章 URL）。除第一種類型的 URL 是在配置文件中指定的種子 URLs 外，其余三種類型的 URL 都是從后續(xù)爬取到的網(wǎng)頁(yè)中提取出來(lái)的。當(dāng)爬蟲模塊抓取到這些 URL 后，會(huì)通過(guò)爬蟲引擎將其交給調(diào)度器模塊，由調(diào)度器模塊負(fù)責(zé)將其放入 URL 隊(duì)列中，并且調(diào)度器模塊會(huì)針對(duì) init 類型、index類型、page 類型這三種不同類型的 URL，在放入隊(duì)列時(shí)將其優(yōu)先級(jí)分別設(shè)置為3、2、1，數(shù)字越大，則優(yōu)先級(jí)越高。最終使得調(diào)度器模塊從 URL 隊(duì)列中取出URL 時(shí)，會(huì)優(yōu)先取出 init 類型的 URL，其次才是 index 類型、page 類型。即，僅當(dāng) URL 隊(duì)列中不存在 init 類型

16、的 URL 時(shí)，調(diào)度器才會(huì)取出 index 類型的 URL，以此類推。而在爬取到 msg 類型的 URL 后，無(wú)需將其放入待爬取 URL 隊(duì)列中。 之所以將 init 類型 URL 設(shè)置為最高爬取優(yōu)先級(jí)，主要是考慮到系統(tǒng)的首要任務(wù)是盡可能多地爬取公眾號(hào)賬號(hào)，因?yàn)橐坏┡廊〉侥硞€(gè)公眾號(hào)，后續(xù)系統(tǒng)即可無(wú)依賴地對(duì)該公眾號(hào)的賬號(hào)信息、發(fā)布文章信息依次進(jìn)行爬取。而一旦不能爬取到新的未爬取公眾號(hào)，后續(xù)的爬取流程無(wú)法順利進(jìn)行。而 init 類型的導(dǎo)航頁(yè)會(huì)定時(shí)更新，應(yīng)盡可能地將每次更新后出現(xiàn)的新公眾號(hào)都爬取到。因此，采取優(yōu)先爬取所有導(dǎo)航頁(yè)面中出現(xiàn)的所有公眾號(hào)的策略，即設(shè)置 init 類型 URL為最高爬取優(yōu)先級(jí)

17、。 考慮到對(duì)于每個(gè)公眾號(hào)而言，其 index 類型的 URL 只有一個(gè)，而 page 類型的 URL 則有多個(gè)，故先爬取 index 類型的 URL。另外，在 index 類型 URL 爬取到的 Public Item 需要存入 public 表，在 page 類型 URL 爬取到的 Msg Item 需要存入 msg 表，而為了能夠確定每個(gè) msg 記錄的所屬 public 記錄，msg 表中需要有對(duì) public 表的外鍵引用字段，因此也決定了必須先爬取 index 類型 URL。圖 3.6 說(shuō)明了針對(duì) URL 隊(duì)列中 3 種不同類型的 URL，爬蟲模塊需要對(duì)其進(jìn)行的相應(yīng)操作的概要說(shuō)明，具

18、體過(guò)程如下：（1）首先，爬蟲系統(tǒng)啟動(dòng)后，會(huì)從配置文件中讀取 280 個(gè)（20x14=280）init 類型的 URL 作為初始爬取 URLs 集合，并由調(diào)度器模塊以優(yōu)先級(jí)為 3 將其放入 URL 隊(duì)列中。（2）此時(shí)，URL 隊(duì)列中僅有 init 類型的 URL，故調(diào)度器模塊會(huì)將隊(duì)頭的init 類型 URL 取出，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給下載器模塊。下載器模塊將該網(wǎng)頁(yè)爬取下來(lái)后，封裝成一個(gè) Response 對(duì)象，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給爬蟲模塊。（3）爬蟲模塊針對(duì) init 類型的 URL 的處理操作是：從該頁(yè)面中分析提取出 index 類型的 URL，并將其經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給調(diào)度器模塊，由調(diào)度器模塊以優(yōu)先級(jí)為

19、 2 將其放入 URL 隊(duì)列中。（4）此時(shí)，URL 隊(duì)列中有 init 類型、index 類型的 URL，由于 init 類型URL 的優(yōu)先級(jí)更高，故會(huì)繼續(xù)重復(fù)第 2-3 步驟的操作，直至 URL 隊(duì)列中所有的init 類型 URL 都被取出為止。（5）現(xiàn)在，URL 隊(duì)列中僅有 index 類型的 URL，故調(diào)度器模塊會(huì)將隊(duì)頭的index 類型 URL 取出，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給下載器模塊。下載器模塊將該網(wǎng)頁(yè)爬取下來(lái)后，封裝成一個(gè) Response 對(duì)象，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給爬蟲模塊。（6）爬蟲模塊針對(duì) index 類型的 URL 的處理操作是：生成一個(gè)與當(dāng)前 URL中 openid 參數(shù)所對(duì)應(yīng)的 p

20、age=1 的 page 類型 URL，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給調(diào)度器模塊，由調(diào)度器模塊以優(yōu)先級(jí)為 1 將其放入 URL 隊(duì)列中；并且，從該頁(yè)面中分析提取出該公眾號(hào)的相關(guān)信息，封裝成一個(gè) Public Item 對(duì)象，將其經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給數(shù)據(jù)流水線模塊。數(shù)據(jù)流水線模塊收到 Public Item 對(duì)象后，將該公眾號(hào)的頭像圖片、二維碼圖片上傳至 Fast DFS 集群，同時(shí)將公眾號(hào)的相關(guān)信息存入My SQL 數(shù)據(jù)庫(kù)的 public 表中。（7）此時(shí)，URL 隊(duì)列中有 index 類型、page 類型的 URL，由于 index 類型URL 的優(yōu)先級(jí)更高，故會(huì)繼續(xù)重復(fù)第 5-6 步驟的操作，直至 URL

21、隊(duì)列中所有的index 類型 URL 都被取出為止。（8）現(xiàn)在，URL 隊(duì)列中僅有 page 類型的 URL，故調(diào)度器模塊會(huì)將隊(duì)頭的page 類型 URL 取出，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給下載器模塊。下載器模塊將該網(wǎng)頁(yè)爬取下來(lái)后，封裝成一個(gè) Response 對(duì)象，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給爬蟲模塊。（9）爬蟲模塊針對(duì) page 類型的 URL 的處理操作是：判斷響應(yīng)數(shù)據(jù)中的total Pages 參數(shù)是否大于當(dāng)前 URL 的 page 參數(shù)，若是則將當(dāng)前 URL 的 page 參數(shù)值+1 后，將其經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給調(diào)度器模塊，由調(diào)度器模塊以優(yōu)先級(jí)為 1 將其放入 URL 隊(duì)列中；從該頁(yè)面中分析提取出文章的相關(guān)信息

22、，封裝成若干個(gè)Msg Item 對(duì)象，將其經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給數(shù)據(jù)流水線模塊。數(shù)據(jù)流水線模塊收到Msg Item 對(duì)象后，將文章的封面圖片、網(wǎng)頁(yè) HTML 源文件上傳至 Fast DFS 集群，同時(shí)將文章的相關(guān)信息存入 My SQL 數(shù)據(jù)庫(kù)的 msg 表中。并且，每爬取到一個(gè)Msg Item 對(duì)象后，都會(huì)判斷該對(duì)象之前是否已經(jīng)爬取到，若是則停止對(duì)當(dāng)前公眾號(hào)的爬取，即不會(huì)將當(dāng)前 URL 的 page 參數(shù)值+1 的 page 類型 URL 放入 URL 隊(duì)列中。（10）當(dāng) URL 隊(duì)列中所有的 page 類型 URL 都已經(jīng)出隊(duì)被處理完后， URL隊(duì)列為空，此時(shí)，調(diào)度器模塊會(huì)再次從配置文件中讀取 2

23、80 個(gè) init 類型的 URL，并將其放入 URL 隊(duì)列中，從而繼續(xù)重復(fù)第 2-9 步驟的操作。以上爬取流程會(huì)一直執(zhí)行，直至人為關(guān)閉系統(tǒng)或系統(tǒng)出現(xiàn)故障為止。必須說(shuō)明的是，調(diào)度器模塊在每次收到 URL 時(shí)，除 init 類型 URL 外，都會(huì)對(duì)收到的 URL 進(jìn)行請(qǐng)求指紋去重，以保證放入 URL 隊(duì)列中的 URL 沒有重復(fù)。3.3公眾號(hào)信息存儲(chǔ)對(duì)公眾號(hào)信息的存儲(chǔ)是通過(guò)流水線中的 Public Pipeline模塊實(shí)現(xiàn)，其負(fù)責(zé)將公眾號(hào)的詳細(xì)信息存儲(chǔ)至 My SQL數(shù)據(jù)庫(kù)中，其主要代碼如下：class Public Pipeline(object): def process_item(self,

24、 item, spider): # 流水線模塊的接口函數(shù) if item and item'type' = 'public': # 僅對(duì) Public Item 進(jìn)行處理 i = item sql = "insert into public(username, nickname, openid, two_url, two_name, pic_url, pic_name, brief, create_at) value(%s,%s,%s,%s,%s,%s,%s,%s,now()" self.mysql.execute(sql, i'us

25、ername', i'nickname', i'openid', i'two_url', i'two_name', i'pic_url', i'pic_name', i'brief') return item其中， self.mysql為 已經(jīng)創(chuàng)建的 My SQL連接對(duì)象。Item對(duì)象的type字段用于標(biāo)識(shí)當(dāng)前 Item所存儲(chǔ)的信息類型，其值包括 'public' 和 'msg' 兩種。當(dāng)值為 'public'時(shí)表明， Item

26、對(duì)象所帶的信息是公眾號(hào)信息。另外， pic_name， two_name字段分別為公眾號(hào)頭像圖片、二維碼圖片上傳至 Fast DFS集群后的保存文件名，故在進(jìn)行此操作前，還需要先完成文件上傳，由 Upload Pipeline模塊負(fù)責(zé)。 3.4文章信息存儲(chǔ)對(duì)文章信息的存儲(chǔ)是通過(guò)流水線中的 Msg Pipeline模塊實(shí)現(xiàn)，其負(fù)責(zé)將文章的詳細(xì)信息存儲(chǔ)至 My SQL數(shù)據(jù)庫(kù)中，其主要代碼如下：class Msg Pipeline(object): def process_item(self, item, spider): # 流水線模塊的接口函數(shù) if item and item'type

27、' = 'msg': # 僅對(duì) Msg Item進(jìn)行處理 # 根據(jù) URL中的_biz參數(shù)獲取 pid值pid, i = self.get_pid_by_biz(item'biz'), item sql = "insert into msg(title, brief, msg_url, msg_name, cover_url, cover_name, post_at, create_at) value(%s, %s, %s, %s, %s, %s, %s, now()" self.mysql.execute(sql, i'ti

28、tle', i'brief', i'msg_url', i'msg_name', i'cover_url', i'cover_name', i'post_at') return itemItem對(duì)象中的biz字段為 URL地址中的_biz參數(shù)，其余各字段的含義見表 3.2。另外， msg_name， cover_name字段分別為文章的 HTML源文件、封面圖片文件上傳至 Fast DFS 集群后的保存文件名，故在進(jìn)行此操作前，還需要先完成文件上傳，由 Upload Pipeline模塊負(fù)責(zé)

29、。 4個(gè)人設(shè)想微信公眾號(hào)存在不少精彩的文章，如果善于挖掘，可以得到不少的收獲。但由于微信對(duì)PC端的支持并不友好，雖然有搜狗搜索可以用，但其結(jié)果仍然不全，一些公眾號(hào)發(fā)的不是文章類型的只是一段話，搜狗就不收錄。想要得到一個(gè)賬號(hào)所有的文章，還是要從爬蟲著手。網(wǎng)上對(duì)于微信公眾號(hào)文章爬取的方法幾乎沒有介紹，不過(guò)有幾個(gè)網(wǎng)站，比如傳送門就做出來(lái)了。這就告訴我們這個(gè)目標(biāo)是可以達(dá)到的。要想得到一個(gè)公眾號(hào)發(fā)送的所有文章，需要從微信手機(jī)端入手。點(diǎn)擊公眾號(hào)右上角小人圖標(biāo)，會(huì)有查看歷史消息的鏈接。點(diǎn)了之后可查看所有歷史文章。所以自然要從這里入手了。上抓包工具，F(xiàn)iddler4，手機(jī)和電腦接入同一網(wǎng)絡(luò)，手機(jī)wlan設(shè)置代

30、理，指向電腦的ip地址，端口默認(rèn)8888，這樣在電腦上就可以監(jiān)聽手機(jī)的http流量了。通過(guò)抓包，在點(diǎn)擊查看歷史消息選項(xiàng)時(shí)，請(qǐng)求的地址是 通過(guò)對(duì)多個(gè)賬號(hào)進(jìn)行抓包分析，可以確定biz這個(gè)14位的字符串是每個(gè)公眾號(hào)的“id”，uin似乎與訪問(wèn)者有關(guān)，key也和所訪問(wèn)的公眾號(hào)有關(guān)，可以在下面的抓取中得到這兩個(gè)參數(shù)，其他的查詢參數(shù)都可以去掉。 所以，必須得到三個(gè)參數(shù)才可以得到文章列表。這三個(gè)參數(shù)biz最容易獲得，在搜狗的微信平臺(tái),搜索目標(biāo)公眾號(hào)，會(huì)有對(duì)應(yīng)的文章列表，連接到相應(yīng)的文章頁(yè)面。解析文章列表，即可得到公共賬號(hào)的biz?？梢酝ㄟ^(guò)請(qǐng)求 現(xiàn)在，已知biz，如何繼續(xù)？我曾經(jīng)也困擾了好久，也算是偶然發(fā)現(xiàn)的。電腦登陸微信，在手機(jī)上訪問(wèn)某個(gè)公眾號(hào)的查看歷史消息頁(yè)面，點(diǎn)擊右上角，發(fā)送給朋友，發(fā)送給文件助手即可，電腦上查看。 似乎看到連接了，打開，果然跳轉(zhuǎn)到了文章列表的頁(yè)面！查看元素，這個(gè)存在span標(biāo)簽內(nèi)，仔細(xì)觀察發(fā)現(xiàn)和剛才抓包看到的url是一樣的！繼續(xù)尋