爬虫实战技巧-抓取源的选择

抓取源的选择对于抓取至关重要，直接关係着抓取的可行性与工作量。选择合理的抓取源不仅仅能够节约开发时间，避免很多坑，同时对数据的质量也有一定的保证。

我们要讨论的是：对于同一个数据来源，从哪个入口进行抓取，Web端，App端，Wap端？抑或是其他的一些途径。

这里的Wap是于Web形成对应并区分，指的是移动端Web，并不是狭义的WAP。

很多同志一说到抓取，就想到Web，HTML，然后各种Xpath，正则模板。这是比较複杂累人的方桉，实际上真正的抓取，还有很多其他的方式，这里我们就即将谈到，希望看完这篇文章对大家有所帮助。

总结与结论

选择哪个数据源抓取？

1. 哪个平台方便哪个
2. 哪个看起来複杂选择哪个

一般地，我们选择的优先级降序排列爲：

各平台内置入口 > Wap（手机浏览器） > 自家手机APP > 自家PC > Web

其中，PC端与手机APP无明显优先级区分，这个排列视抓取团队对平台Crack的熟悉程度而定。

怎麽理解上面说的两点呢？

这个不用举例子，就能很好的理解。我们从两个方面来分析：

1. 数据质量的好坏，不仅仅指数据内容的丰富，同时也包含对后期抽取工作的友好度
2. 后期踩坑的多少，就是所谓的反爬遭遇战，越少越好

第二个标题

抓取分类

可分的种类太多了，这里我们按照数据请求认证的方式简单的划分一下，以便内容后面的梳理。

1. 需要帐号和密码登录

   • 使用Cookie
   • 使用token

2. 只需使用第三方登录（有些是第三方只是绑定作用，仍然需要注册帐号，这个通与第一种类型）

   • 使用token
   • 无需token（不知道有没有这麽不靠谱的）

3. 无需登录

   • 使用token（请求的合法性校验，与帐号维度的token不一样）
   • 无需token

可以看到无需登录无需token的是最有可能大批量抓取数据，有反爬也最多只能在IP维度来做，这时候我们拼IP量就能搞定了。

需要帐号和密码登录的这种我们要儘量去避免，抛开注册和登录时的验证码不说，有帐号在对方后台的，你的每一次请求都能被记录下来，想封你很容易。

第二种，其实可以作爲最优选择，第一数据基本都是序列化过的，第二依附第三方（腾讯，新浪等）做认证的自身处理会相对薄弱。

来源详解

Web端

这个应该是大家最爲熟悉的，也是范围最广，最容易发现的抓取来源。基本输入网址后，我们就能找到想要的数据，这可能是数据规划或者产品提出来的，仍你一张图，然后上面圈出哪些数据需要被抓取到。

一般地，数据会通过两种方式从后台展示给用户：

1. 后台直接将数据内容渲染在HTML中
2. AJAX异步请求获得数据，在前端渲染

区别方式很简单，右键查看源码，或者在浏览器网址前面，键入:view-source:，在HTML源码中能找到你想要的数据的话那就是第一种方式，如果要抓，那直接拼上URL就完事。

第二种方式又可分为两种形式，第一种是返回的以JSON形式序列化好的数据；还有一种是比较坑的后台程序员写的（这个锅其实后台同学不背，主要是前端同学偷懒，想直接要HTML），返回的依然是HTML的片段。对于抓取而言，这两者的区别主要是在数据抽取的阶段，同时对遭遇反爬的判断，或者接口变动的发现都有着很明显的优势。

实际上，我们左右不了人后台数据的返回形式，但是我们可以当作参考，用来筛选对我们抓取工作最有利的途径。

这里无论数据是一次性直接从HTML中返回回来的，还是异步加载的，他们走的都是对方Web端对外接口，通常情况下，这里会有比较严格反爬策略，稍微异常就直接跳转给你验证码。

当然，异步返回数据的这种方式，有些会在这里做请求合法性的验证，你直接把数据请求从浏览器发出去，并不能得到真正的数据。

从某个角度来说，这其实是件好事情，因为一般在验证方面做足了工作的，大部分不太会在反爬上投入太多的精力，这也就是意味着，我们的抓取速度从某个角度来说，是能够得到保证。

顺便提下，不要看到异步加载的数据第一反应就是上headless浏览器这种去渲染出html然后又去抽内容。与其花个把小时去写脚本，还不如花些时间，研究研究他后台数据的接口，有没有数据请求的验证，是怎麽验证，然后用代码去实现，直接请求接口的数据。不但能大大提高抓取速度，同时还节省了一大堆资源，带宽、cpu、内存。想想你爲了请求一条几个字节的评论数，你非得多请求人家服务器几百Kb的数据下来，何必呢，伤人伤己。

当然有一种情况除外，对方的反爬系统使用静态资源的请求比例来分析是否是爬虫，那咱得上phantomjs之流，但也只限于需要帐号才能抓的数据，并且你的帐号数量还极其有限的情况才考虑去用。如果是这种情况，其实也没必要死磕在从Web端抓了。

