A. python爬虫和测试的区别
爬虫的基本流程
发起请求
通过HTTP库向目标站点发起请求，也就是发送一个Request，请求可以包含额外的header等信息，等待服务器响应
获取响应内容
如果服务器能正常响应，会得到一个Response，Response的内容便是所要获取的页面内容，类型可能是HTML,Json字符串，二进制数据（图片或者视频）等类型
解析内容
得到的内容可能是HTML,可以用正则表达式，页面解析库进行解析，可能是Json,可以直接转换为Json对象解析，可能是二进制数据，可以做保存或者进一步的处理
保存数据
保存形式多样，可以存为文本，也可以保存到数据库，或者保存特定格式的文件
B. Python什么爬虫库好用
请求库：
1. requests 这个库是爬虫最常用的一个库
2. Selenium Selenium 是一个自动化测试工具，利用它我们可以驱动浏览器执行特定的动作，如点击、下拉等操作 对于一些用JS做谊染的页面来说，这种抓取方式是非常有效的。
3.ChomeDrive 安装了这个库，才能驱动Chrome浏览器完成相应的操作
4.GeckoDriver 使用W3C WebDriver兼容客户端与基于Gecko的浏览器进行交互的代理。
5.PhantomJS PhantomJS 是一个无界面 、可脚本编程的 WebKit 浏览器引擎，它原生支持多种Web标准：Dom操作，css选择器，json，Canvas以及SVG。
6.aiohttp 之前接收requests库是一个阻塞式HTTP请求库，当我们发送一个请求后。程序会一直等待服务器响应，直到服务器响应后，程序才会最下一步处理。其实，这个过程比较耗时间。如果程序可以在等待的过程中做一些其他的事情，如进行请求的调度，响应的处理等，那么爬虫的效率就会比之前的那种方式有很大的提升。 而aiohttp就是这样一个提供异步web服务的库。使用说这个库用起来还是相当方便的。
解析库：
1.lxml lxml是python的一个解析库，这个库支持HTML和xml的解析，支持XPath的解析方式，而且效率也是非常高的，深受广大程序员的热爱
2.Beautiful Soup Beautiful Soup也是python里一个HTML或XMl的解析库，它可以很方便的懂网页中提取数据，拥有强大的API和多种解析方式。
3.pyquery 同样是一个强大的网页解析工具，它提供了和 jQuery 类似的语法来解析HTML 文梢，
数据库：
1.mysql 数据库
2.MongoDB Mo goDB 是由 ＋＋语言编写的非关系型数据库， 是一个基于分布式文件存储的开源数据库系统内容存储形式类似 JSON 对象，它的字段值可以包含其他文档、数组及文档数组，非常灵活
3.Redis 是一个基于 存的高效的非关系型数据库，
存储库：
1.PyMySOL
2.PyMongo
3.redis-py
4.RedisDump
web库：
1.Flask 是一个轻量级的Web服务程序，它简单，易用，灵活
2.Tornado 是一个支持异步的Web框架，通过使用非阻塞I/O流，可以支持成千上万的开放式连接。
C. dbcontext是注入还是传递好
在EntityFramework6中管理DbContext的正确方式——3环境上下文DbContext vs 显式DbContext vs 注入DbContext(外文翻译)
(译者注：使用EF开发应用程序的一个难点就在于对其DbContext的生命周期管理，你的管理策略是否能很好的支持上层服务 使用独立事务，使用嵌套事务，并行执行，异步执行等需求？ Mehdi El Gueddari对此做了深入研究和优秀的工作并且写了一篇优秀的文章，现在我将其翻译为中文分享给大家。由于原文太长，所以翻译后的文章将分为四篇。你看到的这篇就是是它的第三篇。原文地址：http://mehdi.me/ambient-dbcontext-in-ef6/)
环境上下文DbContext vs 显式DbContext vs 注入DbContext
在任何基于EF项目之初的一个关键决定就是你的代码如何传递DbContext实例到下面真正访问数据库的方法里面。
就像我们在上面看到的，创建和释放DbContext的职责属于顶层服务方法。数据访问代码，就是那些真正使用DbContext实例的代码，可能经常在一个独立的部分里面——可能深入在服务实现类的一个私有方法里面，也可能在一个查询对象里面或者一个独立的仓储层里面。
顶层服务方法创建的DbContext实例需要找到一个传递到这些方法的方式。
这儿有三个想法来让数据访问代码访问DbContext:环境上下文DbContext,显式DbContext或者注入DbContext。每一种方式都有它们各自的优缺点，让我们来逐个分析。
显式DbContext
它看起来是怎么样的
使用显式DbContext方法，顶层服务创建一个DbContext实例然后通过一个方法的参数传递至数据访问的部分。在一个传统的包含服务层和仓储层的三层架构中，大概看起来就是这样：
public class UserService : IUserService
{
private readonly IUserRepository _userRepository;
public UserService(IUserRepository userRepository)
{
if (userRepository == null) throw new ArgumentNullException("userRepository");
_userRepository = userRepository;
}
public void MarkUserAsPremium(Guid userId)
{
using (var context = new MyDbContext())
{
var user = _userRepository.Get(context, userId);
user.IsPremiumUser = true;
context.SaveChanges();
}
}
}
public class UserRepository : IUserRepository
{
public User Get(MyDbContext context, Guid userId)
{
return context.Set<User>().Find(userId);
}
}
（在这个故意为之的示例里面，仓储层的作用当然是完全无意义的。在一个真实的应用程序中，你将期望仓储层更加饱满。另外，如果你真的不想让你的服务直接依赖EF,你可以抽象你的DbContext为“IDbContext”之类的并且通过一个抽象工厂来创建它。）
优点
这种方式是到目前为止而且永远也是最简单的方式。它使得代码非常简单易懂而且易于维护——即使对于那些对代码不是很熟悉的开发人员来说也是这样的。
这儿没有任何神奇的地方。DbContext实例不会凭空创建。它是在一个清晰的明显的地方被创建——如果你好奇DbContext来源于哪儿的话你也可以通过调用栈非常容易的找到。
缺点
这种方式最主要的缺点是它要求你去污染所有你的所有仓储方法（如果你有一个仓储层的话），同样你的大多服务方法也会有一个强制的DbContext参数（或者某种类型的IDbContext抽象——如果你不希望绑定到具体实现的话——但是问题仍然存在）。所以你可能会看到某些方法注入模式的应用。
你的仓储层方法要求提供一个显式的DbContext作为参数也不是什么大问题。实际上，它甚至可以看着已经好事——因为他消除了潜在的歧义——就是这些查询究竟用的哪一个DbContext。
但是对于服务层情况就大不一样了。因为大部分你的服务方法都不会用DbContext,尤其是你将数据访问代码隔离在一个查询对象或者仓储层里面的时候。因此，这些服务方法提供了一个DbContext参数的目的仅仅是为了将他们传递到下层真正需要用到DbContext的方法里面。
这很容易变得十分丑陋。尤其是你的应用程序需要使用多个DbContext的时候，将导致你的服务方法要求两个甚至更多的DbContext参数。这将混淆你的方法的契约——因为你的服务方法现在强制要求一个它们既不需要也不会用而仅仅是为了满足底层方法依赖的参数。
Jon Skeet写了一篇关于显式DbContext vs 隐式DbContext的文章，但没有提供一个好的解决方案。
然而，这种方法的超级简单性还是很难被其它方法打败的。
环境上下文DbContext
它看起来是怎么样的
NHibernate用户应当是对这种方式非常熟悉——因为环境上下文模式（ambient context pattern)是在NHibernate世界里面管理NHibernate的Session（它相当于EF的DbContext）的主要方式。NHibernate甚至对该模式有内置支持，叫做上下文session(contextual session)。
在.NET自身，这种模式也是用得相当广泛。你可能已经用过HttpContext.Current或者TransactionScope，两者都是依赖于环境上下文模式。
使用这种模式，顶层服务方法不仅创建用于当前业务事务的DbContext，而且还要将其注册为环境上下文DbContext。然后数据访问代码就可以在需要时候获取这个环境上下文DbContext了。再也不需要传递DbContext实例。
Anders Abel已经写过一篇文章——简单实现环境上下文DbContext——它依赖ThreadStatic变量来存储DbContext。去看看吧——它比听起来都还要更简单。
优点
这种方式的优点是显然的。你的服务和仓储方法现在对DbContext参数已经自由了（也就是说服务和仓储方法不需要DbContext作为参数了）——让你的接口更加干净并且你的方法契约更加清晰——因为它们现在只需要获取他们真正需要使用的参数了。再也不需要遍地传递DbContext实例了。
缺点
无论如何这种方式引入了一定程度的魔法——它让代码更难理解和维护。当看到数据访问代码的时候，不一定容易发现环境上下文DbContext来自于哪儿。你不得不希望在调用数据访问代码之前某人已经将它注册了。
如果你的应用程序使用多个DbContext派生类，比如，如果你连接多个数据库或者如果你将领域模型划分为几个独立的组，那么对于顶层服务来说就很难知道应当创建和注册哪些DbContext了。使用显式DbContext,数据访问方法要求提供它们需要的DbContext作为参数，因此就不存在歧义的可能。但是使用环境上下文方式，顶层服务方法必须知道下层数据访问代码需要哪种DbContext类型。我们将在后面看到一些解决这个问题的十分干净的方式。
最后，我在上面链接的环境上下文DbContext例子只能在单线程模型很好的工作。如果你打算使用EF的异步查询功能的话，它就不能工作了。在一个异步操作完成后，你很可能发现你自己已经在另外一个线程——不再是之前创建DbContext的线程。在许多情况下，它意味着你的环境上下文DbContext将消失。这个问题可以解决，但是它要求一些深入的理解——在.NET世界里面如何多线程编程，TPL和异步工作背后的原理。我们将在文章最后看到这些。
注入DbContext
它看起来是怎么样的
最后一种比较重要的方式，注入DbContext方式经常被各种文章和博客提及用来解决DbContext生命周期的问题。
使用这种方式，你可以让DI容器管理DbContext的生命周期并且在任何组件（比如仓储对象）需要的时候就注入它。
看起来就是这样的：
public class UserService : IUserService
{
private readonly IUserRepository _userRepository;
public UserService(IUserRepository userRepository)
{
if (userRepository == null) throw new ArgumentNullException("userRepository");
_userRepository = userRepository;
}
public void MarkUserAsPremium(Guid userId)
{
var user = _userRepository.Get(context, userId);
user.IsPremiumUser = true;
}
}
public class UserRepository : IUserRepository
{
private readonly MyDbContext _context;
public UserRepository(MyDbContext context)
{
if (context == null) throw new ArgumentNullException("context");
_context = context;
}
public User Get(Guid userId)
{
return _context.Set<User>().Find(userId);
}
}
然后你需要配置你的DI容器以使用合适的生命周期策略来创建DbContext实例。你将发现一个常见的建议是对于Web应用程序使用一个PerWebRequest生命周期策略，对于桌面应用使用PerForm生命周期策略。
优点
好处与环境上下文DbContext策略相似：代码不需要到处传递DbContext实例。这种方式甚至更进一步：在服务方法里面根本看不到DbContext。服务方法完全不知道EF的存在——第一眼看起来可能很好，但很快就会发现这种策略会导致很多问题。
缺点
不管这种策略有多流行，它确切是有非常重大的缺陷和限制。在采纳之前先了解它是非常重要的。
太多魔法
这种方式的第一个问题就是太依赖魔法。当需要保证你的数据——你最珍贵的资产的正确性和一致性的时候，“魔法”不是你想听到太频繁的一个词。
这些DbContext实例来自于哪里？业务事务的边界如何定义和在哪儿定义？如果一个服务方法依赖两个不同的仓储类，那么这两个仓储式都访问同一个DbContext实例呢还是它们各自拥有自己的DbContext实例？
如果你是一个后端开发人员并且在开发基于EF的项目，那么想要写出正确代码的话，就必须知道这些问题的答案。
答案并不明显，它需要你详细查看DI容器的配置代码才能发现。就像我们前面看到的，要正确设置这些配置不是第一眼看上去那么容易，相反，它可能是非常复杂而且容易出错的。
不清晰的业务事务边界
可能上面示例代码最大的问题是：谁负责提交修改到数据库？也就是谁调用DbContext.SaveChanges()方法？它是不清晰的。
你可以仅仅是为了调用SaveChanges()方法而将DbContext注入你的服务方法。那将是更令人费解和容易出错的代码。为什么服务方法在一个既不是它创建的又不是它要使用的DbContext对象上调用SaveChanges()方法呢？它将保存什么修改？
另外，你也可以在你的所有仓储对象上定义一个SaveChanges()方法——它仅仅委托给底层的DbContext。然后服务方法在仓储对象上调用SaveChanges()方法。这也将是非常具有误导性的代码——因为他暗示着每一个仓储对象实现了它们自己的工作单元并且可以独立于其它仓储对象持久化自己的修改——这显然不是正确的，因为他们实际上是用的都是同一个DbContext实例。
有些时候你会看到还有一种方式：让DI容器在释放DbContext实例之前调用SaveChanges()方法。这是一个灾难的方法——值得一篇文章来描述。
简短来说，DI容器是一种基础设施组件——它对它管理的组件的业务逻辑一无所知。相反，DbContext.SaveChanges()方法定义了一个业务事务的边界——也就是说它是以业务逻辑为中心的。混合两种完全不相关的概念在一起将会引起很多问题。
话虽如此，如果你知道“仓储层已死（Repository is Dead）”运动。谁来调用DbContext.SaveChanges()方法根本不是问题——因为你的服务方法将直接使用DbContext实例。它们因此很自然的成为调用SaveChanges()方法的地方。
当你使用注入DbContext策略的时候，不管你的应用程序的架构模式，你将还会遇到一些其它的问题。
强制你的服务变成有状态的
一个值得注意的地方是DbContext不是一个服务。它是一个资源，一个需要释放的资源。通过将它注入到你的数据访问层。你将使那一层的所有上层——很可能就是整个应用程序，都变成有状态的。
这当然不是世界末日但它却肯定会让DI容器的配置变得更复杂。使用无状态的服务将提供巨大的灵活性并且使得配置它们的生命周期变得不会出错。一旦你引入状态化的服务，你就得认真考虑你服务的生命周期了。
注入DbContext这种方式在项目刚开始的时候很容易使用（PerWebRequest或者Transient生命周期都能很好的适应简单的web应用），但是控制台应用程序，Window服务等让它变得越来越复杂了。
阻止多线程
另外一个问题（相对前一个来说）将不可避免的狠咬你一口——注入DbContext将阻止你在服务中引入多线程或者某种并行执行流的机制。
请记住DbContext(就像NHibernate中的Session)不是线程安全的。如果你需要在一个服务中并行执行多个任务，你必须确保每个任务都使用它们自身的DbContext实例，否则应用程序将在运行时候崩溃。但这对于注入DbContext的方式来说是不可能的事情因为服务不能控制DbContext实例的创建。
你怎么修复这个缺陷呢？答案是不容易。
你的第一直觉可能是将你的服务方法修改为依赖DbContext工厂而非直接依赖DbContext。这将允许它们在需要的时候创建它们自己的DbContext实例。但这样做将会有效地推翻注入DbContext这种观点。如果你的服务通过一个工厂创建它们自己的DbContext实例，这些实例再也不能被注入了。那将意味着服务将显式传递这些DbContext实例到下层需要它们的地方（比如说仓储层）。这样你又回到了之前我们讨论的显式DbContext策略了。我可以想到一些解决这些问题的方法——但所有这些方法感觉起来像不寻常手段而不是干净并且优雅的解决方案。
另外一种解决这个问题的方式就是添加更多复杂的层，引入一个像RabbitMQ 的中间件并且让它为你分发任务。这可能行得通但也有可能行不通——完全取决于为什么你需要引入并发性。但是在任何情况下，你可能都不需要也不想要附加的开销和复杂性。
使用注入DbContext的方式，你最好限制你自己只使用单线程代码或者至少是一个单一的逻辑执行流。这对于大部分应用程序都是完美的，但是在特定情况下，它将变成一个很大的限制。
相关阅读:
使用mongodb保存爬取豆瓣电影的数据
使用scrapy爬取阳光热线问政平台
使用scrapy爬取手机版斗鱼主播的房间图片及昵称
使用selenium + chrome爬取中国大学Mooc网的计算机学科的所有课程链接
使用scrapy爬取腾讯社招，获取所有分页的职位名称及chaolia、类型、人数、工作地点、发布日期超链接
python2使用bs4爬取腾讯社招
使用python2爬取网络贴吧指定关键字和分页帖子楼主所发的图片
提问的智慧
深刻理解系统架构师和系统分析师定义
Redis基础数据结构与核心原理
D. Python爬虫可以爬取什么
Python爬虫可以爬取的东西有很多，Python爬虫怎么学？简单的分析下：
如果你仔细观察，就不难发现，懂爬虫、学习爬虫的人越来越多，一方面，互联网可以获取的数据越来越多，另一方面，像 Python这样的编程语言提供越来越多的优秀工具，让爬虫变得简单、容易上手。
利用爬虫我们可以获取大量的价值数据，从而获得感性认识中不能得到的信息，比如：
知乎：爬取优质答案，为你筛选出各话题下最优质的内容。
淘宝、京东：抓取商品、评论及销量数据，对各种商品及用户的消费场景进行分析。
安居客、链家：抓取房产买卖及租售信息，分析房价变化趋势、做不同区域的房价分析。
拉勾网、智联：爬取各类职位信息，分析各行业人才需求情况及薪资水平。
雪球网：抓取雪球高回报用户的行为，对股票市场进行分析和预测。
爬虫是入门Python最好的方式，没有之一。Python有很多应用的方向，比如后台开发、web开发、科学计算等等，但爬虫对于初学者而言更友好，原理简单，几行代码就能实现基本的爬虫，学习的过程更加平滑，你能体会更大的成就感。
掌握基本的爬虫后，你再去学习Python数据分析、web开发甚至机器学习，都会更得心应手。因为这个过程中，Python基本语法、库的使用，以及如何查找文档你都非常熟悉了。
对于小白来说，爬虫可能是一件非常复杂、技术门槛很高的事情。比如有人认为学爬虫必须精通 Python，然后哼哧哼哧系统学习 Python 的每个知识点，很久之后发现仍然爬不了数据；有的人则认为先要掌握网页的知识，遂开始 HTMLCSS，结果入了前端的坑，瘁……
但掌握正确的方法，在短时间内做到能够爬取主流网站的数据，其实非常容易实现，但建议你从一开始就要有一个具体的目标。
在目标的驱动下，你的学习才会更加精准和高效。那些所有你认为必须的前置知识，都是可以在完成目标的过程中学到的。这里给你一条平滑的、零基础快速入门的学习路径。
1.学习 Python 包并实现基本的爬虫过程
2.了解非结构化数据的存储
3.学习scrapy，搭建工程化爬虫
4.学习数据库知识，应对大规模数据存储与提取
5.掌握各种技巧，应对特殊网站的反爬措施
6.分布式爬虫，实现大规模并发采集，提升效率
一
学习 Python 包并实现基本的爬虫过程
大部分爬虫都是按“发送请求——获得页面——解析页面——抽取并储存内容”这样的流程来进行，这其实也是模拟了我们使用浏览器获取网页信息的过程。
Python中爬虫相关的包很多：urllib、requests、bs4、scrapy、pyspider 等，建议从requests+Xpath 开始，requests 负责连接网站，返回网页，Xpath 用于解析网页，便于抽取数据。
如果你用过 BeautifulSoup，会发现 Xpath 要省事不少，一层一层检查元素代码的工作，全都省略了。这样下来基本套路都差不多，一般的静态网站根本不在话下，豆瓣、糗事网络、腾讯新闻等基本上都可以上手了。
当然如果你需要爬取异步加载的网站，可以学习浏览器抓包分析真实请求或者学习Selenium来实现自动化，这样，知乎、时光网、猫途鹰这些动态的网站也可以迎刃而解。
二
了解非结构化数据的存储
爬回来的数据可以直接用文档形式存在本地，也可以存入数据库中。
开始数据量不大的时候，你可以直接通过 Python 的语法或 pandas 的方法将数据存为csv这样的文件。
当然你可能发现爬回来的数据并不是干净的，可能会有缺失、错误等等，你还需要对数据进行清洗，可以学习 pandas 包的基本用法来做数据的预处理，得到更干净的数据。
三
学习 scrapy，搭建工程化的爬虫
掌握前面的技术一般量级的数据和代码基本没有问题了，但是在遇到非常复杂的情况，可能仍然会力不从心，这个时候，强大的 scrapy 框架就非常有用了。
scrapy 是一个功能非常强大的爬虫框架，它不仅能便捷地构建request，还有强大的 selector 能够方便地解析 response，然而它最让人惊喜的还是它超高的性能，让你可以将爬虫工程化、模块化。
学会 scrapy，你可以自己去搭建一些爬虫框架，你就基本具备爬虫工程师的思维了。
四
学习数据库基础，应对大规模数据存储
爬回来的数据量小的时候，你可以用文档的形式来存储，一旦数据量大了，这就有点行不通了。所以掌握一种数据库是必须的，学习目前比较主流的 MongoDB 就OK。
MongoDB 可以方便你去存储一些非结构化的数据，比如各种评论的文本，图片的链接等等。你也可以利用PyMongo，更方便地在Python中操作MongoDB。
因为这里要用到的数据库知识其实非常简单，主要是数据如何入库、如何进行提取，在需要的时候再学习就行。
五
掌握各种技巧，应对特殊网站的反爬措施
当然，爬虫过程中也会经历一些绝望啊，比如被网站封IP、比如各种奇怪的验证码、userAgent访问限制、各种动态加载等等。
遇到这些反爬虫的手段，当然还需要一些高级的技巧来应对，常规的比如访问频率控制、使用代理IP池、抓包、验证码的OCR处理等等。
往往网站在高效开发和反爬虫之间会偏向前者，这也为爬虫提供了空间，掌握这些应对反爬虫的技巧，绝大部分的网站已经难不到你了.
六
分布式爬虫，实现大规模并发采集
爬取基本数据已经不是问题了，你的瓶颈会集中到爬取海量数据的效率。这个时候，相信你会很自然地接触到一个很厉害的名字：分布式爬虫。
分布式这个东西，听起来很恐怖，但其实就是利用多线程的原理让多个爬虫同时工作，需要你掌握 Scrapy + MongoDB + Redis 这三种工具。
Scrapy 前面我们说过了，用于做基本的页面爬取，MongoDB 用于存储爬取的数据，Redis 则用来存储要爬取的网页队列，也就是任务队列。
所以有些东西看起来很吓人，但其实分解开来，也不过如此。当你能够写分布式的爬虫的时候，那么你可以去尝试打造一些基本的爬虫架构了，实现一些更加自动化的数据获取。
你看，这一条学习路径下来，你已然可以成为老司机了，非常的顺畅。所以在一开始的时候，尽量不要系统地去啃一些东西，找一个实际的项目（开始可以从豆瓣、小猪这种简单的入手），直接开始就好。
因为爬虫这种技术，既不需要你系统地精通一门语言，也不需要多么高深的数据库技术，高效的姿势就是从实际的项目中去学习这些零散的知识点，你能保证每次学到的都是最需要的那部分。
当然唯一麻烦的是，在具体的问题中，如何找到具体需要的那部分学习资源、如何筛选和甄别，是很多初学者面临的一个大问题。
以上就是我的回答，希望对你有所帮助，望采纳。
E. 爬虫框架都有什么
主流爬虫框架通常由以下部分组成：
1.种子URL库：URL用于定位互联网中的各类资源，如最常见的网页链接，还有常见的文件资源、流媒体资源等。种子URL库作为网络爬虫的入口，标识出爬虫应该从何处开始运行，指明了数据来源。
2.数据下载器：针对不同的数据种类，需要不同的下载方式。主流爬虫框架通畅提供多种数据下载器，用来下载不同的资源，如静态网页下载器、动态网页下载器、FTP下载器等。
3.过滤器：对于已经爬取的URL，智能的爬虫需要对其进行过滤，以提高爬虫的整体效率。常用的过滤器有基于集合的过滤器、基于布隆过滤的过滤器等。
4.流程调度器：合理的调度爬取流程，也可以提高爬虫的整体效率。在流程调度器中，通常提供深度优先爬取、广度优先爬取、订制爬取等爬取策略。同时提供单线程、多线程等多种爬取方式。
F. python的爬虫框架有哪些
1.Scrapy是一个为了爬取网站数据，提取结构性数据而编写的应用框架。 可以应用在包括数据挖掘，信息处理或存储历史数据等一系列的程序中
2.pyspider 是一个用python实现的功能强大的网络爬虫系统，能在浏览器界面上进行脚本的编写，功能的调度和爬取结果的实时查看，后端使用常用的数据库进行爬取结果的存储，还能定时设置任务与任务优先级等。
3.Crawley可以高速爬取对应网站的内容，支持关系和非关系数据库，数据可以导出为JSON、XML等
4.Beautiful Soup 是一个可以从HTML或XML文件中提取数据的Python库.它能够通过你喜欢的转换器实现惯用的文档导航,查找,修改文档的方式.Beautiful Soup会帮你节省数小时甚至数天的工作时间。
还有很多，比如Newspaper，Grab，Cola等等
爬虫框架学习可以看一下黑马程序员视频库的学习视频，免费学习哦！很高兴能为你提供帮助
G. Python的爬虫框架有哪些
向大家推荐十个Python爬虫框架。
1、Scrapy：Scrapy是一个为了爬取网站数据，提取结构性数据而编写的应用框架。 可以应用在包括数据挖掘，信息处理或存储历史数据等一系列的程序中。它是很强大的爬虫框架，可以满足简单的页面爬取，比如可以明确获知url pattern的情况。用这个框架可以轻松爬下来如亚马逊商品信息之类的数据。但是对于稍微复杂一点的页面，如weibo的页面信息，这个框架就满足不了需求了。它的特性有：HTML, XML源数据 选择及提取 的内置支持；提供了一系列在spider之间共享的可复用的过滤器(即 Item Loaders)，对智能处理爬取数据提供了内置支持。
2、Crawley：高速爬取对应网站的内容，支持关系和非关系数据库，数据可以导出为JSON、XML等。
3、Portia：是一个开源可视化爬虫工具，可让使用者在不需要任何编程知识的情况下爬取网站！简单地注释自己感兴趣的页面，Portia将创建一个蜘蛛来从类似的页面提取数据。简单来讲，它是基于scrapy内核；可视化爬取内容，不需要任何开发专业知识；动态匹配相同模板的内容。
4、newspaper：可以用来提取新闻、文章和内容分析。使用多线程，支持10多种语言等。作者从requests库的简洁与强大得到灵感，使用Python开发的可用于提取文章内容的程序。支持10多种语言并且所有的都是unicode编码。
5、Python-goose：Java写的文章提取工具。Python-goose框架可提取的信息包括：文章主体内容、文章主要图片、文章中嵌入的任何Youtube/Vimeo视频、元描述、元标签。
6、Beautiful Soup：名气大，整合了一些常用爬虫需求。它是一个可以从HTML或XML文件中提取数据的Python库。它能够通过你喜欢的转换器实现惯用的文档导航,查找,修改文档的方式.Beautiful Soup会帮你节省数小时甚至数天的工作时间。Beautiful Soup的缺点是不能加载JS。
7、mechanize：它的优点是可以加载JS。当然它也有缺点，比如文档严重缺失。不过通过官方的example以及人肉尝试的方法，还是勉强能用的。
8、selenium：这是一个调用浏览器的driver，通过这个库你可以直接调用浏览器完成某些操作，比如输入验证码。Selenium是自动化测试工具，它支持各种浏览器，包括 Chrome，Safari，Firefox等主流界面式浏览器，如果在这些浏览器里面安装一个 Selenium 的插件，可以方便地实现Web界面的测试. Selenium支持浏览器驱动。Selenium支持多种语言开发，比如 Java，C，Ruby等等，PhantomJS 用来渲染解析JS，Selenium 用来驱动以及与Python的对接，Python进行后期的处理。
9、cola：是一个分布式的爬虫框架，对于用户来说，只需编写几个特定的函数，而无需关注分布式运行的细节。任务会自动分配到多台机器上，整个过程对用户是透明的。项目整体设计有点糟，模块间耦合度较高。
10、PySpider：一个国人编写的强大的网络爬虫系统并带有强大的WebUI。采用Python语言编写，分布式架构，支持多种数据库后端，强大的WebUI支持脚本编辑器，任务监视器，项目管理器以及结果查看器。Python脚本控制，可以用任何你喜欢的html解析包。
以上就是分享的Python爬虫一般用的十大主流框架。这些框架的优缺点都不同，大家在使用的时候，可以根据具体场景选择合适的框架。