记在卷首：

任何操作，在你上手之前，你永远不知道这次会发生什么样的问题，以及你永远都不会发现自己多么有解决问题的创造力。

                                                                                                        ——吉吉

没想到这次的主要问题是携程带来的：

1、抓出来的携程店铺对应的URL连接出错

情况说明：

一开始就很奇怪，不知道为什么后羿采集器始终无法抓那个店铺连接的列表。然后换了个什么爬山虎采集器，才把店铺连接都给抓到。不知道携程是不是用了某种反爬设计，不过有些收费的采集器都还是比较强大的可以解决这个问题。

但是，不知道为什么，采集出来的店铺列表的URL突然错了，一个澳门的店铺，URL可以对应到什么广州深圳北京南京。但奇怪的是，URL的内容是带有macau字样的，不一样的是后面的id数字。那么按理说，这种url应该对应到一个澳门的店铺，或者说店铺、网址不存在的页面上，而不是随便定义到全世界任意一个店铺上，所以这个URL设计的很奇怪，所以要不是设计者脑袋抽风，就是故意用来反爬虫的措施。而这一招很鸡贼，因为大家一般都是爬到就好了，或者随便点开几个检查看看，而不会都检查。若不是因为这次我要打tag所以要一个个点URL进去看下每个店都是干什么的，可能就不会发现这个问题，进而爬出的后一半的评论便都是错的了。

总结经验：

（1）爬出URL还是要点进去抽样检查下是不是对的。我觉得这样设计URL来反爬虫站在人类的发展的角度上来说是很缺德的了，因为它会影响到多少研究结果啊。。。

2、镜像网页识别出来的是两个完全不同的列表。并且只要编辑脚本便自动重新识别列表，控制不住。

情况说明：

在我爬取评论的时候，已经构建好了大概的采集框架，但是突然想加一个脚本进去。于是点击进脚本界面，修改脚本，再返回抓取界面的时候，发现采集器系统自动智能识别了，我之前列的采集框架没有了。且“按照热度排序”和“按照时间顺序排序”，两个网页的架构是大致一样的，但诡异的是在按时间顺序排序中我无法利用点击选择的方式识别之前识别的列表。

解决方案：

（1）采集器应该加个连接爬取界面的控制装备，即客户可以锁定爬取的Xpath。这个我在（2）（3）条会提到。

（2）关于网页一样，但识别出来的Xpath不一样的处理：

因为两个网页架构应该一样，所以可以手动设置Xpath。把镜像A（即有想要的那个Xpath的那个界面）的Xpath文本复制到镜像B（即无法自动取到想要的Xpath的那个界面）。

（3）关于爬虫连接和脚本命令相互影响的冲突的处理：

一般都是因为脚本命令改变→爬虫界面改变→爬虫Xpath自动重新设置（再次希望推出可以锁定Xpath，让它不要因为爬虫界面改变就自动重设的功能...）

所以解决方案也相应显现：在操作的时候，尽可能先设置脚本命令→再设置想要的Xpath。这样就不会因为脚本的变化而导致Xpath全付之一炬。

但是这种解决方案还是非常！不！人性化！因为正常人在编写采集方案的时候都无法保证自己能想到所有脚本！很有可能是在做着做着突然想到：诶，这儿再设置一个脚本会不会对输出和研究更有帮助？（比如我今天就是做着做着突然想到：如果用脚本把抓取结果按照时间顺序排列，会不会分析的时候就可以再把时间拿来比较一下？）那么这时候。。。总不能说：要么贯彻自己的想法，然后把之前堆好的采集方案牺牲掉；要么不贯彻这个想法，看看有没有别的方法来解决（比如我上述的那个问题：也可以通过关键词搜索“2018”、“2017”把数据归类来解决。）吧？复制Xpath来保存采集方案只能解决一部分问题，对于比如标题之类的设置，都没办法通过复制Xpath来保存。

3.由于一个永远存在的“下一页”导致陷入loop的问题： 

