​

 原创来自本人的公众号：阿嚏个技术

公众号文章地址：得物采集数据出现geetest验证码的解析方式

本文仅提供反爬技术的分析思路，勿做商业用途，如有侵权，请联系删除。

之前写过一篇爬得物数据的文章《毒（得物）APP历史购买数据抓取》，阅读数还是挺不错的，不过那篇文章其实有些误导，当时是通过在手机上模拟用户的点击和滑屏操作，然后获取相关页面，再对内容进行识别来获取所需数据，那种方式一是效率不高，2天还没解析完一个商品的历史数据；二是数据误差大，因为模拟滑屏操作有定位和延时加载的问题，会导致很多重复数据。有些网友也指出了其中的问题，有网友也说api的效率高，的确研究了其API后做的采集方式很快，一个商品的数据基本就是分分钟的事情。

不过......

得物也是在不断进化的，很快接口的方式发生了变化，甚至有些接口已经失效。相信前一段时间跑API的朋友，会发现接口会经常返回401（请求直接被拒绝），485（请求需要验证码）的错。例如：

{"code":485,"data":{"challenge":"202c8c44a1226df446e1207519df6180","gt":"2acebf85e53151975f4a82b8a812ff02","newCaptcha":true,"resultCode":485,"serverStatus":1},"msg":"请校验验证码","status":485}

出现验证码的情况，手机APP人工操作也是会出现的，为了防爬得物还是牺牲了一些用户体验。

那么下面就是针对这种情况进行分析，给大家提供下思路，供大家参考。

先上图，下面是通过charles抓取得物小程序的图：

从蓝色标识的地方开始，向下的红箭头表示接口执行的顺序。

蓝色的地方表示收到了485状态的返回（图中下部的红框可以看到），然后调用了geetest的滑块验证功能，手工把滑块滑到正确的位置后，小程序向dewu的安全反爬接口发了2个请求，请求返回成功后又可以继续浏览相关界面。这就是这个验证码处理的过程，在上图中用黄色框分别标识了3个步骤。

 那么解题思路来了，在我们碰到接口返回485的时候，我们是不是处理好geetest的验证即可？对的，我验证过了。

执行的结果如下，second request的请求就返回了正常的数据。

 至于geetest如何实现处理，不在本文讨论之中，有兴趣的朋友自行在网上搜索下。

有兴趣的朋友可以搜微信公众号：阿嚏个技术，主要对自己的技术和产品做个记录。

​