Wap端

这个并不是所有你想抓的站点都会有的，像一些政府的基本没有，好在大部分的商业公司都有这条产品线，毕竟这是流量最高，入侵性最低的流量入口了；比如，新浪微博、雪球、喜马拉雅等等，他们都有自己手机Wap端产品。

那Wap端对比Web端优势在哪里呢？
答案是，结构化的数据接口的存在可能性更大！

由于移动端网络的特殊性，所以一般只要稍微靠谱点的产品，都会将Wap端涉及成异步加载数据的方式，儘量减小请求的大小，降低请求的发送频率，

在抓取前期，做抓取源的选择时，要区分到底有没有Wap端其实很简单，两种方式：

1. 手机浏览器直接打开
2. 浏览器调试工具，选择模拟移动设备

这个时候你看到的页面如果很“友好”，那基本上就可以说明他是独立与Web端的，存在数据接口的可能性会更大。当然，也有响应式的前端设计，就一套前端代码，基本这种肯定有单独的数据接口，和Web端一样。

上面提到了，这个的优点就是，可能具有结构化的数据接口，方便抓取与抽取工作。与此同时，从反反爬的角度来说，我据经验猜测IP的次数上线会稍高与Web端，这一点没有可靠的依据，毕竟在反爬引擎中，这隻是一个配置的事情，甚至是动态的无需人爲干预，做反爬的同志们可以斧正。

不管怎样，具有单独的数据接口，这一点已经足够支撑我们从这里着手抓取的工作。

手机端

按照主流平台，一般我们特指iOS与Android，我们不会像搞安全的同志们一样，都去研究，我们选择成本最低的方向来做，所以一般地，Android的APP是我们的首选。

毋庸置疑，99%的APP都是有单独的数据接口，其中对于我们想要的数据90%d的是通过HTTP方式进行传输，其馀的是TCP。TCP这个涉及协议分析这一块，耗时耗力，基本抓取不会考卢直接从请求中去拿数据，后面我会详细地介绍这种的数据应该怎麽去拿。

基本上，HTTP接口的数据，咱们抓个包就能知道接口是什麽样子，需要哪些验证参数。
一般情况下，不会直接一个光着的HTTP露在外面，请求里面会带着各种Key，Token什麽的，这些逻辑的处理都是在APP的代码里，所以咱们得花时间去逆向他的代码。

上面说的还是理想情况下，绝大多数的商业公司的产品，数据接口都走的是HTTPS，如果仅仅是如此那也不打紧，咱们该抓包抓包；但是哇，有那麽一波靠谱的系统设计在一些公司里，给这些接口套了双向验证，咱没法通过中间人的方式去抓包了，因爲证书不对，他不认，直接拒绝连接，这个时候我们必定只有一条逆向之路了。

上面罗嗦了半天，无非就是，APP端有接口好，封IP可能性较低，但是哇，耗时耗力，但是如果能一天够定各种验证，找到接口的请求方式那还是很划算的。

平台入口

最典型的微信里面的入口，很多公司的产品会使用微信登录，或者直接在公衆号里面提供入口。从一个角度来说，这等同于Wap端的产品，但是区别在于，很多产品是直接通过微信去登录验证的，直接可以避免注册登录的过程。微信小程序这个我目前还没有涉及到过，暂时不做讨论。

优点还是那两个，数据格式好，被封概率低；缺点也很明显，走大平台的验证逻辑，Crack起来很不好做，但是，大厂是靠谱，可是小公司可能会是猪队友，人腾讯明明给了那麽几进无懈可击的认证方桉，愣是在自己后台有涉及漏洞，那这个绝对是数据最优的选择。

比如，微信用于认证跳转的URL类似于https://open.weixin.qq.com/connect/oauth2/authorize?appid=wxe74839f******&redirect_uri=http://xx.xxx.com&response_type=code&scope=snsapi_base&state=456&connect_redirect=1#wechat_redirect，经过这个URL认证过的请求，就相当于登录过了。现在有不少公司的产品，从微信入口进去会获得比Web端更好的内容体验，这自然也会是抓取的福音，毕竟传统Web登录繁琐，反爬严格。

对比分析

这里用一个表格记录各项指标分数，以做对比：

PC客户端个人暂时还没有遇到真正的数据抓取，之前几款要麽是内嵌WebView的，要麽是直接读取临时文件就能搞定的，这里不纳入个人评价。

论述结束

这一篇算是囉哩囉唆半天，实际没有说到什麽很技巧的东西，后面会从这里谈到的内容，从实际例子出发去分析，怎麽做，如何做。

前言

根据前面所列的大纲，我们即将会讲到《数据抓包的方式与方法》。希望我继续写的请自行处理，不希望的请通过一些方式联繫我：

1. 微信: rustgolang
2. 微博[当作IM]: 我爱问财