用 Python 爬取 Bing：抓取 Bing 搜索结果的完整指南
抓取 Bing 是指用代码从 Bing 的搜索结果页面中提取结构化数据,而不是手动复制。开发者抓取 Bing 是为了跟踪排名、监控竞争对手、构建研究数据集,或用新鲜的搜索数据为内容管道提供支持。
与 Google 相比，Bing 也友好得多。它的 HTML 更可预测，反爬虫系统没那么激进，分页也极其简单。这使它成为在挑战更难目标之前学习抓取基础知识的绝佳起点。
读完本指南，你将拥有一个可用的 Python 抓取器，它能够发送请求、解析结果、遍历多个页面、处理错误，并将干净的数据导出为 CSV 或 JSON。我们还将介绍如何 代理 一旦你不再只是运行几条测试查询，就能融入正式的抓取方案中。
什么是 Bing 抓取？
每次你在 Bing 上搜索时，服务器都会返回一个完整的 HTML 页面。这个页面被称为 SERP，即搜索引擎结果页（search engine results page）的缩写。抓取 Bing 意味着以编程方式发送同样的请求，并从原始 HTML 中提取结构化数据。
获取该数据有两种方式：
- HTML 抓取
自己请求页面，解析标记，提取你需要的内容。
- APIs
使用一项返回结构化 JSON 而非 HTML 的服务，这样你就能完全跳过解析步骤。
本指南聚焦于 HTML 抓取,因为它让你拥有完全的控制权,除了你自己的基础设施之外无需任何成本。 以下是基本流程：
典型的使用场景包括排名跟踪、 SEO 竞争对手研究、市场情报、新闻监测、 SERP 抓取 以及为 NLP 项目构建训练数据。
为什么抓取 Bing 而不是 Google?
Google 备受关注，但对于抓取项目来说，Bing 往往是更实用的目标。它仍占据着相当可观的搜索流量份额，而且它的结果页面处理起来要容易得多。
| 因素 | Bing | |
| HTML 结构 | 简单且一致的类名 | 经常被混淆和压缩的类名 |
| 反机器人防护 | 具有速率限制的中等防护 | 采用 JavaScript 挑战和 CAPTCHA 的强力防护 |
| SERP 稳定性 | 布局很少发生变化 | 布局经常变化，可能会导致选择器失效 |
| 购物结果 | 可通过标准 HTML 访问 | 通常需要专用的 API 或额外的渲染 |
| 图片结果 | 易于从 HTML 响应中解析 | 经常通过 JavaScript 动态加载 |
| 新闻结果 | 可在标准页面标记中获取 | 通常嵌入在动态小部件内部 |
这些都不意味着 Bing 毫无防护。它仍然会对激进的流量进行限速，并封锁明显的机器人行为模式。但入门门槛更低，这使它成为大多数项目更好的起点。
你可以从 Bing 抓取哪些数据？
一个标准的 Bing SERP 不仅仅包含蓝色链接。根据查询的不同，你可以抓取到：
- 自然搜索结果的标题
- 指向来源页面的 URL
- 摘要，即每条结果下方的简短描述
- 来自图片搜索或内嵌图片轮播的图片
- 购物商品，包括价格以及商家（如果存在的话）
- 新闻文章,附带来源和时间戳
- 相关搜索，对关键词扩展很有用
并非每个字段都会出现在每个 SERP 上。本地商家查询拉取的数据与商品查询不同，因此你的解析器应当优雅地处理缺失字段，而不是抛出错误。
这也是为什么从 Bing 搜索中抓取数据非常适合竞争对手研究的原因。一次查询就可以同时返回自然搜索结果、相关搜索，有时还包括购物或新闻内容。
抓取 Bing 合法吗？
几乎每个抓取项目都会遇到这个问题,而诚实的答案是:这取决于你如何操作。
抓取任何人无需登录即可查看的公开页面，在大多数司法管辖区通常被视为合法。各国法律各不相同，本文不构成法律意见。你可以在我们的以下内容中获取有关该主题的更多信息 关于抓取合法性的博客文章.
有几点需要记住：
- 检查 robots.txt。 它表明了网站所有者的偏好，即便在某些地方它并不具有法律约束力。
- 遵守速率限制。 无论你在收集什么数据，用大量请求猛烈冲击服务器都可能构成滥用。
- 阅读服务条款。 Bing 的条款限制某些自动化访问，因此大规模商用应谨慎处理。
- 负责任地抓取。 添加延迟，避免服务器过载，并且绝不抓取个人数据或需要授权访问的数据。
如果你的项目以任何实际规模进行抓取，或为商业产品提供数据支持，请咨询一位熟悉你所在地区数据采集法律的律师。
要求
你只需要少数几个库就能让抓取工具正常运行。
- requests 库 用于发送 HTTP 请求
- beautifulsoup4 用于解析 HTML
- pandas 用于组织和导出数据
- lxml 作为 BeautifulSoup 更快的解析器后端
- 可选： selenium 如果你需要渲染大量依赖 JavaScript 的页面
核心设置到此就完成了。等我们进入扩展阶段后，再添加代理支持。
如何用 Python 抓取 Bing 搜索结果
以下是我们要逐步构建的完整工作流程：创建会话、发送带有正确请求头的请求、解析结果、遍历各个页面，并将所有内容导出到文件。每一步都建立在上一步的基础之上。
创建一个 requests 会话
会话对象会在多次请求之间复用底层的 TCP 连接，这比每次都发起独立的 requests.get() 调用要快速、真实得多。
设置真实的 User-Agent 和 Accept-Language 请求头很重要。缺少这些请求头的请求看起来明显是自动化的,会更快被标记。
发送请求
用超时和异常处理包裹每一个请求。生产环境中的抓取工具会不断因网络错误而失败，你的代码需要能够扛住这些情况。
注意重试之间采用了指数退避。固定延迟用于测试没问题，但要扩大规模，就需要让延迟随着每次失败尝试而增长。
解析搜索结果
Bing 会将每条自然搜索结果放在结构固定的容器元素中，因此用 BeautifulSoup 提取标题、URL 和摘要非常简单。
始终要防范缺失的元素。Bing 偶尔会渲染出没有摘要的结果，而一个假设每个字段都存在的脚本会在遇到第一个边缘情况时崩溃。
处理分页
Bing 通过一个名为的查询参数进行分页 首先。第一页完全没有参数，第二页从 11 开始，第三页从 21 开始，以此类推，每次递增 10。
这里两个空页面的规则很重要。Bing 偶尔会在一组结果中间返回一个内容稀薄或空白的页面，如果仅仅在遇到第一个空页面时就停止，就会导致你的数据被截断而不完整。
将结果导出为 CSV
当你有了一个字典列表之后， pandas 一行代码就能把它转换成一个干净的文件。
在这里按 URL 去重是值得做的，因为相互重叠的页面有时会把同一条结果返回两次。
高级 Bing 抓取技巧
一个在测试中能处理十个查询的抓取工具，在生产环境中处理一千个查询时往往会崩溃。这些技巧正是为了弥合这一差距。
- 重试逻辑
已内置于 fetch_page 如上所述,但要根据每个查询的重要程度来调整重试次数。
- 指数退避
每次失败后将延迟加倍或加三倍，可以避免你继续猛烈冲击一个已经在对你限速的服务器。
- 轮换 User Agent
循环使用一组逼真的浏览器字符串，可以让流量看起来不那么单一。
- 持久会话
复用一个 requests.Session() 每个工作线程复用连接，而不是不断创建新连接。
- 随机延迟
请求之间固定的延迟本身就是一种指纹。请在一个区间内对其进行随机化。
- 结构化日志记录
记录每一次失败，并附上足够的上下文，以便日后调试时无需重新运行整个任务。
这些技巧单靠自身都无法永远奏效。一旦你每天运行成百上千次查询，真正的瓶颈就会变成你的 IP 地址，而不是你的代码。
Bing 搜索 API 与 HTML 抓取对比
Microsoft 过去曾提供官方的 Bing Search API，但其可用性和定价随时间发生过变化，因此在将其用于生产项目之前，值得先核实一下当前的条款。
| 因素 | 官方 API | HTML 抓取 |
| 数据格式 | 干净的 JSON 响应 | 需要解析的原始 HTML |
| 成本 | 按请求计费 | 仅需基础设施成本,例如代理和服务器 |
| 可靠性 | 稳定的 API 契约 | 当 Bing 更改其页面标记时可能会失效 |
| 数据深度 | 仅限于有文档记录的字段 | 可以访问页面上任何可见的内容 |
| 速率限制 | 由你的 API 套餐决定 | 由 Bing 的机器人检测系统决定 |
| 设置时间 | 快速,只需调用端点即可 | 速度较慢，因为你需要构建并维护一个解析器 |
当你需要少量且可预测的查询量，又不想维护解析代码时，使用官方 API。当你需要 API 未提供的数据字段，或抓取量大到 API 费用迅速累积时，使用 HTML 抓取。
大多数寻找 Bing 搜索抓取 API 的团队最终都会在某个阶段两种方式都尝试一遍。API 设置起来更快，而一旦你需要 API 未涵盖的字段，或者你的查询量很大导致按请求计费变得昂贵时，HTML 抓取就更胜一筹。
常见挑战
每个 Bing 抓取工具最终都会遇到这同样的几个问题。
- 403 Forbidden
通常意味着你的请求头看起来像是自动化程序发出的，或者你的 IP 已经被标记了。
- 429 请求过多
你发送请求的速度超过了 Bing 对该 IP 允许的限速。
- CAPTCHAs
当 Bing 确信某个请求是自动化发起时，就会显示这些验证。放慢速度并轮换 IP 可以减少你遇到它们的频率。
- IP 封禁
来自同一个 IP 的反复激进请求，可能会导致该 IP 被封锁数小时甚至更久。
- 地域限制
某些 SERP 功能，比如本地结果或特定地区的新闻，只有当请求来自该地区时才会显示。
- HTML 变更
Bing 会定期更新其标记。今天有效的选择器，下个月可能会悄无声息地返回空结果。
这些问题大多归结于一个根本原因：来自过少 IP 地址的请求过多，发送速度过快，且缺乏足够的变化来让请求看起来像真人。
使用住宅代理进行 Bing 抓取
一旦你的抓取工具需要每天运行、覆盖多个地区或处理庞大的关键词列表，单个 IP 地址就会成为瓶颈。这正是代理发挥作用的地方。
住宅代理 通过真实的 ISP 分配的 IP 地址路由你的请求，而不是使用容易被标记的数据中心 IP 段。这对抓取来说很重要，因为搜索引擎对数据中心流量的怀疑程度要高得多。
有几个值得理解的概念：
- 轮换代理 为每个请求分配一个新的 IP，从而自动将流量分散到一个庞大的 IP 池中。
- 粘性会话会在设定的时间段内保持相同的 IP，当你需要让分页请求在同一次搜索会话中保持一致时非常有用。
- 地理定位功能让你可以请求来自特定国家或城市的 IP，从而精准抓取特定地区的 SERP。
- IP 信誉会影响你遇到 CAPTCHA 的频率。干净的住宅 IP 通常比反复使用的数据中心 IP 被标记的概率要低得多。
这正是像 NodeMaven 如何融入到工作流程中。NodeMaven 提供带有粘性会话和城市级地理定位的住宅代理，这正好涵盖了搜索引擎抓取最关键的两件事：看起来像真实流量，以及精确控制流量看起来来自哪里。
以下是代理支持如何接入我们已经构建好的抓取工具：
最佳实践
- 在将 Bing 抓取工具投入生产环境之前，先做一份快速检查清单：
- 为每个请求设置真实可信的 User-Agent 和 Accept-Language
- 始终设置超时，绝不要让请求无限期挂起
- 添加带指数退避的重试逻辑
- 随机设置请求之间的延迟，而不要使用固定的休眠时间
- 在一个小而真实的池中轮换 User Agent
- 一旦查询量超过每天寥寥几次，就改用住宅代理
- 在导出之前按 URL 对结果进行去重
- 记录足够详细的失败日志，以便无需重新运行任务即可调试
- 检查 robots.txt 并将请求频率保持在合理范围内
- 妥善处理缺失字段，而不是假设每条结果的结构都完全一致
常见问题
结论
用 Python 抓取 Bing 搜索结果归结为几个核心部分:正确配置的会话、对结果标记的仔细解析、可靠的分页处理,以及围绕这一切的稳健错误处理。Bing 可预测的结构使它成为一个适合培养这些技能的宽容平台。
本指南中的代码是构建一个可用抓取器的坚实基础，而不仅仅是一个玩具示例。随着你的查询量增长，主要的制约因素将从解析逻辑转移到你的 IP 信誉上，而这正是 住宅代理 以及合理的速率限制开始变得最为重要。
