有人说：2019 年可能是过去十年里最坏的一年，但可能是未来十年里最好的一年。 的确 2019 整个大环境确实比较差，很多人可能在 2020，这个新的一个十年的开端，许愿接下来的日子能慢慢好起来。但目前的状况，大家可能都看到了，新型冠状病毒的肆虐，让全国都变成了什么样子。在国内，新型冠状病毒相关的态势一直最近的头条，但可能大家并没有注意到，其实世界各地都似乎不怎么太平，如。而看看时间，2020 才过去了一个多月而已。
中国
不知道大家是不是和我一样，起床醒来的第一件事就是去查一查现在国内新型冠状病毒的确诊人数。 
截止今天（2 月 9 日）晚上 9 点，全国确诊病例达到 37289 例，疑似病例 28942 例，每天还以好几千的数量增加，估计明天早上能突破 4 万。 全国 31 个省区均早已经启动了一级响应，这在过去是从未有过的，随着病毒的传播蔓延，事态的严重性远远超出人们最大胆的想象。现在国家正在举全国之力支援灾区，前线的医疗人员一直在全力以赴救治患者。全国各个地区也在采取可以说是历史上最严格的防疫措施，全国范围内的商场、餐厅、娱乐场所几乎都被关停，各家各户的居民也都在家隔离，企业也延迟复工或者到现在还有很多企业都没有正式复工，口罩物资都已经全网脱销，一罩难求。但没有办法，在这个非常时刻，只要我们每个人都尽上自己的所能，相信疫情肯定会慢慢控制下来，请相信我们的国家。 观察了几天，从数据上来看，可能有这么两个好消息： 
- 一个是现在总的治愈人数已经超过死亡人数接近三倍，而且治愈人数的每日增长速度已经远超过死亡人数，比如今天的治愈人数就已经是死亡人数的大约 10 倍（891：90）。而且现在疫苗已经投入临床试验，相信接下来的治愈数据的增长液会越来越快。
- 新增的确诊和疑似人数出现缓和和下降迹象，至少从最近四天的数据上来看，能看出新增数量整体呈现下降的态势，今天刚刚也有新闻报道说全国除湖北外其他省份每日报告的确诊病例数从 2 月 3 日 890 例下降到 2 月 8 日的 509 例，下降幅度达到 42.8%，这表明各地联防联控机制以及严格管理等防控措施正在发挥作用。希望前几天数据最高的点，就是那个拐点吧。
加油武汉，加油中国！💪
美国
可能我们大多数人关注更多的是国内的新型冠状病毒。但现在，美国其实也不太平。美国正在遭受近 10 年来最严重的流感疫情。 看图，这是美国疾病控制与预防中心网站上的流感活动地图，现在是 2 月 9 日周日，数据的统计是每周一次更新，当前更新到 2 月 1 日，数据来源链接见文末。 
CDC 称，在其流感活动地图上，美国大部分地区为深红色，表明「流感样疾病」活动水平达到最高级。由于美国的流感季还要持续一段时间，因此这一数据可能会继续上升。从地区上看，目前全美 50 个州里，有 48 个州出现流感疫情，其中 32 个州流感活动水平维持高位，人口稠密的纽约、华盛顿和加州无一幸免，纷纷中招。此次流感季将是 10 年来美国最严重的流感季之一，2019 - 2020 流感季中，美国 1900 万人感染流感，至少 1 万人死亡，包括 68 名儿童。预计流感季将持续至 5 月，而 2 月是高峰期。 我有几个亲戚朋友现在就住在美国，因为流感的问题，每天他们也是和我们一样，待在家里不敢出门，同样体会出来了 ”隔离“ 的滋味。
澳洲
澳洲最近同样也不太平。 之前大家可能有听说澳洲大火的消息，其实关于澳洲大火的报道，去年 10 月份开始就有了，本来大家以为只是一场普通的森林火灾，扑灭就完事了。我看最近有报道澳洲大火的消息的时候，很多人在底下评论，大火一直在烧啊？没错，这大火一直烧，四个月了，烧的时候澳洲的卫星地图状况就是这个样子： 
这场火，不仅造成人命伤亡及经济损失，也对自然生态带来毁灭性破坏，使数亿动物遭遇灭顶之灾。已有近 5 亿只动物死于澳洲山火，并据相关报道显示考拉或将功能性灭绝。悉尼大学发布报告，全国约有 10 亿动物被大火波及，其中仅在澳大利亚袋鼠岛的大火中就有超 2 万只考拉死亡，考拉将被列为濒危动物。澳大利亚全境被烧毁的森林面积约 1120 万 公顷，而去年震惊世界的亚马孙雨林大火烧毁森林面积才约 180 万公顷。此外，有 1400 多公里的海岸线都在燃烧，相当从东北烧到了江浙沪。 慢慢地，前几天，山火逐渐逼近了堪培拉。1 月 31 日，因为山火的步步紧逼，澳大利亚政府宣布堪培拉进入紧急状态，这是自 2003 年山火危机之后 17 年以来，堪培拉首次进入紧急状态。2 月 2 日整天，堪培拉均处于高度戒备状态。堪培拉和周边地区的气温一度超过 42 摄氏度。 当时堪培拉就是这么一个状态： 
其他的地区山火基本是这么一个状态： 
以及那些被烧死的无辜的动物们： 
澳大利亚的这场大火也对全球造成了影响。欧洲哥白尼大气监测服务发表数据：澳大利亚已经向大气排放约 4 亿吨二氧化碳，这个数据比全球 116 个二氧化碳排放量最低国家年排放量总和还要高。 不过，就在最近几天，现在澳洲的山火由于一场暴雨的到来，很多地区的火已经灭了。但，这还没完，由于雨过大，洪水又来了。 据《每日邮报》2 月 9 日报道，近日，澳大利亚遭遇了十年来最大降雨，东海岸被大规模破坏，悉尼正在全力应对洪水爆发，火车站都变成了游泳池。澳大利亚气象局预计，在新南威尔士州北部的一些气象站在 48 小时内录得超过 300 毫米的降雨后，降雨将持续到周日。 据报道，周六，在新南威尔士州北部，67 岁的吉尔·萨瑟兰和她 30 岁的侄女汉娜驱车前往位于新南威尔士州北部河流地区的宁宾，途中他们穿过了一条被洪水淹没的道路。然而，他们很快就失去了对汽车的控制，车子灌满了水，沉了下去，完全从视线中消失了。 
但好在，大火已经基本停了，但愿这次洪水也能尽快过去，祝好！
巴西
当地时间 1 月 26 日，巴西东南部因受强风暴雨影响，正在遭遇百年不遇的泥石流灾害。 暴雨接连两日肆虐米纳斯吉拉斯州，导致多处房屋倒塌，道路摧毁，很多生命瞬间流逝。到目前为主，此次灾情至少已造成 46 人死亡，超过 25000 人流离失所。巴西国家气象研究所表示，这是自 110 年前开始有纪录以来，本地区降下的最猛烈暴雨。 
军队现已对山区的村镇与交通设施展开全力救助，巴西政府也声称将努力建立一个全国性的灾害预防和早期预警系统。
波兰、丹麦
1 月 23 日，波兰海关总署发布消息。1 月 7 日，波兰官方向世界动物卫生组织通报，2019 年 12 月 31 日至 2020 年 1 月 4 日，该国卢布林省和大波兰省发生 8 起 H5N8 亚型高致病性禽流感。波兰是欧洲最大的家禽生产国，自 2017 年以来从未爆发过禽流感。 1 月 30 日，丹麦环境和食品部向 OIE 紧急报告称，丹麦发生一起 H5N1 型低致病性禽流感疫情。本次疫情于 1 月 29 日得到确认，此次疫情可能导致多达 4 万只禽类被宰杀，方圆 3 公里多达 35 万只家禽受到威胁。 
法国、西班牙
1 月 21 日，西班牙东北部地区遭强暴风和大雪袭击，供电中断，几十万人无电可用，暴风和大雪至少已造成 4 人死亡。阿联酋《宣言报》22 日报道称，由于暴风和降大雪，能见度很低，气温急速下降，达到结冰的程度，地中海沿岸海浪急剧上升。 西班牙紧急部门的报告表示，虽然与法国之间的供给线得到了修复，但因为积雪覆盖了 2600 多公里的道路，交通受阻，供电难以解决，位于东北部的吉罗纳省 22 万居民仍然没有电可用。 
土耳其
土耳其内政部 1 月 25 日消息称，24 日晚发生在该国东部埃拉泽省的 6.8 级地震已经造成 22 人死亡，超过 1000 人受伤。 据土耳其阿纳多卢通讯社报道，土耳其内政部部长索伊卢 25 日在新闻发布会上表示，埃拉泽省在地震中的死亡人数为 18 人，其邻省马拉提亚省死亡人数为 4 人。政府派出的救援队已从倒塌的房屋和建筑物的废墟中救出 39 人。 
利比亚
根据俄罗斯卫星通讯社开罗 1 月 14 日的报道，利比亚冲突各方停火问题谈判 13 日在莫斯科举行，俄土两国代表参加了谈判。 然而利比亚战火和谈失败，双方陷入了僵局。土耳其出兵面临全面内战永久分裂风险。 
苏丹
1 月 14 日下午，苏丹发生政变，安全部门和军方在首都喀土穆机场附近发生激烈对峙，并伴有阵阵枪声。 
军方戒严了城区主要街道，喀土穆国际机场已关闭。中国驻苏丹使馆发出安全警告，提醒中国公民不要靠近机场区域。
也门
1 月 19 日，也门西部一个军事训练营遭遇袭击，造成数十名也门政府军士兵死亡，至少 100 人受伤，胡塞武装在马里布市发动了大规模伤亡袭击，命令也门军队必须保持高度戒备，做好战斗准备。 
印尼
印尼国家抗灾署 6 号通报，首都雅加达和周边地区日前遭遇的洪灾，已造成 67 人死亡。 
印尼国家抗灾署发言人阿古斯在一份声明中说，截至当地时间 6 日下午，灾害还造成 1 人失踪，另有 3.6 万人居住在临时避难所。由于强降雨引发洪灾、山体滑坡等灾害，雅加达周边的 12 个县市已陆续宣布进入为期一到两周的紧急状态，以便救援和物资运输工作展开。
东非
东非近期爆发蝗灾，这被称为 70 年来最严重的沙漠蝗灾，其中肯尼亚受灾最为严重，数亿只蝗虫在肯尼亚境内肆虐。 据联合国估计此次蝗虫数量达 3600 亿只，且数量可能在数月后暴增 500 倍。非常令人惊恐的是沙漠蝗群一天内可以吃掉能养活 2500 人的粮食，这也令当地出现了严重的粮食危机。蝗群密度一般达到每平方公里 1.5 亿只，蝗群一天可以随风飞行 100 至 150 公里，破坏范围及力量惊人。 
联合国粮食及农业组织已经发出警告，蝗灾将会造成近年来罕见的粮食危机，1900 万人将面临危及生命的饥荒。 这个确实非常严重的，一些更详细的报道大家可以了解澎湃新闻报道的视频：https://www.thepaper.cn/newsDetail_forward_5758503，真的难以想象。
总结
总的来说，全世界的 2020 开局的确可以说是不怎么太平。仔细想想，这些现象的发生有天灾，有人祸。除了一些政治上的问题，这些灾难其实来源于人们对大自然的过渡攫取，或者说是对野生动物的滥杀和捕食。 多难兴邦，天灾无情人有情。在大自然的面前，我们显得非常渺小，在灾难的面前，我们都是受害者。这时候就需要我们团结一心，站在一个战线上去把这些困难渡过去，而不是在这个节骨眼上发国难财，造谣传谣。像我们之前非典、汶川地震一样，众志成城，再难我们也能挺过去的。 相信我们的国家，相信世界的人们。 加油武汉，加油中国，加油全世界！
参考来源
- 本文选题和主要参考来源：2020 年只过去了一个月，全世界正在发生什么？https://mp.weixin.qq.com/s/V1iioQsuYITpFfRijZkQHw
- 卫健委：全国除湖北外其他省份确诊病例下降超 40% http://news.sina.com.cn/c/2020-02-09/doc-iimxxstf0048640.shtml
- 美国 4 个月近 2000 万人感染流感 今年或是 10 年来最严重 https://www.codingsky.com/news/2020-02-08/11567.html
- Weekly U.S. Influenza Surveillance Report https://www.cdc.gov/flu/weekly/index.htm#ILIActivityMap
- 澳洲遭十年最大暴雨，悉尼全力应对洪水爆发 https://new.qq.com/rain/a/20200209A06URA
- 巴西遭创纪录暴雨肆虐 泥石流冲毁房屋 http://www.chinanews.com/m/tp/hd/2020/0126/134972.shtml
- 也门政府军遭胡塞武装导弹袭击至少 40 人死亡 http://www.xinhuanet.com/mil/2020-01/19/c_1210444134.htm
- 苏丹安全部门和军方在喀土穆机场附近激烈对峙 https://news.sina.cn/gj/2020-01-15/detail-iihnzhha2484546.d.html
- 67 人死亡 1 人失踪 印尼洪水灾情严重 http://news.cri.cn/20200107/235b849d-523f-b512-c6d4-4feacd8347f4.html
- 东非遭 70 年来最严重蝗灾，情况或将恶化 https://www.thepaper.cn/newsDetail_forward_5758503
登录完成之后就可以看到 Splash 的界面了，如图所示。 
以上，便是 Kubernetes 搭建 Splash 的方法。 希望对大家有帮助。
图 6-4 示例 5 页面 在编写 Python 代码之前，我们需要确定目标数据的元素定位。航空公司名称元素定位如图 6-5 所示。 
图 6-5 航空公司名称元素定位结果 航空公司名称包裹在没有属性的 span 标签中，但该 span 标签包裹在 class 属性为 air g-tips 的 div 标签中。接下来我们看一下航站名称的元素定位，定位结果如图 6-6 所示。 
图 6-6 航站名称元素定位结果 航站名称包裹在没有属性的 h2 标签中，h2 标签包裹在 class 为 sep-lf 的 div 标签中。 我们再看一下票价的元素定位，定位结果如图 6-7 所示。 
图 6-7 票价的元素定位结果 页面中显示的票价为 467，但是在网页中却有两组不同的数字，其中一组是[7, 7, 7]，而另一组是 [6, 4]，这看起来就有点奇怪了。 难道是网页显示有问题？ 按照正常排序来说，这架航班的票价应该是 77 764 才对。我们可以查看第二架航班信息的价格，思考是网页显示问题还是做了什么反爬虫措施。第二架航班的票价元素定位结果如图 6-8 所示。 
图 6-8 第二架航班的票价元素定位结果 结果与第一架航班的票价显示有同样的问题：网页显示内容和 HTML 代码中的内容不一致。我们分析一下 HTML 代码，看一看是否能找到什么线索。第一架航班票价的 HTML 代码为：
图 6-9 数字组合推测 5 个数字的组合结果太多了，我们必须找出其中的规律，这样就能知道网页为什么显示 467 而不是 764 或者 776 。在仔细查看过后，发现每个带有数字的标签都设定了样式。第 1 对 b 标签的样式为：
图 6-10 span 标签对和 i 标签对位置图 此时网页中显示的价格应该是 777，但是由于第 2 和第 3 对 b 标签中有值，所以我们还需要计算它们的位置。此时标签位置的变化如图 6-11 所示。 
图 6-11 标签位置变化 右侧是标签位置变化后的结果，由于第 2 对 b 标签的位置样式是 left:-32px，所以第 2 对 b 标签中的值 6 就会覆盖原来第 1 对 b 标签中的中的第 2 个数字 7，此时页面应该显示的数字是 767。 按此规律推算，第 3 对 b 标签的位置样式是 left:-48px，这个标签的值会覆盖第 1 对 b 标签中的第 1 个数字 7，覆盖结果如图 6-12 所示，最后显示的票价是 467。 
图 6-12 覆盖结果 根据结果来看这种算法是合理的，不过我们还需要对其进行验证，现在将第二架航班的 HTML 值 和 CSS 样式按照这个规律进行推算。最后推算得到的结果与页面显示结果相同，说明这个位置偏移的计算方法是正确的，这样我们就可以编写 Python 代码获取网页中的票价信息了。因为 b 标签包裹在 class 属性为 rel 的 em 标签下，所以我们要定位所有的 em 标签。对应的 Python 代码如下：
图 6-13 去哪儿网航班信息 航班票价对应的 HTML 代码如图 6-14 所示。 
图 6-14 去哪儿网航班票价 HTML 代码 去哪儿网航班票价所对应的 HTML 代码结构和 CSS 与我们在示例 5 中见到的类似。我们可以大胆猜测，去哪儿网航班票价的显示规律与示例 5 中所用的方法也是类似的，感兴趣的同学可以按照 6.2.1 节的思路进行票价推算。去哪儿网航班票价中第 1 对 b 标签下的 i 标签数量与 width 是相匹配的，并未出现显示错误的问题。
想要与作者韦世东交流或者参加新书发布活动的朋友可以扫描二维码进群与我互动哦！
图 6-15 示例 6 页面 在编写 Python 代码之前，我们需要确定目标数据的元素定位。在定位过程中，发现一个与以往不同的现象：有些数字在 HTML 代码中并不存在。例如口味的评分数据，其元素定位如图 6-16 所示。 
图 6-16 评分数据中口味分数元素定位 根据页面显示内容，HTML 代码中应该是 8.7 才对，但实际上我们看到的却是：
图 6-17 class 属性值和数字的对比 从图 6-17 中可以看出，class 属性值和数字是一一对应的，如属性值 vhk08k 与数字 0 对应。根据这个线索，我们可以猜测每个数字都与一个属性值对应，对应关系如图 6-18 所示。 
图 6-18 数字与属性值对应关系 浏览器在渲染页面的时候就会按照这个对应关系进行映射，所以页面中显示的是数字，而我们在 HTML 代码中看到的则是这些 class 属性值。浏览器在渲染时将 HTML 中的 d 标签与数字按照此关系进行映射，并将映射结果呈现在页面中。映射逻辑如图 6-19 所示。 
图 6-19 映射逻辑 我们的爬虫代码可以按照同样的逻辑实现映射功能，在解析 HTML 代码时将 d 标签的 class 属性值取出来，然后进行映射即可得到页面中显示的数字。如何在爬虫代码中实现映射关系呢？实际上网页中使用的是“属性名数字”这种结构，Python 中内置的字典正好可以满足我们的需求。我们可以用 Python 代码测试一下，代码如下：
图 6-20 大众点评商家信息页 大众点评的商家信息页主要用于展示消费者对商家的各项评分、商家电话、店铺地址和推荐菜品等。我们可以看一看商家电话或评分的 HTML 代码，如图 6-21 所示。 
图 6-21 商家电话 HTML 代码 大众点评中的商家号码并不是全部使用 d 标签代替，其中有部分使用了数字。但是仔细观察一下就可以发现商家号码的数量等于 d 标签数量加上数字的数量，说明 d 标签的 class 属性值与数字也有可能是一一对应的映射关系。感兴趣的同学可以使用示例 6 中的方法，尝试映射大众点评案例中的数字。 如果这种手段的绕过方法这么简单的话，那么它早就被淘汰了，为什么连大众点评这样的大型网站都会使用呢？我们继续往下看，大众点评的商家营业时间部分的 HTML 代码如图 6-22 所示。 
图 6-22 大众点评商家营业时间 除了刚才的数字映射之外，大众点评还对中文进行了映射。此时如果按照示例 6 中人为地将 class 值和对应的文字进行映射的话，就非常麻烦了。试想一下，如果网页中所有的文字都使用这种映射反爬虫的手段，那么爬虫工程师要如何应对呢？对所有用到的文字进行映射吗？ 这不可能做到，其中要完成映射的包括 10 个数字、26 个英文字母和几千个常用汉字。而且目标网站一旦更改文字的对应关系，那么爬虫工程师就需要重新映射所有文字。面对这样的问题，我们必须找到文字映射规律，并且能够使用 Python 语言实现映射算法。如此一来，无论目标网站文字映射的对应关系如何变化，我们都能够使用这套映射算法得到正确的结果。 这种映射关系在网页中是如何实现的呢？是使用 JavaScript 在页面中定义数组吗？还是异步请求API 拿到 JSON 数据？这都有可能，接下来我们就去寻找答案。
图 6-23 标签背景图 d 标签的背景图中全部都是数字，这些无序的数字共有 4 行。但这好像不是一张大图片，我们查看该图片页面的源代码，内容如图 6-24 所示。 
图 6-24 图片页面源代码 源代码中前两行表明这是一个 SVG 文件，该文件中使用 text 标签定义文本， style 标签用于设置文本样式， text 标签定义的文本正是图片页面显示的数字。难道这些无序的数字就是我们在页面中看到的电话号码和评分数字？ 除了 class 属性值为 vhkbvu 的 d 标签，其他标签也使用了这个的 CSS 样式，但每对 d 标签的坐标定位都不同。它们的坐标定位如下：
图 6-25 test.svg 显示内容 代码前 3 行声明文件类型，第 4 行~第 5 行定义了 SVG 内容块和画布宽高，第 6 行使用 text 标签定义了一段文本并指定了文本的坐标。这段文本就是我们在浏览器中看到的内容，而代码中的 x 坐标和 y 坐标则用于确定该文本在画布中的位置，坐标规则如下。
图 6-26 x 为 0 时的 test.svg 显示内容 x 的值为 0 时，文本紧贴浏览器左侧。而 x 的值为 10 时，文本距离浏览器左侧有一定的距离，这说明 x 的值能够决定文字所在的位置。现在我们将代码中 x 对应的值改为“10 50 30 40 20 60”（注意这里特意将第 2个数字 20与第 5个数字互换了位置），这样做是为了设定前 6个字符的坐标位置。 此时，第 1 个字符的位置参数为 10，第 2 个字符的位置参数为 50，第 3 个字符的位置参数为 30，以此类推，页面中正常显示的文字顺序应该是：
图 6-27 设定多个 x 值的 svg 图 6-27 中文字顺序与我们猜测的顺序是一样的，这说明 SVG 中每个字符都可以有自己的 x 轴坐标值。y 与 x 同理，每个字符都可以有自己的 y 轴坐标值。虽然我们只设定了 6 个位置参数， svg 中的字符却有 11 个，但没有设定位置参数的字符依然能够按照原文顺序排序。在了解 SVG 基本知识之后，我们回头看一下案例中所使用的 SVG 文件中坐标参数的设定，图 6-23 中的字符与图 6-24 图片页源代码中的字符一一对应，且每个字符都设定了 x 轴的位置参数，而 y 轴则只有 1 个值。 在了解位置参数之后，我们还需要弄清楚字符定位的问题。浏览器根据 CSS 样式中设定的坐标和元素宽高来确定 SVG 中对应数字。x 轴的正方向为从左到右，y 轴的正方向是从上到下，如图 6-28 所示。 
图 6-28 SVG x 轴和 y 轴与位置参数的关系 而 CSS 样式中的 x 轴与 y 轴是相反的，也就是说 CSS 样式中 x 轴是负数向右的，y 轴是负数向下的，如图 6-29 所示。 
图 6-29 CSS x 轴和 y 轴与位置参数的关系 所以当我们需要在 CSS 中定位 SVG 中的字符位置时，需要用负数表示。我们可以通过一个例子来理解它们的关系，现在需要在 CSS 中定位图 6-30 中第 1 行的第 1 个字符的中心点。 
图 6-30 SVG 假设字符大小为 14 px，那么 SVG 的计算规则如下。
图 6-31 映射结果 然后再利用切片特性拿到字符。对应代码如下：
这时候，只要我们点击最前面的复选框，验证码算法会首先利用其「风险分析引擎」做一次安全检测，如果直接检验通过的话，我们会直接得到如下的结果： 
如果算法检测到当前系统存在风险，比如可能是陌生的网络环境，可能是模拟程序，会需要做二次校验。它会进一步弹出类似如下的内容： 
比如上面这张图，验证码页面会出现九张图片，同时最上方出现文字「树木」，我们需要点选下方九张图中出现「树木」的图片，点选完成之后，可能还会出现几张新的图片，我们需要再次完成点选，最后点击「验证」按钮即可完成验证。 或者我们可以点击下方的「耳机」图标，这时候会切换到听写模式，验证码会变成这样： 
这时候我们如果能填写对验证码读的音频内容，同样可以通过验证。 这两种方式都可以通过验证，验证完成之后，我们才能完成表单的提交，比如完成登录、注册等操作。 这种验证码叫什么名字？ 这个验证码就是 Google 的 reCAPTCHA V2 验证码，它就属于行为验证码的一种，这些行为包括点选复选框、选择对应图片、语音听写等内容，只有将这些行为校验通过，此验证码才能通过验证。相比于一般的图形验证码来说，此种验证码交互体验更好、安全性会更高、破解难度更大。 许多国外的网站都采用了此种验证码，由于某些原因，在国内其实无法直接使用，但只需要将验证码的域名更换为 recaptcha.net 同样是可以使用的，所以有时候我们在国内某些站点同样能看到它的身影。 其实上文所介绍的验证码仅仅是 reCAPTCHA 验证码的一种形式，是 V2 的显式版本，另外其 V2 版本还有隐式版本，隐式版本在校验的时候不会再显式地出现验证页面，它是通过 JavaScript 将验证码和提交按钮进行绑定，在提交表单的时候会自动完成校验。除了 V2 版本，Google 又推出了最新的 V3 版本，reCAPTCHA V3 验证码会为根据用户的行为来计算一个分数，这个分数代表了用户可能为机器人的概率，最后通过概率来判断校验是否可以通过。其安全性更高、体验更好。 具体的内容大家可以参考 reCAPTCHA 的官方介绍：
破解验证码背后有图像识别算法和大量人力的支撑，如果我们仅仅是简单的图形验证码，其可以通过一些图像识别算法将内容识别出来转化为文本内容。如果是较为复杂的图形验证码或者像 reCAPTCHA 类似的行为验证码，其背后会有人来对验证码进行模拟，然后返回其验证成功后的秘钥，我们利用其结果便可以完成一些验证码的绕过。 当然这种网站肯定是要收费的，按照 1000 次识别为单位，其花费的费用为 0.5 美刀到 2.99 美刀不等，比如非常简单的图形验证码可能就是 0.5 美刀，这种验证码对于其人力和算力资源消耗都是相对较小的，对于复杂的 reCAPTCHA 验证码，就要花 2.99 美刀了，因为识别这么一个验证码并不容易，其背后的人可能需要看好多图，点选好多次才能完成一次成功的验证。 目前我用的服务的收费标准是这样的： 
具体的内容或者更新大家可以到其官方说明 
在这里我们可以看到账户余额、API KEY、FAQ 等配置。 这里最重要的就是 API KEY 了，它是我们用来使用 2Captcha 的凭证，我们将它复制下来，后面我们会在代码中使用它。 
好，准备工作完成了，我们接下来进入正式内容。
在这里可以看到有一个表单，上面有一些输入框，下方是 reCAPTCHA V2 验证码。 要识别这个验证码，第一步便是找到这个验证码 sitekey，这个是验证码的唯一标识。 我们打开浏览器的开发者工具，查看其页面源码，首先找到 reCAPTCHA 的源代码，如下图所示： 
可以看到 reCAPTCHA 是对应了一个 iframe，我们看到的 reCAPTCHA 内容都是在 iframe 里面呈现出来的。 这里我们可以观察到在 reCAPTCHA 的源码的最外层的 div 上面有一个字段，叫做 data-sitekey，这就是刚才我们所说的 sitekey，它是验证码的唯一标识，比如这里我先将这个 sitekey 保存下来，这里其值为：
所以，2Captcha 相当于为我们模拟了点选验证码的过程，其最终得到的这个 token 其实就是我们应该赋值给 name 为 g-recaptcha-response 的内容。 那么怎么赋值呢？ 很简单，用 JavaScript 就好了。我们可以用 JavaScript 选取到这个 textarea，然后直接赋值即可，代码如下：
可以看到其就是提交了一个表单，其中有一个字段就是 g-recaptcha-response，它会发送到服务端进行校验，校验通过，那就成功了。 所以，如果我们借助于 2Captcha 得到了这个 token，然后把它赋值到表单的 textarea 里面，表单就会提交，如果 token 有效，就能成功绕过登录，而不需要我们再去点选验证码了。 最后我们得到如下成功的页面： 
至此，我们就成功地借助 2Captcha 来完成了 reCAPTCHA V2 验证码的识别。
图 6-32 示例 7 页面 在编写代码之前，我们需要确定目标数据的元素定位。定位时，我们在 HTML 中发现了一些奇怪的符号，HTML 代码如下：
图 6-33 字符与数字的映射关系 字符与数字是一一对应的，我们只需要多找一些页面，将 0 ~ 9 数字对应的字符凑齐即可。但如果目标网站的字体是动态变化的呢？映射关系也是变化的呢？ 根据 6.3 节的学习和分析，我们知道人为映射并不能解决这些问题，必须找到映射关系的规律，并使用 Python 代码实现映射算法才行。继续往下分析，难道字符映射是先异步加载数据再使用 JavaScript 渲染的？ 
图 6-34 请求记录 网络请求记录如图 6-34 所示，请求记录中并没有发现异步请求，这个猜测并没有得到证实。CSS 样式方面有没有线索呢？页面中包裹符号的标签的 class 属性值都是 stonefont：
图 6-35 百度字体编辑器界面 打开页面后，将 movie.woff 文件拖曳到百度字体编辑器的灰色区域即可，字体文件内容如图 6-36 所示。 
图 6-36 字体文件 movie.woff 预览 该字体文件中共有 12 个字体块，其中包括 2 个空白字体块和 0 ~ 9 的数字字体块。我们可以大胆地猜测，评分数据和票房数据中使用的数字正是从此而来。 由此看来，我们还需要了解一些字体文件格式相关的知识，在了解文件格式和规律后，才能够找到更合理的解决办法。
图 6-37 字形与点的关系 字体文件中不仅包含字形数据和点信息，还包括字符到字形映射、字体标题、命名和水平指标等，这些信息存在对应的表中，所以我们也可以认为 TrueType 字体文件由一系列的表组成，其中常用的表 及其作用如图 6-38 所示。 
图 6-38 构成字体文件的常用表及其作用 如何查看这些表的结构和所包含的信息呢？我们可以借助第三方 Python 库 fonttools 将 WOFF 等字体文件转换成 XML 文件，这样就能查看字体文件的结构和表信息了。首先我们要安装 fonttools 库， 安装命令为：
图 6-39 字符到字形映射关系示例 XML 中的字符 0xe339 与网页源代码中的字符 对应，这样我们就确定了 HTML 中的字符码与 movie.woff 字体文件中对应的字形关系。字形数据存储在 glyf 表中，每个字形的数据都是独立的，例如字形 uniE339 的字形数据如下：
图 6-40 字形 uniE339 的轮廓 我们可以在百度字体编辑器中调整点的位置，然后保存字体文件并将新字体文件转换为 XML 格式，相同名称的字形数据如下：
图 6-41 字形数据对比 XML 文件中记录的是字形坐标信息，实际上，我们没有办法直接通过字形数据获得文字，只能从其他方面想办法。虽然目标网站使用多套字体，但相同文字的字形也是相同的。比如现在有 movie.woff 和 food.woff 这两套字体，它们包含的字形如下：
图 6-42 描述相同文字的两个字形 点坐标的数量和坐标值可以作为比较条件吗？ 如图 6-43 所示，两个不同文字的字形数据是不一样的。虽然这两种字形的 name 都是 uniE9C7，但是字形数据中大部分 pt 标签 x 和 y 的差距都很大，所以我们可以判定这两个字形描述的并不是 同一个文字。你可能会想到点的数量也可以作为排除条件，也就是说如果点的数量不相同，那么这个 两个字形描述的就不是同一个文字。真的是这样吗？ 
图 6-43 描述不同文字的字形数据对比 在图 6-44 中，左侧描述文字 7 的字形有 17 个点，而右侧描述文字 7 的字形却有 20 个点。对应的字形信息如图 6-45 所示。 
图 6-44 描述相同文字的字形 
图 6-45 描述相同文字的字形信息 虽然点的数量不一样，但是它们的字形并没有太大的变化，也不会造成用户误读，所以点的数量并不能作为排除不同字形的条件。因此，只有起止坐标和点坐标数据完全相同的字形，描述的才是相同字符。
界面类似显示如下图所示。 
在这里显示了我们已经有的一些 Tampermonkey 脚本，包括我们自行创建的，也包括从第三方网站下载安装的。 另外这里也提供了编辑、调试、删除等管理功能，我们可以方便地对脚本进行管理。 接下来我们来创建一个新的脚本来试试，点击左侧的「+」号，会显示如图所示的页面。 
初始化的代码如下：
我们随便输入用户名密码，点击登录按钮，观察一下网络请求的变化。 可以看到如下结果： 
看到实际上控制台提交了一个 POST 请求，内容为：
这么多混淆代码，总不能一点点扒着看吧？这得找到猴年马月？那么遇到这种情形，这怎么去找 token 的生成位置呢？ 解决方法其实有两种。
这时候如果我们再次点击登录按钮的时候，正好发起一次 Ajax 请求，就进入到断点了，然后再看堆栈信息就可以一步步找到编码的入口了。 点击 Submit 之后，页面就进入了 Debug 状态停下来了，结果如下： 
一步步找，我们最后其实可以找到入口其实是在 onSubmit 方法这里。但实际上，我们观察到，这里的断点的栈顶还会包括了一些 async Promise 等无关的内容，而我们真正想找的是用户名和密码经过处理，再进行 Base64 编码的地方，这些请求的调用实际上和我们找寻的入口是没有很大的关系的。 另外，如果我们想找的入口位置并不伴随这一次 Ajax 请求，这个方法就没法用了。 这个方法是奏效的，但是我们先不讲 onSubmit 方法里面究竟是什么逻辑，下一个方法再来讲。
接下来，打开控制台，切换到 Sources 面板，这时候我们可以看到站点下面的资源多了一个叫做 Tampermonkey 的目录，展开之后，发现就是我们刚刚自定义的脚本。 
然后输入用户名、密码，点击提交。发现成功进入了断点模式停下来了，代码就卡在了我们自定义的 
成功 Hook 住了，这说明 JavaScript 代码在执行过程中调用到了 btoa 方法。 看下控制台，如下图所示。 
这里也输出了 window 对象和 btoa 方法，验证正确。 这样，我们就顺利找到了 Base64 编码操作这个路口，然后看看堆栈信息，也已经不会出现 async、Promise 这样的调用，很清晰地呈现了 btoa 方法逐层调用的过程，非常清晰明了了，如图所示。 
各个底层的 encode 方法略过，这样我们也非常顺利地找到了 onSubmit 方法里面的处理逻辑：
所以，现在我们知道了 token 和用户名、密码是什么关系了吧。 这里一目了然了，就是对表单进行了 JSON 序列化，然后调用了 encode 也就是 btoa 方法，并赋值为了 token，入口顺利解开。后面，我们只需要模拟这个过程就 OK 了。 所以，我们通过 Tampermonkey 自定义 JavaScript 脚本的方式实现了某个方法调用的 Hook，使得我们快速能定位到加密入口的位置，非常方便。 以后如果观察出来了一些门道，可以多使用这种方法来尝试，如 Hook encode 方法、decode 方法、stringify 方法、log 方法、alert 方法等等，简单而又高效。 以上便是通过 Tampermonkey 实现简单 Hook 的基础操作，当然这个仅仅是一个常见的基础案例，不过从中我们也可以总结出一些 Hook 的基本门道。 后面我们会继续介绍更多相关内容。
图 15-6 主机列表 另外刚才我们提到在 gerapy 目录下有一个空的 projects 文件夹，这就是存放 Scrapy 目录的文件夹，如果我们想要部署某个 Scrapy 项目，只需要将该项目文件放到 projects 文件夹下即可。 比如这里我放了两个 Scrapy 项目，如图 15-7 所示： 
图 15-7 项目目录 这时重新回到 Gerapy 管理界面，点击项目管理，即可看到当前项目列表，如图 15-8 所示： 
图 15-8 项目列表 由于此处我有过打包和部署记录，在这里分别予以显示。 Gerapy 提供了项目在线编辑功能，我们可以点击编辑即可可视化地对项目进行编辑，如图 15-9 所示： 
图 15-9 可视化编辑 如果项目没有问题，可以点击部署进行打包和部署，部署之前需要打包项目，打包时可以指定版本描述，如图 15-10 所示： 
图 15-10 项目打包 打包完成之后可以直接点击部署按钮即可将打包好的 Scrapy 项目部署到对应的云主机上，同时也可以批量部署，如图 15-11 所示： 
图 15-11 部署页面 部署完毕之后就可以回到主机管理页面进行任务调度了，点击调度即可查看进入任务管理页面，可以当前主机所有任务的运行状态，如图 15-12 所示： 
图 15-12 任务运行状态 我们可以通过点击新任务、停止等按钮来实现任务的启动和停止等操作，同时也可以通过展开任务条目查看日志详情，如图 15-13 所示： 
图 15-13 查看日志 这样我们就可以实时查看到各个任务运行状态了。 以上便是 Gerapy 的一些功能的简单介绍，使用它我们可以更加方便地管理、部署和监控 Scrapy 项目，尤其是对分布式爬虫来说。 更多的信息可以查看 Gerapy 的 GitHub 地址：
图 15-3 制作镜像 然后输入镜像的一些配置信息，如图 15-4 所示。 
图 15-4 镜像配置 最后确认制作镜像即可，稍等片刻即可制作成功。 接下来我们可以创建新的主机，在新建主机时选择已经制作好的镜像即可，如图 15-5 所示。 
图 15-5 新建主机 后续配置过程按照提示进行即可。 配置完成之后登录新到云主机，即可看到当前主机 Docker 和 Scrapyd 镜像都已经安装好，Scrapyd 服务已经正常运行。 我们就通过自定义镜像的方式实现了相同环境的云主机的批量部署。
图 15-2 Scrapyd 主页 这样我们就完成了 Scrapyd Docker 镜像的构建并成功运行了。 然后我们可以将此镜像上传到 Docker Hub，例如我的 Docker Hub 用户名为 germey，新建了一个名为 scrapyd 的项目，首先可以打一个标签：
图 15-1 Scrapyd 首页 如果可以成功访问到此页面，那么证明 Scrapyd 配置就没有问题了。
图 14-7 初始位数组 现在我们有了一个待检测集合，我们表示为 S={x1, x2, …, xn}，我们接下来需要做的就是检测一个 x 是否已经存在于集合 S 中。在 BloomFilter 算法中首先使用 k 个相互独立的、随机的哈希函数来将这个集合 S 中的每个元素 x1、x2、…、xn 映射到这个长度为 m 的位数组上，哈希函数得到的结果记作位置索引，然后将位数组该位置索引的位置 1。例如这里我们取 k 为 3，即有三个哈希函数，x1 经过三个哈希函数映射得到的结果分别为 1、4、8，x2 经过三个哈希函数映射得到的结果分别为 4、6、10，那么就会将位数组的 1、4、6、8、10 这五位置 1，如图 14-8 所示： 
图 14-8 映射后位数组 这时如果再有一个新的元素 x，我们要判断 x 是否属于 S 这个集合，我们便会将仍然用 k 个哈希函数对 x 求映射结果，如果所有结果对应的位数组位置均为 1，那么我们就认为 x 属于 S 这个集合，否则如果有一个不为 1，则 x 不属于 S 集合。 例如一个新元素 x 经过三个哈希函数映射的结果为 4、6、8，对应的位置均为 1，则判断 x 属于 S 这个集合。如果结果为 4、6、7，7 对应的位置为 0，则判定 x 不属于 S 这个集合。 注意这里 m、n、k 满足的关系是 m>nk，也就是说位数组的长度 m 要比集合元素 n 和哈希函数 k 的乘积还要大。 这样的判定方法很高效，但是也是有代价的，它可能把不属于这个集合的元素误认为属于这个集合，我们来估计一下它的错误率。当集合 S={x1, x2,…, xn} 的所有元素都被 k 个哈希函数映射到 m 位的位数组中时，这个位数组中某一位还是 0 的概率是： 
因为哈希函数是随机的，所以任意一个哈希函数选中这一位的概率为 1/m，那么 1-1/m 就代表哈希函数一次没有选中这一位的概率，要把 S 完全映射到 m 位数组中，需要做 kn 次哈希运算，所以最后的概率就是 1-1/m 的 kn 次方。 一个不属于 S 的元素 x 如果要被误判定为在 S 中，那么这个概率就是 k 次哈希运算得到的结果对应的位数组位置都为 1，所以误判概率为： 
根据： 
可以将误判概率转化为： 
在给定 m、n 时，可以求出使得 f 最小化的 k 值为： 
在这里将误判概率归纳如下： 表 14-1 误判概率
图 14-3 代理池接口 
图 14-4 Cookies 池接口 所以接下来我们就需要把 Scrapy 新浪微博项目中的访问链接修改如下：
图 14-5 去重指纹 
图 14-6 爬取队列 随着时间的推移，指纹集合会不断增长，爬取队列会动态变化，爬取的数据也会被储存到 MongoDB 数据库中。 至此 Scrapy 分布式的配置已全部完成。
图 14-1 调度架构 如果两个 Scheduler 同时从队列里面取 Request，每个 Scheduler 都有其对应的 Downloader，那么在带宽足够、正常爬取且不考虑队列存取压力的情况下，爬取效率会有什么变化？没错，爬取效率会翻倍。 这样，Scheduler 可以扩展多个，Downloader 也可以扩展多个。而爬取队列 Queue 必须始终为一个，也就是所谓的共享爬取队列。这样才能保证 Scheduer 从队列里调度某个 Request 之后，其他 Scheduler 不会重复调度此 Request，就可以做到多个 Schduler 同步爬取。这就是分布式爬虫的基本雏形，简单调度架构如图 14-2 所示。 
图 14-2 调度架构 我们需要做的就是在多台主机上同时运行爬虫任务协同爬取，而协同爬取的前提就是共享爬取队列。这样各台主机就不需要各自维护爬取队列，而是从共享爬取队列存取 Request。但是各台主机还是有各自的 Scheduler 和 Downloader，所以调度和下载功能分别完成。如果不考虑队列存取性能消耗，爬取效率还是会成倍提高。
图 13-32 个人详情页面 我们在页面最上方可以看到她的关注和粉丝数量。我们点击关注，进入到她的关注列表，如图 13-33 所示。 
图 13-33 关注列表 我们打开开发者工具，切换到 XHR 过滤器，一直下拉关注列表，即可看到下方会出现很多 Ajax 请求，这些请求就是获取关注列表的 Ajax 请求，如图 13-34 所示。 
图 13-34 请求列表 我们打开第一个 Ajax 请求看一下，发现它的链接为：
图 13-35 请求详情 
图 13-36 响应结果 请求类型是 GET 类型，返回结果是 JSON 格式，我们将其展开之后即可看到其关注的用户的基本信息。接下来我们只需要构造这个请求的参数。此链接一共有 7 个参数，如图 13-37 所示。 
图 13-37 参数信息 其中最主要的参数就是 containerid 和 page。有了这两个参数，我们同样可以获取请求结果。我们可以将接口精简为：
图 13-38 用户信息 
图 13-39 微博信息 针对用户信息，我们不仅爬取了其基本信息，还把关注和粉丝列表加到了 follows 和 fans 字段并做了去重操作。针对微博信息，我们成功进行了时间转换处理，同时还保存了微博的图片列表信息。
图 13-32 运行结果 如果出现类似图 13-29 的运行结果，这就证明构建的镜像没有问题。
图 13-30 推送结果 如果我们想在其他的主机上运行这个镜像，主机上装好 Docker 后，可以直接执行如下命令：
图 13-31 运行效果 整个项目爬取完成后，数据就可以存储到指定的数据库中。
图 13-28 输出结果 返回的是一个 JSON 格式的字符串，我们解析它的结构，如下所示：
最后经排查，发现后端接口使用时设定了 
图 13-19 爬取站点
图 13-20 页面内容 这是新闻的列表页，下一步自然就是将列表中的每条新闻详情的链接提取出来。这里直接指定这些链接所在区域即可。查看源代码，所有链接都在 ID 为 left_side 的节点内，具体来说是它内部的 class 为 con_item 的节点，如图 13-21 所示。 
图 13-21 列表源码 此处我们可以用 LinkExtractor 的 restrict_xpaths 属性来指定，之后 Spider 就会从这个区域提取所有的超链接并生成 Request。但是，每篇文章的导航中可能还有一些其他的超链接标签，我们只想把需要的新闻链接提取出来。真正的新闻链接路径都是以 article 开头的，我们用一个正则表达式将其匹配出来再赋值给 allow 参数即可。另外，这些链接对应的页面其实就是对应的新闻详情页，而我们需要解析的就是新闻的详情信息，所以此处还需要指定一个回调函数 callback。 到现在我们就可以构造出一个 Rule 了，代码如下所示：
图 13-22 分页源码 但是，下一页节点和其他分页链接区分度不高，要取出此链接我们可以直接用 XPath 的文本匹配方式，所以这里我们直接用 LinkExtractor 的 restrict_xpaths 属性来指定提取的链接即可。另外，我们不需要像新闻详情页一样去提取此分页链接对应的页面详情信息，也就是不需要生成 Item，所以不需要加 callback 参数。另外这下一页的页面如果请求成功了就需要继续像上述情况一样分析，所以它还需要加一个 follow 参数为 True，代表继续跟进匹配分析。其实，follow 参数也可以不加，因为当 callback 为空的时候，follow 默认为 True。此处 Rule 定义为如下所示：
图 13-23 运行效果
图 13-24 详情页面 如果像之前一样提取内容，就直接调用 response 变量的 xpath()、css() 等方法即可。这里 parse_item() 方法的实现如下所示：
图 13-25 输出内容 现在我们就可以成功将每条新闻的信息提取出来。 不过我们发现这种提取方式非常不规整。下面我们再用 Item Loader，通过 add_xpath()、add_css()、add_value() 等方式实现配置化提取。我们可以改写 parse_item()，如下所示：
图 13-26 运行结果 现在我们已经对 Spider 的基础属性实现了可配置化。剩下的解析部分同样需要实现可配置化，原来的解析函数如下所示：
图 13-27 运行结果 运行结果是完全相同的。 我们再回过头看一下 start_urls 的配置。这里 start_urls 只可以配置具体的链接。如果这些链接有 100 个、1000 个，我们总不能将所有的链接全部列出来吧？在某些情况下，start_urls 也需要动态配置。我们将 start_urls 分成两种，一种是直接配置 URL 列表，一种是调用方法生成，它们分别定义为 static 和 dynamic 类型。 本例中的 start_urls 很明显是 static 类型的，所以 start_urls 配置改写如下所示： ```json”start_urls”: {“type”:”static”,”value”: [“
图 13-15 页面截图 翻页操作也成功实现，如图 13-16 所示即为当前页码，和我们传入的页码 page 参数是相同的。 
图 13-16 翻页结果 我们只需要在 Spider 里用 SplashRequest 对接 Lua 脚本就好了，如下所示：
图 13-17 运行结果 由于 Splash 和 Scrapy 都支持异步处理，我们可以看到同时会有多个抓取成功的结果。在 Selenium 的对接过程中，每个页面渲染下载是在 Downloader Middleware 里完成的，所以整个过程是阻塞式的。Scrapy 会等待这个过程完成后再继续处理和调度其他请求，这影响了爬取效率。因此使用 Splash 的爬取效率比 Selenium 高很多。 最后我们再看看 MongoDB 的结果，如图 13-18 所示。 
图 13-18 存储结果 结果同样正常保存到了 MongoDB 中。
图 13-13 运行结果 再查看一下 MongoDB，结果如图 13-14 所示： 
图 13-14 MongoDB 结果 这样我们便成功在 Scrapy 中对接 Selenium 并实现了淘宝商品的抓取。
图 13-6 请求列表 我们查看一个请求的详情，观察返回的数据结构，如图 13-7 所示。 
图 13-7 返回结果 返回格式是 JSON。其中 list 字段就是一张张图片的详情信息，包含了 30 张图片的 ID、名称、链接、缩略图等信息。另外观察 Ajax 请求的参数信息，有一个参数 sn 一直在变化，这个参数很明显就是偏移量。当 sn 为 30 时，返回的是前 30 张图片，sn 为 60 时，返回的就是第 31~60 张图片。另外，ch 参数是摄影类别，listtype 是排序方式，temp 参数可以忽略。 所以我们抓取时只需要改变 sn 的数值就好了。 下面我们用 Scrapy 来实现图片的抓取，将图片的信息保存到 MongoDB、MySQL，同时将图片存储到本地。
图 13-8 运行结果 所有请求的状态码都是 200，这就证明图片信息爬取成功了。
图 13-9 输出日志 查看本地 images 文件夹，发现图片都已经成功下载，如图 13-10 所示。 
图 13-10 下载结果 查看 MySQL，下载成功的图片信息也已成功保存，如图 13-11 所示。 
图 13-11 MySQL 结果 查看 MongoDB，下载成功的图片信息同样已成功保存，如图 13-12 所示。 
图 13-12 MongoDB 结果 这样我们就可以成功实现图片的下载并把图片的信息存入数据库了。
图 13-1 Scrapy 架构 它可以分为如下的几个部分。
图 9-10 预装操作系统 推荐安装 CentOS 7 系统。 然后找到远程管理面板 远程连接的用户名和密码，也就是 SSH 远程连接服务器的信息。比如我使用的 IP 和端口是 153.36.65.214:20063，用户名是 root。命令行下输入如下内容：
图 9-11 配置页面 提示成功之后就可以进行拨号了。注意，在拨号之前测试 ping 任何网站都是不通的，因为当前网络还没联通。输入如下拨号命令：
图 9-12 拨号建立连接 断线重播的命令就是二者组合起来，先执行 adsl-stop，再执行 adsl-start。每次拨号，ifconfig 命令观察主机的 IP，发现主机的 IP 一直在变化，网卡名称叫作 ppp0，如图 9-13 所示。 
图 9-13 网络设备信息 接下来，我们要做两件事：一是怎样将主机设置为代理服务器，二是怎样实时获取拨号主机的 IP。
图 9-14 运行结果 如果有正常的结果输出，并且 origin 的值为代理 IP 的地址，就证明 TinyProxy 配置成功了。
图 9-15 Hash 结构 如果有多台主机，只需要向 Hash 中添加映射即可。 另外，get() 方法就是从散列表中取出某台主机对应的代理。remove() 方法则是从散列表中移除对应的主机的代理。还有 names()、proxies()、all() 方法则是分别获取散列表中的主机列表、代理列表及所有主机代理映射。count() 方法则是返回当前散列表的大小，也就是可用代理的数目。 最后还有一个比较重要的方法 random()，它随机从散列表中取出一个可用代理，类似前面代理池的思想，确保每个代理都能被取到。 如果要对数据库进行操作，只需要初始化 RedisClient 对象，然后调用它的 set() 或者 remove() 方法，即可对散列表进行设置和删除。
图 9-16 示例输出 首先移除了代理，再进行拨号，拨号完成之后获取新的 IP，代理检测成功之后就设置到 Redis 散列表中，然后等待一段时间再重新进行拨号。 我们添加了多台拨号主机，这样就有多个稳定的定时更新的代理可用了。Redis 散列表会实时更新各台拨号主机的代理，如图 9-17 所示。 
图 9-17 Hash 结构 图中所示是四台 ADSL 拨号主机配置并运行后的散列表的内容，表中的代理都是可用的。
图 9-18 主页面 访问 proxies 接口可以获得所有代理列表，如图 9-19 所示。 
图 9-19 代理列表 访问 random 接口可以获取随机可用代理，如图 9-20 所示。 
图 9-20 随机代理 我们只需将接口部署到服务器上，即可通过 Web 接口获取可用代理，获取方式和代理池类似。
图 13-5 Scrapy Shell 我们可以在命令行模式下输入命令调用对象的一些操作方法，回车之后实时显示结果。这与 Python 的命令行交互模式是类似的。 接下来，演示的实例都将页面的源码作为分析目标，页面源码如下所示：
图 13-2 页面结构 提取的方式可以是 CSS 选择器或 XPath 选择器。在这里我们使用 CSS 选择器进行选择，parse() 方法的改写如下所示：
图 13-3 页面底部 有一个 Next 按钮，查看一下源代码，可以发现它的链接是 /page/2/，实际上全链接就是：
图 13-4 爬取结果 长的 text 已经被处理并追加了省略号，短的 text 保持不变，author 和 tags 也都相应保存。
图 12-26 运行页面 也可以单独运行 pyspider 的某一个组件。 运行 Scheduler 的命令如下所示：
图 12-27 抓取进度 progress 中的 5m、1h、1d 指的是最近 5 分、1 小时、1 天内的请求情况，all 代表所有的请求情况。 蓝色的请求代表等待被执行的任务，绿色的代表成功的任务，黄色的代表请求失败后等待重试的任务，红色的代表失败次数过多而被忽略的任务，从这里我们可以直观看到爬取的进度和请求情况。
图 12-2 运行结果 这样可以启动 pyspider 的所有组件，包括 PhantomJS、ResultWorker、Processer、Fetcher、Scheduler、WebUI，这些都是 pyspider 运行必备的组件。最后一行输出提示 WebUI 运行在 5000 端口上。可以打开浏览器，输入链接 
图 12-3 WebUI 页面 此页面便是 pyspider 的 WebUI，我们可以用它来管理项目、编写代码、在线调试、监控任务等。
图 12-4 创建项目 接下来会看到 pyspider 的项目编辑和调试页面，如图 12-5 所示。 
图 12-5 调试页面 左侧就是代码的调试页面，点击左侧右上角的 run 单步调试爬虫程序，在左侧下半部分可以预览当前的爬取页面。右侧是代码编辑页面，我们可以直接编辑代码和保存代码，不需要借助于 IDE。 注意右侧，pyspider 已经帮我们生成了一段代码，代码如下所示：
图 12-6 操作示例 左栏左上角会出现当前 run 的配置文件，这里有一个 callback 为 on_start，这说明点击 run 之后实际是执行了 on_start() 方法。在 on_start() 方法中，我们利用 crawl() 方法生成一个爬取请求，那下方 follows 部分的数字 1 就代表了这一个爬取请求。 点击下方的 follows 按钮，即可看到生成的爬取请求的链接。每个链接的右侧还有一个箭头按钮，如图 12-7 所示。 
图 12-7 操作示例 点击该箭头，我们就可以对此链接进行爬取，也就是爬取攻略的首页内容，如图 12-8 所示。 
图 12-8 爬取结果 上方的 callback 已经变成了 index_page，这就代表当前运行了 index_page() 方法。index_page() 接收到的 response 参数就是刚才生成的第一个爬取请求的 Response 对象。index_page() 方法通过调用 doc() 方法，传入提取所有 a 节点的 CSS 选择器，然后获取 a 节点的属性 href，这样实际上就是获取了第一个爬取页面中的所有链接。然后在 index_page() 方法里遍历了所有链接，同时调用 crawl() 方法，就把这一个个的链接构造成新的爬取请求了。所以最下方 follows 按钮部分有 217 的数字标记，这代表新生成了 217 个爬取请求，同时这些请求的 URL 都呈现在当前页面了。 再点击下方的 web 按钮，即可预览当前爬取结果的页面，如图 12-9 所示。 
图 12-9 预览页面 当前看到的页面结果和浏览器看到的几乎是完全一致的，在这里我们可以方便地查看页面请求的结果。 点击 html 按钮即可查看当前页面的源代码，如图 12-10 所示。 
图 12-10 页面源码 如果需要分析代码的结构，我们可以直接参考页面源码。 我们刚才在 index_page() 方法中提取了所有的链接并生成了新的爬取请求。但是很明显要爬取的肯定不是所有链接，只需要攻略详情的页面链接就够了，所以我们要修改一下当前 index_page() 里提取链接时的 CSS 选择器。 接下来需要另外一个工具。首先切换到 Web 页面，找到攻略的标题，点击下方的 enable css selector helper，点击标题。这时候我们看到标题外多了一个红框，上方出现了一个 CSS 选择器，这就是当前标题对应的 CSS 选择器，如图 12-11 所示。 
图 12-11 CSS 工具 在右侧代码选中要更改的区域，点击左栏的右箭头，此时在上方出现的标题的 CSS 选择器就会被替换到右侧代码中，如图 12-12 所示。 
图 12-12 操作结果 这样就成功完成了 CSS 选择器的替换，非常便捷。 重新点击左栏右上角的 run 按钮，即可重新执行 index_page() 方法。此时的 follows 就变成了 10 个，也就是说现在我们提取的只有当前页面的 10 个攻略，如图 12-13 所示。 
图 12-13 运行结果 我们现在抓取的只是第一页的内容，还需要抓取后续页面，所以还需要一个爬取链接，即爬取下一页的攻略列表页面。我们再利用 crawl() 方法添加下一页的爬取请求，在 index_page() 方法里面添加如下代码，然后点击 save 保存：
图 12-14 运行结果 现在，索引列表页的解析过程我们就完成了。
图 12-15 运行结果 切换到 Web 页面预览效果，页面下拉之后，头图正文中的一些图片一直显示加载中，如图 12-16 和图 12-17 所示。 
图 12-16 预览结果 
图 12-17 预览结果 查看源代码，我们没有看到 img 节点，如图 12-18 所示。 
图 12-18 源代码 出现此现象的原因是 pyspider 默认发送 HTTP 请求，请求的 HTML 文档本身就不包含 img 节点。但是在浏览器中我们看到了图片，这是因为这张图片是后期经过 JavaScript 出现的。那么，我们该如何获取呢？ 幸运的是，pyspider 内部对接了 PhantomJS，那么我们只需要修改一个参数即可。 我们将 index_page() 中生成抓取详情页的请求方法添加一个参数 fetch_type，改写的 index_page() 变为如下内容：
图 12-19 爬取详情 再点击新生成的详情页 Request 的爬取按钮，这时我们便可以看到页面变成了这样子，如图 12-20 所示。 
图 12-20 运行结果 图片被成功渲染出来，这就是启用了 PhantomJS 渲染后的结果。只需要添加一个 fetch_type 参数即可，这非常方便。 最后就是将详情页中需要的信息提取出来，提取过程不再赘述。最终 detail_page() 方法改写如下所示：
图 12-21 输出结果 左栏中输出了最终构造的字典信息，这就是一篇攻略的抓取结果。
图 12-22 启动爬虫 在最左侧我们可以定义项目的分组，以方便管理。rate/burst 代表当前的爬取速率，rate 代表 1 秒发出多少个请求，burst 相当于流量控制中的令牌桶算法的令牌数，rate 和 burst 设置的越大，爬取速率越快，当然速率需要考虑本机性能和爬取过快被封的问题。process 中的 5m、1h、1d 指的是最近 5 分、1 小时、1 天内的请求情况，all 代表所有的请求情况。请求由不同颜色表示，蓝色的代表等待被执行的请求，绿色的代表成功的请求，黄色的代表请求失败后等待重试的请求，红色的代表失败次数过多而被忽略的请求，这样可以直观知道爬取的进度和请求情况，如图 12-23 所示。 
图 12-23 爬取情况 点击 Active Tasks，即可查看最近请求的详细状况，如图 12-24 所示。 
图 12-24 最近请求 点击 Results，即可查看所有的爬取结果，如图 12-25 所示。 
图 12-25 爬取结果 点击右上角的按钮，即可获取数据的 JSON、CSV 格式。
图 12-1 pyspider 架构图 Scheduler 发起任务调度，Fetcher 负责抓取网页内容，Processer 负责解析网页内容，然后将新生成的 Request 发给 Scheduler 进行调度，将生成的提取结果输出保存。 pyspider 的任务执行流程的逻辑很清晰，具体过程如下所示。