情况说明：

携程最后一页仍然有“下一页”的按钮，并且仍然可以“点击”（跳转到当前页面，也就是尾页），从而会（1）造成一直在点击，无法自动终止采集（2）对于一个任务多连接采集的情况，会一直停留在第一个连接的尾页，无法跳转到下面的链接采集。

解决方案：

因为我的目的是采集所有的评论，所以我采取的方案是把所有的店铺连接按照其有的评论数量打包成不同的链接包：比如因为一页有10条评论，我就把有1-10条评论的店铺的URL打包在一起采集，然后对于这些店铺设置无需翻页。然后再把有11-20条评论的店铺的URL再打包在一起采集，然后对于这些URL设置最大翻页数量为2页，因为2页足以采集到所有的评论。以此类推，因为评论数量越大，有这么大评论数量的店铺就越少。所以往后可以把有20-50条评论的店铺、有51-200条评论的店铺打包在一起，设置翻页5次，20次的限制......这样便解决掉因为携程翻页设置的特殊性导致的无限loop问题。但是，这样做。。。巨麻烦。。。希望有更好的解决方法。这次采集时间很长，也是因为用了这种处理，导致数据被分成了几十份抓取。

不过好处是提升了稳定性，分部抓取的好处就是一部分挂掉了只要用很短的时间修理这部分就行了，然后对于后羿这种稳定性。。。真的捕星的采集器（不过人家是免费的所以也不错了）来说，也避免了采集了20000条数据后突然挂掉，又要重新从第一条采集到20000条的风险。所以这种处理虽然麻烦，也算一种手动优化吧（手动滑稽。jpg），但是手动优化始终很麻烦，最好的解决方式就是采集器能把采集过程设计能够设计成分块处理：现在的采集器很多都是从1一个个采集到999999999的，如果其中一个出了错，999999999都要重新采集，实在是使用路上的一大问题！

总结经验：

（1）感受到一种内功心法：无限loop 与 determine+limit的对立关系。

（2）在抓取数量较大的数据的时候，可以有意识的采用分块抓取，不把鸡蛋放在同一个篮子里。不过手动分块抓取毕竟真的很麻烦，所以还是很希望有自动分块抓取。

接下来是一些乌龙和吐槽的记录：

1、上面说到，因为抓取出来的店铺URL连接是错误的，所以这意味着我需要重新抓取一次。但是这个时候很尴尬的是，之前用的那个爬墙虎还是什么的采集器一天只能免费采集1000条，而我之前已经采集了910多条，这意味着我需要等到第二天才能采集。于是。。。后面300多条都是一个个自己手工采集的。。。好处是（1）采集出来的连接绝对靠谱（2）不拖进度（3）可以顺带把每个店是干什么的看了，把标签打了。然后。。。不好的地方也不言而喻，很耗时耗力。（是“耗”，而不是“费”）

2、关于打tag这件事。本来是不准备打的，因为携程的连接里面就已经把澳门购物按照商品分成了七大类，所以本来的计划是打开这七大类，把店铺连接抽出来，然后爬取链接里的评论。像之前的列表一样。然而，当我打开这七大类，就震惊了：七大类里面，每一类，居然只有零零散散的几家店。甚至在葡萄酒那一大类中居然只有澳门的某一家来来超市。还不是所有来来超市，只是某一家。所以在此吐槽下携程对每个商户的商品的tag打的真的是捕星。所以后来只能自己给这900多家商户分类，一个个给其定位，打标签，然后按照不同种类抓取数据。（应该把这些打好的标签卖给携程，督促一下他们的打标签工作！（不过打标签这种事明明可以开源来做呀，让网友来打呀，为什么没有这个功能呢？（因为不是很重要？没有什么直接利益？而且如果让携程的员工打标签也是耗时耗力的一件事hhh。（最后写的这草是因为网吧上机时间要结束啦！不想再开一小时了！如果有没说完的回去想想，有机会再补充！