屏幕抓取是指读取应用程序渲染输出中的数据,即人类在屏幕上看到的像素和文字,并将其转移到别处。它不是通过有文档记录的接口向系统请求数据,而是以人类读取数据的方式获取数据:从显示屏上读取。这听起来很原始,从某种意义上说确实如此。但它也仍然是从许多没有其他接口的系统中获取数据的唯一方式。
本文解释了屏幕抓取的实际含义,它与网络抓取和通过 API 获取数据的区别,以及当"屏幕"是终端、旧版桌面应用或现代渲染网页时,它在实践中如何工作。我们将介绍它真正能发挥作用的场景(旧版系统、金融和数据迁移),它的缺陷,以及如何负责任地执行。
什么是屏幕抓取?
屏幕抓取是收集一个应用程序的显示输出并将其传输到另一个应用程序的过程。抓取程序读取可见内容(出现在用户界面中的原始文本和值),并将其解析为自己的结构化模型,供第二个系统使用。
其决定性特征是屏幕抓取从呈现层工作。它不要求源系统提供干净的导出文件,也不查询其数据库。它获取屏幕上显示的任何内容(终端窗口中的字符、桌面表单中的字段、浏览器中的文本和表格),并从这个表面重建底层数据。源应用程序通常不知道自己正在被这样读取,因为从它的角度来看,没有发生任何异常:它只是绘制了其正常的屏幕。
历史上,这个术语来自字面意义上的那个动作。几十年前,程序直接从大型机终端的屏幕缓冲区中读取字符单元,以捕获绿屏应用程序显示的内容。目标已经改变,但理念没有:当系统只向你展示一个渲染好的显示屏时,你就抓取这个显示屏。
屏幕抓取与网络抓取的对比
人们将"屏幕抓取"和"网络抓取"互换使用,它们确实有重叠,但并非同一回事。区分两者最清晰的方式是看各自读取的是什么。
网络抓取读取结构。它针对网页的标记语言(HTML、DOM、单个元素)工作,通过定位来提取特定字段:一个元素内的价格、另一个元素中的产品标题、链接列表、页面正文中的电子邮件地址。它关心的是页面的底层源代码,而不仅仅是其外观。我们在此博客上涵盖的大部分内容,从XPath 和 CSS 选择器到使用 BeautifulSoup 解析 HTML,都是这个意义上的网络抓取。
屏幕抓取读取输出。它捕获渲染结果(屏幕显示的视觉数据),并适用于完全没有有用标记语言的源:终端、桌面窗口、扁平化报告、页面图片。当目标是网页时,两者会模糊重叠,因为渲染后的浏览器屏幕同时也是一个 HTML 文档。但视角不同。网络抓取问的是"哪个元素包含这个值?"屏幕抓取问的是"屏幕显示什么,我如何将其读回数据?"
| 维度 | 屏幕抓取 | 网络抓取 |
|---|---|---|
| 读取来源 | 渲染后的显示(UI、终端、图像) | 页面的源标记(HTML/DOM) |
| 典型来源 | 旧版应用、大型机、桌面 UI、网页 | 网站和 Web 应用 |
| 目标 | 屏幕上显示的任何内容,包括图表和视觉元素 | 通过选择器定位的特定元素和字段 |
| 通常需要 | 从表面进行 OCR 或文本捕获 | HTML 解析器和选择器 |
| 在何时失效 | 布局或屏幕位置改变时 | 标记或元素结构改变时 |
简而言之:每次对渲染页面的网络抓取都是某种形式的屏幕抓取,但大量屏幕抓取与网络完全无关。
屏幕抓取与 API 访问的对比
如果说屏幕抓取是从显示屏上读取数据,那么 API 访问则恰恰相反:直接向系统请求其数据。API(应用程序编程接口)是系统有意暴露的有文档记录的端点,以 JSON 等格式返回干净、结构化的数据,字段稳定,并有告知你期望什么内容的约定。
当 API 存在时,它几乎总是优于屏幕抓取。数据已经是结构化的,你无需猜测布局,提供者已经告诉你格式将保持一致。相比之下,屏幕抓取很脆弱:它取决于屏幕恰好如何排列,因此一次外观重设计或移动一列都可能在一夜之间破坏一个正在运行的集成。
屏幕抓取之所以持续存在,原因很简单。许多系统没有 API,或者没有你被允许使用的 API。一个 30 年历史的大型机应用、一个没人愿意重建的内部工具、一个只渲染网页的供应商门户:这些只暴露一个屏幕,别无其他。当系统提供的唯一接口就是其显示屏时,读取该显示屏不是一种取巧手段,而是集成方式。屏幕抓取正是在更简洁的门不存在时才会派上用场。
屏幕抓取的工作原理
无论目标如何渲染,屏幕抓取都遵循相同的大致流程:将屏幕呈现在你面前,捕获它所显示的内容,将该捕获内容转换为结构化数据,然后交给下一个系统。具体机制因来源而异。
读取旧版和终端屏幕
对于大型机和终端应用,工具以原始客户端的方式连接(通常通过终端协议),并读取填满屏幕字符网格的文本。由于数据已经是固定位置排列的文本,抓取器可以映射屏幕的已知区域("账号位于第 6 行,第 12 至 23 列"),并按位置提取每个字段。这种方式刚性有余,但只要屏幕布局不变,就是可靠的。
读取桌面 UI
对于桌面应用,抓取器从屏幕上的 UI 元素中读取值:文本框的内容、标签、网格单元格。如果值可以直接以文本形式读取,这就足够了。如果不能(例如,数据嵌入在图像或自定义绘制控件中),工具会将该区域捕获为图片,然后对其运行 OCR。
读取现代 Web 屏幕
对于现代网页,"屏幕"是浏览器在加载 HTML 并运行页面 JavaScript 后渲染的内容。这一点很重要:当今大量网站在浏览器中构建其可见内容,因此通过普通请求获得的原始 HTML 几乎是空的,真实数据只有在页面渲染后才会出现。要抓取这个屏幕,你需要像浏览器一样渲染页面,然后读取结果。这与爬取 JavaScript 密集型网站是同一个问题,也是为什么真实的浏览器引擎(无头或其他形式)成为现代 Web 屏幕抓取中心的原因。
OCR:将像素还原为文本
当数据只以图像形式存在(扫描表单、图表、截图)时,光学字符识别(OCR)完成转换工作。OCR 读取图像中字符的形状并返回机器可读文本,抓取器随后可以解析和存储这些文本。OCR 是让屏幕抓取能够处理真正没有任何底层文本可以抓取的来源(只有文字图片)的桥梁。
一旦数据被捕获和解析,最后一步是将其写入可用格式:电子表格、JSON 负载、数据库行、PDF,或接收系统所期望的任何格式。这种交接,从别人的显示屏到你的结构化存储,正是整个工作的意义所在。
当你需要读取的屏幕是现代网页时,难点在于让它可靠地渲染而不被封锁。Crawling API 在真实浏览器中加载页面,运行其 JavaScript,轮换 IP,并清除 CAPTCHA,然后返回完整渲染的结果,让你可以像真实访客所见那样抓取屏幕,而无需自己构建和维护浏览器基础设施。
屏幕抓取的用途
屏幕抓取出现在数据被锁在显示屏后面且没有更简洁出路的地方。以下几种模式占了实际使用的大多数。
旧版系统与现代化
这是屏幕抓取的主场。公司在使用过时技术构建的旧版应用中运行关键信息,包括大型机终端、老旧桌面工具、原始开发人员早已离去的系统。其中的数据仍然驱动着日常运营,但没有 API 也没有导出功能。屏幕抓取读取这些旧版屏幕并将其数据传输到现代界面,让新的前端或服务能够使用旧数据,无需任何人重写原始系统。这通常是无法改变的系统与需要其数据的软件之间唯一可行的桥梁。
金融与银行
当账户数据存在于门户而非开放 API 背后时,金融服务依赖屏幕抓取。在客户明确许可和提供凭据的情况下,聚合工具可以登录银行网站,从屏幕上读取显示的余额和交易,并将其提取到预算应用、会计系统或贷款机构的审批流程中。这种账户聚合模式在开放银行 API 出现之前支撑了一代金融科技,现在仍在填补这些 API 尚未覆盖的空白。这里不可或缺的是同意:这一切的发生是因为账户持有人授权了这些操作。
数据迁移与网站转换
当企业迁离旧平台时,数据也必须跟着迁移。如果源系统无法干净地导出,屏幕抓取直接从其界面读取记录,以便将其加载到新系统中。网站转换同理:将内容从一个过时、庞大的网站迁移到现代布局,当抓取器导出旧页面显示的内容而不是让人重新输入时,速度会快得多。屏幕抓取将脆弱的手动迁移变成了可重复的过程。
聚合与价格比较
比较网站和数据聚合商从许多来源读取相同类型的值,并将其并排展示。例如,价格比较服务读取特定产品在多个零售商处显示的价格,让买家(或处理大批量库存的中间商)看到谁的价格最低。当这些来源是现代网络商店时,这已进入电商网络抓取领域,而一个返回解析后字段的结构化端点可以省去你手动解析每个零售商布局的工作。
屏幕抓取的优势
对于适合它的情况,屏幕抓取提供了一些具体的优势。
- 在其他方法都不起作用时,它有效。最大的单一优势是覆盖范围:它从没有 API 也没有导出的系统中获取数据。对于旧版应用,这意味着使用数据还是根本没有数据的区别。
- 上手快。由于它读取现有界面,你不需要源系统的所有者为你构建任何东西。你将抓取器指向屏幕并开始收集,这通常比委托开发新集成快得多。
- 成本效益高。抓取脚本或托管抓取 API 可以完成原本需要手动数据输入或自定义集成项目才能完成的工作,以极低的成本自动化重复性传输。
- 准确且一致。自动捕获每次以相同方式读取相同字段,消除了手动重新输入时产生的拼写错误和重复项,并在大量数据中保持数据质量稳定。
- 扩展单调的工作。一旦定义好屏幕抓取流程,它就可以在无人监督的情况下跨多条记录或多个页面运行,让人们从重复的复制粘贴中解放出来。
局限性与风险
屏幕抓取确实有用,但它是在更好的选项缺失时才会求助的选项,并且有真实的缺点值得说明。
它很脆弱。由于它依赖显示屏的布局,屏幕抓取会在显示屏改变时失效。移动一个字段、重新设计一个页面、重新排列终端屏幕,一个正在运行的抓取器就可能开始返回错误数据而没有任何报错。任何读取渲染表面的工具都继承了这种脆弱性,这就是为什么屏幕抓取集成需要持续维护,而稳定的 API 则不需要。
OCR 并不完美。当你依赖 OCR 从图像中读取值时,你就继承了它的错误率。低质量图像、不常见字体和拥挤的布局都会产生误读,因此任何基于 OCR 的流程都需要验证,而不能盲目信任输出。
现代 Web 目标会反击。抓取当代网站的屏幕意味着要面对每个抓取器都会遇到的相同防御:机器人检测、基于 IP 的速率限制和 CAPTCHA。简单的抓取器会迅速被封锁,这就是为什么当屏幕是网页时,强大的 IP 轮换和真实的渲染引擎如此重要。
敏感数据提高了风险。许多屏幕抓取用例(尤其是金融领域)涉及个人或机密信息。这使得同意、安全和谨慎处理不是可选的礼貌,而是正确执行的核心。
负责任地抓取
无论什么屏幕,都要谨慎抓取。遵守每个来源的服务条款和 robots.txt,将自己限定在你有权访问的数据范围内,这意味着公开信息,或者如银行案例中那样,账户所有者已明确许可你代表他们读取的数据。保持合理的请求速率,以免降低你所依赖的服务质量,并以其应有的安全标准处理你捕获的任何个人或金融数据。负责任的屏幕抓取与其说是关于巧妙的变通方法,不如说是在来源设定的边界内运作。
核心要点
- 屏幕抓取读取显示屏。它捕获应用程序的渲染输出(UI、终端、图像),并将其转换回供其他系统使用的结构化数据。
- 它与网络抓取的区别在于读取的内容。网络抓取针对页面的标记语言和元素;屏幕抓取读取可见表面,包括完全没有有用标记语言的来源。
- 当 API 存在时,它优于屏幕抓取。API 有意返回干净、稳定、结构化的数据;屏幕抓取是在没有这样的接口时使用的。
- 其优势在于覆盖范围、速度和成本。它从旧版和金融系统中获取数据,驱动数据迁移,并以低成本准确地自动化重复性传输。
- 其弱点是脆弱性。布局变化、OCR 错误和反机器人防御都会威胁到它,因此要负责任地抓取,并在来源的条款范围内进行。
常见问题
屏幕抓取和网络抓取是一回事吗?
不完全是。网络抓取从页面的 HTML 结构中提取特定字段,而屏幕抓取读取渲染后的显示屏本身,适用于网络以外的来源,如终端和桌面应用。当目标是网页时,两者重叠很大,因为渲染后的浏览器屏幕同时也是一个 HTML 文档,但屏幕抓取是从表面读取数据这一更广泛理念。
为什么使用屏幕抓取而不是 API?
主要是因为没有可用的 API。旧版大型机、老旧桌面工具和许多供应商门户只暴露一个屏幕,因此读取该屏幕是获取其数据的唯一方式。当有文档记录的 API 可用时,它几乎总是更好的选择,因为它返回的结构化数据不会在每次界面重设计时就失效。
屏幕抓取需要 OCR 吗?
只有当数据仅以图像形式存在时才需要。如果屏幕上的值可以作为文本读取(终端字符、网页内容、UI 字段),你可以直接解析文本。当你必须从图片中恢复文本时,OCR 才会介入,比如扫描表单、图表或没有底层文本层的截图。
屏幕抓取在 2026 年还有意义吗?
有。API 已经取代了许多集成,但大量关键数据仍然存在于没有其他接口的旧版系统中,现代网站仍然需要像屏幕一样被渲染和读取。只要系统仅通过显示屏暴露数据,屏幕抓取就仍然是通往它的实用桥梁。
如何在不被封锁的情况下对现代网站进行屏幕抓取?
你需要在真实浏览器中渲染页面以让其 JavaScript 运行,并且需要看起来像真正的访客:轮换住宅 IP、合理的请求速率和 CAPTCHA 处理。自己构建这一切很复杂,这就是为什么许多团队使用Crawling API 等托管服务来获取渲染后的页面,或者在需要自动解析字段时使用Crawling API。
屏幕抓取合法吗?
取决于你抓取的内容和方式。在网站服务条款和 robots.txt 范围内以合理速率读取公开数据,或者所有者已明确授权你访问的数据,这是负责任的基准。敏感和个人数据(尤其是金融数据)需要同意和谨慎处理,因此在开始之前请查看来源的条款和你的义务。
大规模爬取任何站点,无需与基础设施对抗。
Crawlbase 负责处理代理、指纹和 CAPTCHA,让你的团队专注于交付数据流水线,而非维护爬取管道。1,000 次请求免费,无需信用卡。
