分享一下最近學習到的豆瓣搜索頁爬蟲。
鏈接為：https://search.douban.com/movie/subject_search?search_text={search_text}&cat=1002 ,其中{search_text}為url編碼后的搜索關鍵字。
請求后查看源碼，可以發現，搜索結果的內容並沒有出現在源碼里面。
那么，第一時間反應就是，應該就是ajax一部請求后再渲染到頁面上去的。可是，當打開chrome的檢查模式時，發現並沒有發生異步請求。（xhr類型的文件就是異步請求后返回的結果）
既然不是ajax請求，數據會不會藏在js文件里面呢，打開js，然后選擇某部電影的名稱去搜索，結果啥也沒有。搜索了很多部電影，還是一樣的結果。
后來發現，請求頁面的源代碼里面的window.__DATA__，每次請求都不一樣，而且看樣子像是經過了base64編碼后的字符串，果斷設置斷點。
果然，搜索結果並沒有渲染出來，原來數據就藏在了請求鏈接的源代碼里面。那么先試了一下最簡單粗暴的方法，直接對這個字符串進行base64解碼。一看結果，果然，沒這么簡單。
好了，既然不能直接解碼，那么就找一下解碼的方法。點擊單步運行繼續調試。發現，當執行完bundle.js文件的時候，頁面被渲染出來了，有理由懷疑，這里將window.__DATA__的數據進行解碼了。直接在那個文件里面搜__DATA__。
在5千多行的地方找到了這個數據，觀察了一下這個js文件，像是用了Packer進行js混淆了，先在這里設個斷點。運行后，在右側watch地方將Mt.dispatch(window.__DATA__)輸入進去觀察一下。發現數據出來了。
好了，既然發現了數據是在這里解碼出來了，那么找到解碼的方法，再進行模擬不就行了嗎。定位一下Mt.dispatch()方法的位置。
原來就在它的頭頂。
那么，重新設置斷點，將斷點設置在try里面的return那句上。
這個r不正是__DATA__的數據嗎。好，接着單步運行。
點擊之后發現r的值變了，這里通過右側的call stack前一個調用的函數。
可以發現調用的函數如下。
數據經過一系列處理后，再返回一個鍵為‘688747b7b292207c’的json數據，那么先定位每一個處理數據的函數，看看是怎么實現的。很悲催，當定位到第一個處理方法的時候，發現該方法的實現，在另一個js文件。
這個js文件也是經過了js混淆，很難看出里面函數的調用邏輯，而且這次返回的結果還不是最終需要的數據。先不管那么多，單步調式到數據出來再說了。
最后發現，數據接着處理了好幾次，才會出現最終需要的數據。完全傻眼了，去百度吧，但是找了好久，都沒看到解決的方法，再快要放棄的時候，終於找到了大佬。原文鏈接是：https://mp.weixin.qq.com/s/2mpu_oY2-M0wcLvf1eU7Sw
這位大佬將每一個處理的函數都扣了出來，牛逼。按照他的步驟，最后成功獲取到了需要的數據（推文里面的是圖書搜索，將鏈接換成電影搜索的一樣可行）。
最后再總結一下，這個js逆向真的很費時間，個人還是覺得用selenium或者pyppeteer開發會比較簡單。