开场不绕弯儿:老生常谈是没错的 - - 用正则完整解析 XML 或 HTML 结构通常不是好主意。但是工程里经常不是完美场景。面临时间紧、外部页面不规则或只是为了临时抓取一点数据时,正则仍然会成为快速可用的工具。关键是要清楚它的边界、风险和补救手段,并把正则当作手段而不是最终目标。 为什么社区里总有人说不要用正则解析 XML?根本原因在于形式语言理论和现实网文语言的不规则性。XML 本身并非正则语言。
它允许嵌套标签、命名空间、实体引用、CDATA、注释、处理指令、DTD 等复杂特性。正则擅长匹配有限的、可用简单规则表达的文本模式,但当语法允许任意深度嵌套时,单纯的正则就会失去对树结构的表达能力。更实际的后果是:你的表达式会在遇到换行、属性顺序变化、空白、注释或被切割的实体时失效,出现误抓或漏抓。 即便如此,许多工程师仍然用正则来完成抓取任务,这不是因为他们不懂正规工具,而是因为正则在某些场景下提供了明显的优势。速度、依赖最少、实现快速迭代以及在资源受限的环境(例如极简容器、嵌入式脚本或运维脚本)中可直接运行,都是正则的卖点。因此问题并不只是可不可以,而是如何在需要妥协时把风险降到最低。
首先要明确什么时候绝对不要用正则。若你需要:保留全部原始属性与命名空间信息、在复杂嵌套中重建树结构、正确处理实体与编码细节、或保证长期稳定的 API 级数据解析,那么选择成熟的解析器不可替代。XML 和 HTML 都有专门的库:在 Python 里有 lxml、xml.etree、BeautifulSoup;在 JavaScript 里有 htmlparser2、cheerio;命令行环境有 xmllint、xmlstarlet、pup、htmlq 等。这些工具能正确处理编码、实体、注释、注入式脚本等,减少意外。 当你确实要用正则时,有一套实用的防护方法可以降低脆弱性。不要试图解析树结构,只提取局部文本或锚定区块。
也就是说,把任务转化为"把感兴趣的文本块从文档中抽取出来"而不是"构建 DOM"或"理解文档的全部语义"。举例来说,想从一个页面提取某个 download 区块或特定标题下的列表时,先用稳定的锚点(例如可预见的文字、id 或 class 值)把片段定位出来,然后在片段内部用更宽容的正则去抓取所需字段。这样可以把正则的使用范围限制在局部,降低全局语法差异带来的影响。 在具体技巧层面,应该优先使用支持 PCRE 的正则引擎,利用非贪婪量词、断言与多行或单行模式控制匹配边界。非贪婪量词可以避免"跨越太多"的问题,正向先行断言和后行断言可以在不捕获多余内容的同时锚定上下文。尽量避开通配符 .* 直接吞掉整段文本的做法,改用具体的字符类或限定长度,例如 [^<]+ 用来匹配标签之间的内容要比 .* 更稳健。
若需要处理换行,用 DOTALL 或单行模式,或者预先把换行归一化为空格以简化正则逻辑。 尽量减少对标签结构的依赖。很多网页的 class 名称、属性顺序或空格会随前端框架更新而改变,但可视文本如表头、按钮文本往往更稳定。把抓取逻辑从 DOM 精确定位转向"文本锚点加紧凑提取",能在面对小幅改动时保持更大的适应性。同时保持多步清洗的流程,而不是依赖单条复杂正则完成所有事情。典型流程是先把原始 HTML 拉下并进行最小化(去掉回车与多余空白),然后按锚点切割出片段,再在片段内执行若干较小的正则替换或提取,最后对结果做规范化与验真。
举例说明:假设你要抓取一个下载页面里列出的平台与 URL。稳妥做法是先定位到包含 downloads 的容器行,再用较短的正则抽取 href 内容与平台描述。避免写一个试图匹配整页复杂嵌套的单行万用表达式。以 shell 管线为例,可以先用 curl 抓取,再用 tr -d 削减回车换行,再用 grep -P 围绕固定锚点抽取局部,再用 sed 或 awk 做进一步清洗。关键在于把链路拆成多个可验证小步,每步都能在失败时回退或报警。 要特别警惕的是嵌套标签的场景。
正则无法稳妥处理任意深度的递归嵌套。比如你想抓取任意标签内的完整子树内容,简单的 <tag.*?>(.*?)</tag> 在遇到子标签里再次出现相同 tag 名称时会失败。如果页面结构可能出现相同标签的嵌套,应该放弃单正则完全解析,改用真正的解析器,或在抓取时增加上下文限制使嵌套可能性被排除。 处理属性与实体也很容易栽跟头。XML 属性可以使用单引号或双引号,属性值中可能包含实体引用如 & 或被转义的字符,属性顺序不固定,某些属性可能缺失。若你的正则要求严格的属性顺序或特定空格,抓取会异常脆弱。
更稳健的做法是在抽取前用简单正则把感兴趣的标签块取出,再在一个更容错的阶段用额外的正则或轻量解析处理属性,或者完全交给专门库解析属性后再处理值。 性能方面,正则在单次执行上通常比 DOM 解析器更轻量,尤其是在只提取少量文本时。但千万不要写出指数级回溯的正则模式。复杂的嵌套量词和大量选择分支会导致回溯爆炸,进而把 IO 等待的轻量脚本变成 CPU 吃紧的任务。测试你的表达式在代表性输入集上的表现,使用非贪婪而非复杂嵌套优先匹配。许多平台提供在线或本地的工具来检测正则回溯风险并优化表达式。
另一个重要角度是可维护性和可观测性。临时正则脚本很容易被遗漏在仓库角落里,随时间失效且难以调试。为避免这种情况,建议写清楚的单元测试或集成测试来覆盖最关键的抓取路径,并在抓取失败时发送告警或保存失败快照用于回放。记录抓取版本和最近一次成功样本可以大幅降低运维成本。更进一步,如果抓取用于业务关键流程,把正则方案放入灰度策略中:当正则失败时自动切换到备用解析器或降级逻辑,而非直接返回空数据。 法律与道德方面的考虑不可忽视。
抓取第三方站点数据前务必查看 robots.txt、服务条款和隐私条款,尊重版权和请求频率限制。即便技术上可行,不当行为也会给自己或团队带来法律与声誉风险。完善的爬虫应实现请求限速、请求头模拟、人为友好访问策略和缓存机制,避免在短时间内对目标站点造成过大压力。 最后给出一个实践性的建议清单供参考:优先寻找官方 API 或机器可读接口,优先使用现成的解析库以保证长期正确性,把正则限定在局部摘取而非树重构,使用 PCRE 的高级特性但避免复杂回溯,分阶段清洗与抽取并实现故障告警与回退策略。把正则当作快速、短期且受控的武器,而不是可持续的长期解决方案。 总结时回到最初的悖论:理论上正则不能完整解析 XML,但工程上它依然能在合适场景下快速解决问题。
关键在于对场景进行正确的判断和风险控制。选择正确的工具并不意味着一成不变,意味着你了解各自的优势与局限。掌握该放弃的时机与该坚持的理由,才能在真实世界的工程中既高效又稳健地完成任务。 。
