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

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

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

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

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

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

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

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

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

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īng) HTTP請求 URL中的 page參數(shù)； total Items值代表該公眾號所發(fā)布的文章總數(shù)； total Pages值代表可供查詢的最大頁號（目前最多只能查詢至 100頁）； items值代表本次查詢返回的數(shù)據(jù)，其數(shù)據(jù)

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

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

13、號 openid標(biāo)識。考慮到目前微信公眾平臺認(rèn)證賬號已經(jīng)超過 800萬，總數(shù)較大，對所有公眾號進(jìn)行爬取需要較長時(shí)間，故需要按照某種原則來設(shè)定公眾號的爬取先后順序。第一種途徑是通過各個(gè)類別的導(dǎo)航頁面來采集公眾號，導(dǎo)航頁面的公眾號往往是熱門賬號，故本文采用第一種途徑，優(yōu)先爬取這些熱門公眾號。3.2.2爬取流程設(shè)計(jì)本文主要是使用節(jié)第一種途徑來采集微信公眾號的 openid標(biāo)識，再進(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)航類別下某一頁的地址；第二種類型的URL 為某個(gè)公眾號的主頁地址；第三種類型的 URL 為某個(gè)公眾號所發(fā)布的文章的某一頁的地址；第四種類型的 URL 為某篇文章的地址。 本文將這 4 種類型的 URL 分別稱為 init 類型（種子 URL）、index 類型（主頁 URL）、page 類型（文章分頁 URL）、msg

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

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

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

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

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

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

21、隊(duì)列中所有的index 類型 URL 都被取出為止。（8）現(xiàn)在，URL 隊(duì)列中僅有 page 類型的 URL，故調(diào)度器模塊會將隊(duì)頭的page 類型 URL 取出，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給下載器模塊。下載器模塊將該網(wǎng)頁爬取下來后，封裝成一個(gè) Response 對象，經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給爬蟲模塊。（9）爬蟲模塊針對 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)先級為 1 將其放入 URL 隊(duì)列中；從該頁面中分析提取出文章的相關(guān)信息

22、，封裝成若干個(gè)Msg Item 對象，將其經(jīng)爬蟲引擎轉(zhuǎn)發(fā)給數(shù)據(jù)流水線模塊。數(shù)據(jù)流水線模塊收到Msg Item 對象后，將文章的封面圖片、網(wǎng)頁 HTML 源文件上傳至 Fast DFS 集群，同時(shí)將文章的相關(guān)信息存入 My SQL 數(shù)據(jù)庫的 msg 表中。并且，每爬取到一個(gè)Msg Item 對象后，都會判斷該對象之前是否已經(jīng)爬取到，若是則停止對當(dāng)前公眾號的爬取，即不會將當(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)度器模塊會再次從配置文件中讀取 2

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

24、 item, spider): # 流水線模塊的接口函數(shù) if item and item'type' = 'public': # 僅對 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連接對象。Item對象的type字段用于標(biāo)識當(dāng)前 Item所存儲的信息類型，其值包括 'public' 和 'msg' 兩種。當(dāng)值為 'public'時(shí)表明， Item

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

27、' = 'msg': # 僅對 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對象中的biz字段為 URL地址中的_biz參數(shù)，其余各字段的含義見表 3.2。另外， msg_name， cover_name字段分別為文章的 HTML源文件、封面圖片文件上傳至 Fast DFS 集群后的保存文件名，故在進(jìn)行此操作前，還需要先完成文件上傳，由 Upload Pipeline模塊負(fù)責(zé)

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

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