豆瓣搜索页爬虫

分享一下最近学习到的豆瓣搜索页爬虫。

链接为: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开发会比较简单。

posted @ 2020-05-12 00:11  一个小哥哥  阅读(4336)  评论(0编辑  收藏  举报