Scrapy与BeautifulSoup

Scrapeless Scraping Browser提供云浏览器执行，用于动态页面获取，适用于使用框架或解析器的Python抓取工作流。

Scrapy与BeautifulSoup主要是在框架与抓取栈的一个组件之间的比较。Scrapy协调爬取和提取。BeautifulSoup，正式命名为Beautiful Soup，为Python代码提供了方便的方式来搜索和导航解析的HTML或XML文档。

您可以在Scrapy应用程序内部使用BeautifulSoup，因此选择并不总是排他性的。首先决定您需要文档解析器、抓取生命周期，还是两者都有。这个问题产生的答案比简单声明某个工具在生产中更快或更合适要有用得多。

每种工具包含什么

Scrapy包括协调的请求处理和项目处理，而BeautifulSoup专注于提供给它的文档树。这是大多数实际权衡背后的主要区别。

BeautifulSoup的较小范围在您的应用程序已经处理获取和存储时可能是一个优势。当您否则需要自己构建这些协调层时，Scrapy的较大范围可能是一个优势。有用的比较是完整的建议栈，而不是每个包孤立。

Scrapy爬取如何在框架中移动

Scrapy爬取通过调度器和下载器移动请求，将响应发送给蜘蛛，并通过处理管道传递提取的项目。 Scrapy架构 使这些阶段明确，以便蜘蛛可以同时生成记录和额外请求。

这个结构适合目录，其中索引页面揭示类别，类别揭示详细页面，详细页面生成项目。该框架协调待处理请求，而您的蜘蛛描述特定于源的关系。共享验证或存储行为可以存在于单独页面回调之外。

框架结构仍然需要应用程序策略。定义允许的源、有效的URL模式和停止条件，然后跟随发现的链接。一个组织良好的爬虫如果其发现规则允许每个链接，仍然可以收集无关页面。它的架构使范围更容易集中，但并不为您选择范围。

Scrapy还具有设置和扩展点，成为项目维护表面的一部分。开发人员必须理解请求被修改的地方和项目被拒绝的地方。当多个蜘蛛受益于共享行为时，这种学习成本是合理的；对于狭窄的一文档任务可能是不必要的。

BeautifulSoup如何适应小型提取任务

BeautifulSoup适合Python已经有文档并需要可读提取规则的任务。 Beautiful Soup文档导航接口 与选定的解析器一起工作，并提供元素搜索、CSS 选择和树遍历。

对于通过现有应用下载的公共表格，BeautifulSoup 可以是一个小的补充：加载接受的标记，识别每一行，读取其单元格，并验证生成的字段。您不需要爬虫框架，仅仅因为输入最初来自网站。

周围的程序拥有其余部分。它必须获取文档，识别来源，决定如何表示失败，并编写已接受的记录。如果添加了更多页面，它还负责调度和去重，除非另一个框架提供这些功能。这种灵活性很有用，但在设计估算中应该保持可见。

指定解析器，而不是依赖于安装的任何依赖项。不同的解析器选择可以从格式错误的标记构建不同的树。从开发者的机器上可以正常工作的选择，可能在部署后表现出不同的行为，如果解析器配置发生变化。

选择器并不是一个完整的抓取架构

选择器质量影响两种方法中的提取准确性，但它并不能决定框架的选择。Scrapy的 CSS 和 XPath 选择器接口 提供了自己的提取接口。BeautifulSoup 提供了自己的搜索和遍历模型，并支持 CSS 选择。

首先找到代表一个实体的容器。阅读该容器内的标题和可选字段，以便缺失值不会影响记录之间的关联。这个规则比表达是通过 Scrapy 响应还是 BeautifulSoup 对象编写更为重要。

一个解析器可以忠实地处理错误的页面。访问通知可能具有满足广泛选择器的标题和段落。在接受提取值之前，请验证文档类型。一个标题和一些文本不足以证明收集者达到了请求的目录条目。

当爬虫协调证明Scrapy是合理的

当共享请求协调和项目处理成为重复需要时，Scrapy 变得具有吸引力。触发因素是工作流的复杂性，而不是一个普遍的页面计数阈值。一个适度的爬虫，具有几种页面类型和持久状态，可能需要比一个大型固定简单文档列表更多的协调。

Scrapy的 项目管道模型 在提取后，提供了验证、规范化、重复处理和持久化的明确位置。当许多爬虫生成的记录必须满足相同的输出合同时，这非常有用。

对于长时间运行的工作，Scrapy 可以通过配置的作业目录持久化合适的爬虫状态，并恢复一个干净停止的作业。此功能有要求和限制；这并不意味着每个任意的应用对象或外部会话将无限期保持有效。保持每个作业的状态分开，并测试您计划操作的实际暂停和恢复工作流程。

BeautifulSoup 可以参与同样精心设计的生产应用，但周围的系统必须提供这些协调责任。仅仅因为该库故意专注于解析而避免将其视为不适合生产。评估完整的服务及其运营所有权。

三个决策与现实工作负载的示例

合适的选择遵循工作的形状和已有的基础设施。以下场景是说明性选择示例，而不是经过衡量的基准。

在现有的 Python 作业中使用单个公共表

使用BeautifulSoup，当应用程序已经下载已知文档并需要将表格提取到现有管道中时。保持行模式明确，并正确保存缺失单元格。一个单独的爬虫可以添加概念，而不去除当前的维护负担。

一个包含类别和详细页面的目录

使用 Scrapy 当类别导致详细请求并且许多页面共享集合政策时。在爬虫中放置发现，在项目管道中集中常见验证，并区分重复请求与重复产品记录。这利用了框架的责任来证明其合理性。

一个成熟的 Scrapy 项目与一个复杂的 HTML 片段

在Scrapy回调中使用BeautifulSoup，如果其遍历接口使特定片段更容易解释。对于该片段，保持一条清晰的提取路径，而不是在没有必要的情况下通过多个接口解析相同的文档。现有的Scrapy调度和输出处理可以保持不变。

动态页面需要一个获取决策

普通的 Scrapy 下载或 BeautifulSoup 解析本身不会执行页面的 JavaScript。如果响应仅包含一个壳，替换一个提取接口为另一个将不会创建缺失的节点。在更换工具之前，请检查获得的表示。

无抓取的抓取浏览器 提供云浏览器执行，以满足依赖脚本或交互的源所需状态。 抓取浏览器服务介绍 解释了获取层。提取的文档可以通过您的Python应用程序选择的解析器和验证合约进行处理。

相关 BeautifulSoup 静态和动态提取演练 扩展了这种分离。请在您的成本估算中包括浏览器工作，使用 无抓取定价，并定义在提取开始之前必须存在的页面状态。

结论：将工具匹配到缺失的层级

选择BeautifulSoup当缺失的部分是可读文档的解析。选择Scrapy当缺失的部分是协调爬虫和共享项目处理。当某个特定解析任务在Scrapy生命周期内从BeautifulSoup中受益时，将它们结合使用，并将浏览器依赖的获取作为一个单独的要求处理。