Transcript
00:00:00这是 Scrapling，一个旨在解决网络爬虫最头疼问题的 Python 爬虫库。
00:00:05爬虫今天能用，网站一变就挂。改一个类名，
00:00:10移一个 div，加一个机器人检测，你的数据管道就瘫痪了。Scrapling 的核心理念是
00:00:17让你的爬虫能够自适应而不是直接崩溃。它在 GitHub 上拥有超过 53,000 个星标，
00:00:22支持自适应解析、隐身抓取以及更大规模的爬虫工作流。
00:00:27我打算测试一个最关键的问题。
00:00:30它能在不重写选择器的情况下应对网站变更吗？我们马上来揭晓。
00:00:40那么，什么是 Scrapling？Scrapling 是一个自适应的一站式 Python 网络爬虫框架。
00:00:46你拥有自愈解析器、隐身抓取器，在需要 JavaScript 时还有基于浏览器的抓取方式，
00:00:51以及用于大规模抓取的蜘蛛框架。一次安装，一个 API。这意味着更少的爬虫损坏，
00:00:57并能获得更多可用的数据。现在，让我们看看真正关键的部分。
00:01:03如果你喜欢通过代码工具来加速工作流程，请务必订阅。我们会不断推出新视频。
00:01:08现在，我这里有一个基础设置，对吧？我已经安装了 Scrapling，所以我们快速过一下。
00:01:13一次导入，一次调用，我们就拿到了页面。在上面，我创建了一些会改变的 HTML。
00:01:21一个是普通的起始页面。然后我保持内容不变，但切换了 CSS 选择器。
00:01:27假设我想获取产品名称和价格。通常，我可能会用 CSS 选择器来抓取它们，
00:01:34对吧？所以使用 page CSS，填入选择器，设置 auto-save 为 true。我可以这样做，
00:01:40它就能工作，我们会得到一个数据字典。看起来很正常。两个选择器，一个字典，
00:01:46我继续进行下一步。就是这样。但同时，这实际上是个问题，因为普通的爬虫在
00:01:52页面变更前运行良好。现在，如果网站在一夜之间随机发生变化呢？他们重新设计了它。
00:01:58他们做了一些调整来防止这种情况。比如产品标题变成了 item heading，或者产品价格变成了
00:02:04pricing value。页面上有同样的数据，但整个 DOM 结构改变了。旧的选择器应该
00:02:11已经失效了。这就是大多数爬虫崩溃的地方。但现在我们可以开启自适应模式。
00:02:18只需将 autosave 等于 true 改为 adaptive 等于 true。现在我仍然可以把产品标题
00:02:26设置 adaptive 为 true。数据是一样的。我没有更改选择器。页面结构变了，却
00:02:34不需要重写选择器。这就是这里的主要思想。当你以 autosave 为 true 抓取元素时，
00:02:40Scrapling 会记录关于它的线索。所以它会记录标签、属性、
00:02:44父子节点、邻近文本，可能还有 DOM 位置和结构形状。所以当
00:02:50类名改变时，Scrapling 还有很多剩下的线索。它不需要整个网站保持不变。
00:02:56它只需要足够的结构信号来再次识别该元素。这就是
00:03:01最重要的地方，因为真正的爬虫故障几乎从来不是完全重设计。通常是一个重命名的类，
00:03:06一个新的包装器，一个移动的布局，一件小事。这正是自适应匹配所针对的。
00:03:13Scrapling 有三个重要的核心组件。第一是刚才看到的自适应解析器。
00:03:18然后是多功能抓取器，单一工作流，适合各种任务。抓取器支持普通 HTTP，
00:03:25快速处理简单页面。隐身抓取器可以在需要时绕过反爬虫机制。动态抓取器是针对
00:03:32重 JavaScript 站点的真实浏览器。一个 API，切换抓取器，保持代码不变。当快速
00:03:39脚本变成真正的爬虫时，蜘蛛框架就派上用场了。异步爬取、暂停和恢复、代理轮转、流式传输，以及所有这些
00:03:46混合会话。那些你通常后期添加的功能，它都已经具备了。Scrapling 不仅仅是另一个
00:03:53解析器。它用单一工作流取代了整个抓取技术栈：Requests、BeautifulSoup、Playwright、重试逻辑、代理助手、
00:04:00蜘蛛代码。Scrapling 并不是说 BeautifulSoup 没用，也不是说
00:04:06Playwright 或 Scrapy 已经过时了。BeautifulSoup 加 Requests 对于简单页面仍然非常棒。它简单，
00:04:13易读，每个人都懂，但它不提供任何隐身能力。它不提供
00:04:20自适应选择器，也不能渲染 JavaScript。对于大型解析任务，它可能
00:04:26成为真正的瓶颈。而 Scrapy 很强大。如果你正在构建严肃的爬取
00:04:31基础设施，Scrapy 仍然值得尊重，但 Scrapy 往往意味着设置、管道、中间件、
00:04:36扩展程序以及大量的设置工作。Playwright 和 Selenium 在你需要真实浏览器时很棒。
00:04:42有时页面确实需要 JavaScript。没别的办法。但浏览器很沉重。它们
00:04:48比纯 HTTP 慢，而且占用更多内存。再说一次，它们仍然无法解决选择器损坏的
00:04:54问题。它们运行页面，但不理解你的爬虫意图。所以有了 Scrapling，
00:05:01你可以在可能的情况下使用快速抓取，需要时使用隐身抓取，在页面
00:05:06需要时使用浏览器渲染，并使用自适应解析。这样前端的一点小改动就不会搞垮一切。不过，这一切
00:05:12并不意味着 Scrapling 没有问题。如果你面对的是 DOM 级别的数据保护、
00:05:17高级指纹识别或激进的速率限制，你可能仍然需要高质量的代理。所以 Scrapling 可以
00:05:23提供帮助，但它不会让你隐身。动态抓取也可能意味着额外的浏览器设置。这就是
00:05:29涉及 JavaScript 渲染时的权衡。以下是关于这一切的一些思考。
00:05:34如果你做真实的爬虫工作，尤其是构建数据管道、
00:05:41有 RAG 任务、AI 代理或任何需要在目标网站变更后持续运行的任务，Scrapling 都值得尝试。使用它的
00:05:47最强理由不是因为它让抓取成为可能。我们已经有了能够做到这一点的工具，对吧？
00:05:53最强理由是它降低了维护成本。当然，如果是非常微小的脚本，
00:05:59我可能会跳过它，Requests 和 BeautifulSoup 就足够了，对吧？
00:06:04如果你喜欢这类编程工具，请务必订阅 BetterStack 频道。我们下个视频见。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video