爬⾍项⽬经验总结
前⾔
人类与环境
从新数据库 mongodb 到基于内存的 key-value 数据库 Redis，从 scrapy 爬⾍框架到 re 正则表达式模块，尤其正则，以前不会写的时候总是依赖 string 的各种⽅法，部分时候显得有些繁琐，会正则了之后在字符串的匹配、查、替换、分隔⽅⾯打开了另⼀扇便捷之窗。另外，将 Redis 引⼊爬⾍架构来实现分布式，也算是⼀个技术理念的突破吧，也为后⾯研究⾼并发站点打下了基础。鸟的祖先
其实前⾯说了那么多唬⼈的东西，⽤的时候倒是没有说有实在适应不来的，作为⼀个敲了年代码的砖⼯来说算不上什么技术攻坚，可能在 Nosql 和正则模块(包括正则语法和 re 模块)投⼊的精⼒相对多⼀点。业务上，对于⽹页结构的分析和⼀个⾼覆盖率 url 爬取策略的制定还是得跟有经验的开发⼈员多讨论，就爬⾍来说，技术不是重点，更多的是对站点页⾯跳转套路的分析。 下⾯就结合实际开发中常遇到的⼀些问题分节对爬⾍这块的注意事项做⼀个简要讲解。新干线
取消合法性检验以改进爬取⽅案
我这⾥要讲的是在确认程序语法⽆误后，以故意制造 AtttributeError 来完善爬取策略，算不上什么⽅案，⼀点写法上的⼩技巧吧。
这个报错具体解释起来就是 'NoneType' object has no attribute ，类似于 java ⾥⾯的空指针异常。⾸先，解决这个异常的⽅式很简单，⽐如让 soup 在查上⼀级标签的时候做⼀次是否为空的判断，如果不为空则继续查到下⼀级⽬标：(if parentNode: ...)。但实际上最开始写这块内容的时候要避免这种条件判断，因为我们并不知道我们要的⽬标在该类⽹页当中是否只存在⼀种结构，有可能有的页⾯压根⼉没那个标签，也有可能标签名不⼀样或者类名变了等等情况，这需要我们在测试过程中去记录下所有出错的页⾯，逐⼀排查这些页⾯的特殊结构，这样才能有效地保证我们所爬取的页⾯覆盖⾯更⼴，数据更全。下⾯拿实际代码举个例⼦： soup = BeautifulSoup(response.body_as_unicode(),'lxml')
citys = soup.find('div',class_="piList").find_all('span')
for city in citys:三围地图
href = city.find('a').get('href')
yield Request(href, _url)
这⾥在获取⽹页中城市的链接的时候，并没有⾸先去对 span 的祖先(前端术语) class 为 piList 是否存在做判断，因为在爬这类的⽹页的时候当然会有可能说是部分页⾯的城市信息压根不放在这⾥⾯，
类名为 piList 的标签压根不存在，这时候程序会在这⾥报 AtttributeError 但不会影响爬⾍的继续运⾏，等整个程序执⾏完毕，scrapy 会有⼀个总的出错统计在⽇志的末尾，我们就顺着总数⼀⼀出出错位置对应的页⾯ url 再去浏览器到该页⾯，重新分析其⽂档结构，或改类名，或改标签名，最后完善成类似下⾯的代码:
soup = BeautifulSoup(response.body_as_unicode(),'lxml')
city_list = soup.find('div',class_="piList")
if not city_list:
city_list = soup.find('div',id="citys")
citys = city_list.find_all('span')
for city in citys:
href = city.find('a').get('href')
yield Request(href, _url)
朝鲜族语言
关于使⽤浏览器开发者⼯具查看⽹页
我们在⽤浏览器的开发者⼯具分析⽹页的时候，最好是在 Sources 下⾯查看⽹站源码，因为我们爬⾍爬下来的内容是未经浏览器渲染的(尽管有这样的⼯具，⽐如 PyQt 中的 webkit)。但是⼤多数情况下我们在 Elements 审查/检查窗⼝看到的内容与 Sources 下⾯是⼀致的，⽽且在这下⾯进⾏标签的查看和⽂档结构的分析也更⽅便，所以可在其下⾯定位⽬标后到 Sources 中确认是否能到，再确定 beautifulsoup 或 xpath 的写法，尤其对于翻页和通过事件响应跳出的弹窗。
北京奥运会入场式
