Cheerio 安全政策与威胁边界从漏洞报告流程到解析库的安全承诺【免费下载链接】cheerioThe fast, flexible, and elegant library for parsing and manipulating HTML and XML.项目地址: https://gitcode.com/gh_mirrors/ch/cheerio导读本文以 Cheerio 官方安全政策文档 SECURITY.md 为主体系统梳理该 HTML/XML 解析库的版本支持范围、漏洞报告流程、安全关注点与责任边界并结合仓库内 THREAT_MODEL.md、INCIDENT_RESPONSE.md 及核心源码回答三个实际问题哪些版本会收到安全更新、如何私下报告漏洞、哪些问题属于 Cheerio 的安全职责而哪些属于使用方义务。读完本文你将掌握围绕 Cheerio 制定漏洞响应预案、评估解析类依赖安全风险所需的完整信息。支持的版本范围只有 1.x 分支收到安全更新Cheerio 在 SECURITY.md 中明确划分了受支持与不受支持的版本VersionSupported1.x✅ Yes 1.0❌ No政策原文强调只有1.x分支的最新发布版本会收到安全更新。如果你在使用更早的主版本官方建议直接升级而不是期待旧版本获得补丁。这一点在仓库的 package.json 中也可以得到印证——当前仓库版本为1.2.0正处于受支持区间同时engines字段要求 Node.js 22.19.0package.json实际部署时也应关注运行时版本是否在官方维护范围内。对于依赖方而言这一小节的政策含义是安全更新只会落在 1.x 的最新发布上升级策略应始终指向当前最新版而不是能用就不动。漏洞报告流程不走公开 issue走私下渠道禁止公开渠道SECURITY.md 的第一条硬性规定是请勿为安全漏洞开启公开的 GitHub issue。公开讨论会让漏洞细节在修复完成前曝光增加被恶意利用的风险。两个官方报告渠道首选渠道——Tidelift 安全联系渠道Cheerio 通过 Tidelift 协调修复与披露SECURITY.md。Tidelift 会负责在维护者与报告者之间协调补丁开发与公开披露的时间点。备选渠道——GitHub 私有漏洞报告如果 Tidelift 未及时响应可以通过 GitHub 的私有安全公告Security Advisory渠道提交SECURITY.md该渠道同样保证报告在修复期间保持机密。报告中应包含的信息为了提高漏洞确认与修复效率官方要求报告尽量提供以下内容SECURITY.md漏洞描述及其潜在影响复现步骤或概念验证PoC受影响的 Cheerio 版本相关配置细节你建议的严重级别Critical / High / Medium / Low这五项信息与 INCIDENT_RESPONSE.md 中分级响应表的输入直接对应——报告里给出的严重级别和受影响版本正是维护者进行 Triage 时最先核对的字段。提交后的处理时间线报告提交后维护者承诺按以下流程处理SECURITY.md确认Acknowledgment——72 小时内确认收到报告分诊Triage——评估严重性、影响范围与受影响版本修复与发布Fix Release——开发、测试并发布补丁披露Disclosure——发布 GitHub Security Advisory 公开详情并除非你选择匿名将报告者列入致谢。官方同时请求报告者在问题修复前给予合理的保密时间不要抢先公开。需要说明的是INCIDENT_RESPONSE.md 特别强调这些是志愿者维护的开源项目给出的善意响应目标而非 SLA 承诺。安全关注范围Cheerio 关心什么Cheerio 是面向 Node.js 的 HTML/XML 解析与操纵库package.json因此其安全关注点集中在解析不可信标记这条攻击面上。SECURITY.md 列出了五类官方特别关注的问题拒绝服务Denial of service——精心构造的输入导致内存或 CPU 消耗失控例如 ReDoS正则灾难性回溯、二次方复杂度的解析行为原型污染Prototype pollution——通过解析内容或 API 误用修改Object.prototypeXSS 助长XSS enablement——Cheerio 的输出在浏览器上下文中渲染时意外引入 XSS 的路径供应链Supply chain——被攻陷的依赖、构建管道或发布产物信息泄露Information disclosure——通过解析或序列化行为无意泄露数据。威胁模型中的范围内定义THREAT_MODEL.md 对以上范围做了更细的界定并补充了意外代码执行一类任何使解析或序列化路径触发eval、Function或等价执行攻击者提供内容的场景都被视为安全漏洞。同时文档明确说明Cheerio 不是净化器序列化器产出比输入更危险的输出例如错误转义导致的属性注入才属于 XSS enablement 漏洞范畴。信任边界什么不可信什么可信THREAT_MODEL.md 给出了清晰的信任边界划分不可信攻击者可控所有输入标记——传给load()、loadBuffer()、流式 API 或.html(content)、.append(content)等操纵方法的任意 HTML/XML 字符串来自外部来源的 CSS 选择器——由用户输入衍生的选择器可能触发选择器引擎的病态回溯。可信JavaScript 运行时——假设 Node.js 或兼容运行时未被篡改调用方应用代码——库的职责到输出为止调用方负责如何处理输出如在浏览器渲染前净化包完整性——假设安装的cheerio包及其依赖未被篡改底层解析器——parse5 与 htmlparser2 属于 Cheerio 生态、由同一团队维护它们自身的缺陷在范围内。值得注意的是最后一点Cheerio 的解析职责实际上委托给了这两个解析器。从源码看src/load-parse.ts 会根据_useHtmlParser2选项在htmlparser2与 parse5 之间切换依赖声明也印证了这一架构package.json 中同时列出htmlparser2、parse5、parse5-htmlparser2-tree-adapter。因此针对解析器本身的漏洞报告同样会被受理。明确排除在外的内容THREAT_MODEL.md 列出的非漏洞清单是理解责任边界的关键使用方不安全地使用 Cheerio 输出——把未经净化的输出直接渲染进浏览器属于应用责任这正是下一节Cheerio 不是净化器的官方表述应用层 API 误用——例如用攻击者控制的字符串作为属性名读取 Cheerio 对象、把未净化的对象作为选项传入属于调用方的输入校验责任对应 CWE-20恶意或存在漏洞的第三方代码——Cheerio 生态之外被攻陷的传递依赖属于供应链问题应向受影响包报告对应 CWE-1357运行时或平台缺陷——Node.js、V8 或操作系统自身的漏洞不在范围内合法大输入的资源消耗——解析 500 MB 的 HTML 文件会占用大量内存属于预期行为DoS 报告必须证明相对于输入规模的非对称资源消耗Gadget 链利用——Cheerio 自身行为正确、只是被用作多库利用链中的一环时不构成 Cheerio 的漏洞。最后一条对评估依赖风险很有参考价值判断一个解析库是否有问题要看它在输入规模与资源消耗之间是否保持线性关系以及序列化是否忠实于输入而不是看它能否被恶意程序利用。安全承诺的源码印证从不执行脚本、从不主动联网Cheerio 的核心安全承诺在 THREAT_MODEL.md 中有一句话概括Cheerio 从不执行脚本、不评估表达式、不访问网络唯一的例外是可选加载器fromURL它使用undici发起你要求的请求。这一承诺可以从源码层面得到印证解析入口 src/load.ts 的load()只做字符串/DOM → 文档的转换不存在任何eval或动态执行路径src/load-parse.ts 中解析器的选择也只是htmlparser2与 parse5 的静态切换。唯一的联网路径fromURL在 src/index.ts 中实现它通过懒加载的undici源码注释说明这是为了避免每次导入付出约 60ms 与 8MB 堆的开销见 src/index.ts发起 GET 请求并做了多层防御默认跟随最多 5 次重定向、非 2xx 响应抛出ResponseError、Content-Type既非 HTML 也非 XML 时抛出RangeError拒绝解析src/index.ts。值得注意的安全细节fromURL会依据响应Content-Type自动决定 XML 模式并把baseURI设置为重定向后的最终 URLsrc/index.ts。这意味着它只会按你的请求去取页面不会解析页面里的任何脚本或发起任何后续请求——解析即安全的边界由此确立。此外在流式解析路径中代码会对 parse5 设置scriptingEnabled truesrc/index.ts。需要澄清的是这一选项在 parse5 中只影响是否模拟脚本元素被执行的文档行为即元素是否被当作会被执行的脚本保留Cheerio 本身并不真正执行任何 JavaScript。使用方的安全义务官方明确划出的责任线虽然 SECURITY.md 是报告与范围的政策文档但它指向的威胁模型在仓库的开发者安全指南中有更落地的实操对应可视为该政策在使用方式维度的延伸website/src/content/docs/advanced/security.md。以下是官方明确归类为使用方责任的四个高频风险点1. Cheerio 不是净化器官方文档开门见山Cheerio 的输出是markup标记不是safe安全的标记。加载包含script或onerror属性的页面时这些内容在解析与序列化后会原样保留——这是解析器应有的忠实行为也意味着$.html()的输出与输入同样可信或同样不可信。如果要把抓取的内容渲染到浏览器必须先用专用净化库如 sanitize-html、DOMPurify处理。2. 操纵方法接收的是原始 HTMLhtml()、append()、prepend()、before()、after()、replaceWith()、wrap()都会把参数当作标记解析。把用户输入直接传给它们等于把输入中的任意标签注入文档。官方给出的对比示例// 如果 name 是 img srcx onerror…你就注入了一个元素 $(#greeting).html(Hello, ${name}); // text() 会转义因此是安全的 $(#greeting).text(Hello, ${name});想表达文本就用text()标记解析方法只应接收你自己构造或已净化的内容。从源码看text()在 src/static.ts 中通过domutils的textContent提取纯文本天然不做任何标签解释。3. 由用户输入拼接的选择器官方明确警告不要用不可信来源构造选择器。即便是给属性值加引号也不够——值中的会闭合属性选择器之后的内容会被解析为更多选择器语法const id x], [data-idsecret; // 实际变成: [data-idx], [data-idsecret] —— 两个选择器而非一个 $([data-id${id}]);Cheerio 没有CSS.escape可靠的修法是把值移出选择器改用固定选择器匹配后用属性比较const matches $([data-id]).filter((_, el) $(el).attr(data-id) id);4. 限制接受的输入规模解析成本与输入规模成正比Cheerio 会照常尝试解析 500 MB 的响应。因此官方建议接受不可控来源的标记时先加上大小上限再交给解析器。这条原则与威胁模型中的合法大输入排除项完全一致——非对称资源消耗才算 DoS线性消耗属于预期行为。事件响应计划报告之后的完整处置闭环作为 SECURITY.md 报告流程的落地配套INCIDENT_RESPONSE.md 描述了维护者处理安全事件的全过程同样适用于 cheerio 生态中的 htmlparser2、css-select 等包。其核心是四级严重程度分级INCIDENT_RESPONSE.md严重级别定义确认时间更新频率目标修复时间Critical正在被实际利用或 RCE/供应链攻陷 24 小时每日 7 天High易利用的 DoS、原型污染或 XSS 助长 72 小时每 3 天 14 天Medium需要非常规配置或影响有限 1 周每周下一个版本Low纵深防御改进、理论风险 2 周按需排期修复处理流程分为六个阶段接收与确认 → 分诊 → 遏制必要时废弃受影响 npm 版本、轮换泄露的凭据、禁用被攻陷的 CI 工作流→ 修复含回归测试→ 发布与披露发布 npm 补丁与 Security AdvisoryAdvisory 会自动生成 CVE并触发 Dependabot 告警→ 事后复盘解决后一周内完成INCIDENT_RESPONSE.md。作为漏洞报告者理解这一分级和流程的价值在于报告时提供准确的严重级别判断和受影响版本能显著加速处置而补丁发布 → CVE 生成 → Dependabot 告警的链路则是你所在项目自动感知 Cheerio 安全更新的机制。相关文档导航SECURITY.md 与仓库内另外两份安全文档构成完整闭环文中链接均已转换为仓库根目录下的相对路径安全政策SECURITY.md——版本支持范围与漏洞报告流程威胁模型THREAT_MODEL.md——Cheerio 认为什么是漏洞、什么是非漏洞的完整声明事件响应计划INCIDENT_RESPONSE.md——维护者如何分级与处置安全事件面向开发者的安全实践指南见 website/src/content/docs/advanced/security.md。如果你的项目以 Cheerio 为依赖建议将以上三份文档连同 package.json 中的版本信息一并纳入依赖安全评估与漏洞响应预案——它们共同定义了什么该报、报给谁、多久会有回应、哪些责任在你自己的完整边界。【免费下载链接】cheerioThe fast, flexible, and elegant library for parsing and manipulating HTML and XML.项目地址: https://gitcode.com/gh_mirrors/ch/cheerio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cheerio 安全政策与威胁边界：从漏洞报告流程到解析库的安全承诺
Cheerio 安全政策与威胁边界从漏洞报告流程到解析库的安全承诺【免费下载链接】cheerioThe fast, flexible, and elegant library for parsing and manipulating HTML and XML.项目地址: https://gitcode.com/gh_mirrors/ch/cheerio导读本文以 Cheerio 官方安全政策文档 SECURITY.md 为主体系统梳理该 HTML/XML 解析库的版本支持范围、漏洞报告流程、安全关注点与责任边界并结合仓库内 THREAT_MODEL.md、INCIDENT_RESPONSE.md 及核心源码回答三个实际问题哪些版本会收到安全更新、如何私下报告漏洞、哪些问题属于 Cheerio 的安全职责而哪些属于使用方义务。读完本文你将掌握围绕 Cheerio 制定漏洞响应预案、评估解析类依赖安全风险所需的完整信息。支持的版本范围只有 1.x 分支收到安全更新Cheerio 在 SECURITY.md 中明确划分了受支持与不受支持的版本VersionSupported1.x✅ Yes 1.0❌ No政策原文强调只有1.x分支的最新发布版本会收到安全更新。如果你在使用更早的主版本官方建议直接升级而不是期待旧版本获得补丁。这一点在仓库的 package.json 中也可以得到印证——当前仓库版本为1.2.0正处于受支持区间同时engines字段要求 Node.js 22.19.0package.json实际部署时也应关注运行时版本是否在官方维护范围内。对于依赖方而言这一小节的政策含义是安全更新只会落在 1.x 的最新发布上升级策略应始终指向当前最新版而不是能用就不动。漏洞报告流程不走公开 issue走私下渠道禁止公开渠道SECURITY.md 的第一条硬性规定是请勿为安全漏洞开启公开的 GitHub issue。公开讨论会让漏洞细节在修复完成前曝光增加被恶意利用的风险。两个官方报告渠道首选渠道——Tidelift 安全联系渠道Cheerio 通过 Tidelift 协调修复与披露SECURITY.md。Tidelift 会负责在维护者与报告者之间协调补丁开发与公开披露的时间点。备选渠道——GitHub 私有漏洞报告如果 Tidelift 未及时响应可以通过 GitHub 的私有安全公告Security Advisory渠道提交SECURITY.md该渠道同样保证报告在修复期间保持机密。报告中应包含的信息为了提高漏洞确认与修复效率官方要求报告尽量提供以下内容SECURITY.md漏洞描述及其潜在影响复现步骤或概念验证PoC受影响的 Cheerio 版本相关配置细节你建议的严重级别Critical / High / Medium / Low这五项信息与 INCIDENT_RESPONSE.md 中分级响应表的输入直接对应——报告里给出的严重级别和受影响版本正是维护者进行 Triage 时最先核对的字段。提交后的处理时间线报告提交后维护者承诺按以下流程处理SECURITY.md确认Acknowledgment——72 小时内确认收到报告分诊Triage——评估严重性、影响范围与受影响版本修复与发布Fix Release——开发、测试并发布补丁披露Disclosure——发布 GitHub Security Advisory 公开详情并除非你选择匿名将报告者列入致谢。官方同时请求报告者在问题修复前给予合理的保密时间不要抢先公开。需要说明的是INCIDENT_RESPONSE.md 特别强调这些是志愿者维护的开源项目给出的善意响应目标而非 SLA 承诺。安全关注范围Cheerio 关心什么Cheerio 是面向 Node.js 的 HTML/XML 解析与操纵库package.json因此其安全关注点集中在解析不可信标记这条攻击面上。SECURITY.md 列出了五类官方特别关注的问题拒绝服务Denial of service——精心构造的输入导致内存或 CPU 消耗失控例如 ReDoS正则灾难性回溯、二次方复杂度的解析行为原型污染Prototype pollution——通过解析内容或 API 误用修改Object.prototypeXSS 助长XSS enablement——Cheerio 的输出在浏览器上下文中渲染时意外引入 XSS 的路径供应链Supply chain——被攻陷的依赖、构建管道或发布产物信息泄露Information disclosure——通过解析或序列化行为无意泄露数据。威胁模型中的范围内定义THREAT_MODEL.md 对以上范围做了更细的界定并补充了意外代码执行一类任何使解析或序列化路径触发eval、Function或等价执行攻击者提供内容的场景都被视为安全漏洞。同时文档明确说明Cheerio 不是净化器序列化器产出比输入更危险的输出例如错误转义导致的属性注入才属于 XSS enablement 漏洞范畴。信任边界什么不可信什么可信THREAT_MODEL.md 给出了清晰的信任边界划分不可信攻击者可控所有输入标记——传给load()、loadBuffer()、流式 API 或.html(content)、.append(content)等操纵方法的任意 HTML/XML 字符串来自外部来源的 CSS 选择器——由用户输入衍生的选择器可能触发选择器引擎的病态回溯。可信JavaScript 运行时——假设 Node.js 或兼容运行时未被篡改调用方应用代码——库的职责到输出为止调用方负责如何处理输出如在浏览器渲染前净化包完整性——假设安装的cheerio包及其依赖未被篡改底层解析器——parse5 与 htmlparser2 属于 Cheerio 生态、由同一团队维护它们自身的缺陷在范围内。值得注意的是最后一点Cheerio 的解析职责实际上委托给了这两个解析器。从源码看src/load-parse.ts 会根据_useHtmlParser2选项在htmlparser2与 parse5 之间切换依赖声明也印证了这一架构package.json 中同时列出htmlparser2、parse5、parse5-htmlparser2-tree-adapter。因此针对解析器本身的漏洞报告同样会被受理。明确排除在外的内容THREAT_MODEL.md 列出的非漏洞清单是理解责任边界的关键使用方不安全地使用 Cheerio 输出——把未经净化的输出直接渲染进浏览器属于应用责任这正是下一节Cheerio 不是净化器的官方表述应用层 API 误用——例如用攻击者控制的字符串作为属性名读取 Cheerio 对象、把未净化的对象作为选项传入属于调用方的输入校验责任对应 CWE-20恶意或存在漏洞的第三方代码——Cheerio 生态之外被攻陷的传递依赖属于供应链问题应向受影响包报告对应 CWE-1357运行时或平台缺陷——Node.js、V8 或操作系统自身的漏洞不在范围内合法大输入的资源消耗——解析 500 MB 的 HTML 文件会占用大量内存属于预期行为DoS 报告必须证明相对于输入规模的非对称资源消耗Gadget 链利用——Cheerio 自身行为正确、只是被用作多库利用链中的一环时不构成 Cheerio 的漏洞。最后一条对评估依赖风险很有参考价值判断一个解析库是否有问题要看它在输入规模与资源消耗之间是否保持线性关系以及序列化是否忠实于输入而不是看它能否被恶意程序利用。安全承诺的源码印证从不执行脚本、从不主动联网Cheerio 的核心安全承诺在 THREAT_MODEL.md 中有一句话概括Cheerio 从不执行脚本、不评估表达式、不访问网络唯一的例外是可选加载器fromURL它使用undici发起你要求的请求。这一承诺可以从源码层面得到印证解析入口 src/load.ts 的load()只做字符串/DOM → 文档的转换不存在任何eval或动态执行路径src/load-parse.ts 中解析器的选择也只是htmlparser2与 parse5 的静态切换。唯一的联网路径fromURL在 src/index.ts 中实现它通过懒加载的undici源码注释说明这是为了避免每次导入付出约 60ms 与 8MB 堆的开销见 src/index.ts发起 GET 请求并做了多层防御默认跟随最多 5 次重定向、非 2xx 响应抛出ResponseError、Content-Type既非 HTML 也非 XML 时抛出RangeError拒绝解析src/index.ts。值得注意的安全细节fromURL会依据响应Content-Type自动决定 XML 模式并把baseURI设置为重定向后的最终 URLsrc/index.ts。这意味着它只会按你的请求去取页面不会解析页面里的任何脚本或发起任何后续请求——解析即安全的边界由此确立。此外在流式解析路径中代码会对 parse5 设置scriptingEnabled truesrc/index.ts。需要澄清的是这一选项在 parse5 中只影响是否模拟脚本元素被执行的文档行为即元素是否被当作会被执行的脚本保留Cheerio 本身并不真正执行任何 JavaScript。使用方的安全义务官方明确划出的责任线虽然 SECURITY.md 是报告与范围的政策文档但它指向的威胁模型在仓库的开发者安全指南中有更落地的实操对应可视为该政策在使用方式维度的延伸website/src/content/docs/advanced/security.md。以下是官方明确归类为使用方责任的四个高频风险点1. Cheerio 不是净化器官方文档开门见山Cheerio 的输出是markup标记不是safe安全的标记。加载包含script或onerror属性的页面时这些内容在解析与序列化后会原样保留——这是解析器应有的忠实行为也意味着$.html()的输出与输入同样可信或同样不可信。如果要把抓取的内容渲染到浏览器必须先用专用净化库如 sanitize-html、DOMPurify处理。2. 操纵方法接收的是原始 HTMLhtml()、append()、prepend()、before()、after()、replaceWith()、wrap()都会把参数当作标记解析。把用户输入直接传给它们等于把输入中的任意标签注入文档。官方给出的对比示例// 如果 name 是 img srcx onerror…你就注入了一个元素 $(#greeting).html(Hello, ${name}); // text() 会转义因此是安全的 $(#greeting).text(Hello, ${name});想表达文本就用text()标记解析方法只应接收你自己构造或已净化的内容。从源码看text()在 src/static.ts 中通过domutils的textContent提取纯文本天然不做任何标签解释。3. 由用户输入拼接的选择器官方明确警告不要用不可信来源构造选择器。即便是给属性值加引号也不够——值中的会闭合属性选择器之后的内容会被解析为更多选择器语法const id x], [data-idsecret; // 实际变成: [data-idx], [data-idsecret] —— 两个选择器而非一个 $([data-id${id}]);Cheerio 没有CSS.escape可靠的修法是把值移出选择器改用固定选择器匹配后用属性比较const matches $([data-id]).filter((_, el) $(el).attr(data-id) id);4. 限制接受的输入规模解析成本与输入规模成正比Cheerio 会照常尝试解析 500 MB 的响应。因此官方建议接受不可控来源的标记时先加上大小上限再交给解析器。这条原则与威胁模型中的合法大输入排除项完全一致——非对称资源消耗才算 DoS线性消耗属于预期行为。事件响应计划报告之后的完整处置闭环作为 SECURITY.md 报告流程的落地配套INCIDENT_RESPONSE.md 描述了维护者处理安全事件的全过程同样适用于 cheerio 生态中的 htmlparser2、css-select 等包。其核心是四级严重程度分级INCIDENT_RESPONSE.md严重级别定义确认时间更新频率目标修复时间Critical正在被实际利用或 RCE/供应链攻陷 24 小时每日 7 天High易利用的 DoS、原型污染或 XSS 助长 72 小时每 3 天 14 天Medium需要非常规配置或影响有限 1 周每周下一个版本Low纵深防御改进、理论风险 2 周按需排期修复处理流程分为六个阶段接收与确认 → 分诊 → 遏制必要时废弃受影响 npm 版本、轮换泄露的凭据、禁用被攻陷的 CI 工作流→ 修复含回归测试→ 发布与披露发布 npm 补丁与 Security AdvisoryAdvisory 会自动生成 CVE并触发 Dependabot 告警→ 事后复盘解决后一周内完成INCIDENT_RESPONSE.md。作为漏洞报告者理解这一分级和流程的价值在于报告时提供准确的严重级别判断和受影响版本能显著加速处置而补丁发布 → CVE 生成 → Dependabot 告警的链路则是你所在项目自动感知 Cheerio 安全更新的机制。相关文档导航SECURITY.md 与仓库内另外两份安全文档构成完整闭环文中链接均已转换为仓库根目录下的相对路径安全政策SECURITY.md——版本支持范围与漏洞报告流程威胁模型THREAT_MODEL.md——Cheerio 认为什么是漏洞、什么是非漏洞的完整声明事件响应计划INCIDENT_RESPONSE.md——维护者如何分级与处置安全事件面向开发者的安全实践指南见 website/src/content/docs/advanced/security.md。如果你的项目以 Cheerio 为依赖建议将以上三份文档连同 package.json 中的版本信息一并纳入依赖安全评估与漏洞响应预案——它们共同定义了什么该报、报给谁、多久会有回应、哪些责任在你自己的完整边界。【免费下载链接】cheerioThe fast, flexible, and elegant library for parsing and manipulating HTML and XML.项目地址: https://gitcode.com/gh_mirrors/ch/cheerio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
