正则表达式解析网页

用正则表达式从网页里抠数据，正则就像拿一把瑞士军刀去拆快递——快是表达真的快，扎手也是式解真的扎手。上周我想抓某图书网站的析网新书价格，懒得开浏览器，正则直接curl下来一段HTML，表达盯着满屏的式解<div class="price">标签，第一反应就是析网写个正则匹配数字。结果三分钟搞定，正则比等Puppeteer启动还利索。表达但别急着高兴，式解这法子只适合结构稳定的析网页面，稍微改个class名，正则你的表达正则就当场报废。

为什么有人宁可用正则也不用解析库

BeautifulSoup和lxml当然更稳，式解但装环境、学API、处理编码问题，一套流程下来，小任务早干完了。正则的诱惑在于零依赖，一行re.findall(r'<h3>(.*?)</h3>', html)就能把标题全捞出来。我见过一个运维老哥，用正则从Nginx日志里提取IP和状态码，跑了五年没出过错。他的原话是：“日志格式是我定的，我干嘛要上解析器？”这话有道理，只要数据源可控，正则就是最轻的锤子。

但网页不一样。HTML不是正则语言，嵌套标签、属性顺序、注释、CDATA，随便一个都能让你的模式匹配到奇怪的地方。比如<div class="a">和<div class='a'>，引号不同，正则就得写两套。更别提有些网站把数据塞在JavaScript变量里，正则得跨行匹配，一不小心就贪婪过头，把整个页面都吞了。

一个真实翻车现场

去年帮朋友抓某招聘网站的岗位薪资。页面结构看起来很简单：<span class="salary">15-25K</span>。我写了r'<span class="salary">(.*?)</span>'，测试通过。跑了一周没问题，结果某天对方改版，class变成了salary-text，我的正则直接返回空列表。更坑的是，有些岗位薪资写成“15K-25K·13薪”，我的模式只抓到“15K-25K”，后面的13薪丢了。朋友问为什么少了，我只能说正则太死板，它不懂语义。

后来我换了个思路：先用正则定位到包含“salary”的script标签，再用json解析里面的数据。这样既利用了正则的快速筛选，又避免了硬匹配HTML标签。算是个折中方案，但写起来比纯正则麻烦三倍。

什么时候该果断放弃正则

页面结构复杂、需要提取嵌套层级、或者数据藏在动态加载的JSON里，这时候还硬写正则就是跟自己过不去。我现在的判断标准很简单：如果正则模式超过三行，或者需要用到反向引用和前瞻断言，立刻换解析库。别跟自己的头发过不去。

另外，正则匹配HTML有个隐蔽的坑：HTML实体。比如 、'，你的正则得额外处理转义。有次我抓到的标题里全是'，以为是乱码，查了半天才发现是单引号的实体编码。这种细节，解析库自动帮你搞定，正则得自己写替换逻辑。

我的工具箱里怎么放这两样东西

日常小任务，比如从固定API返回的文本里抽手机号、从日志里抠时间戳，正则永远是第一选择。写起来快，调试也快，re101在线测试一下就能用。但只要是解析网页，尤其是别人的网站，我直接上lxml加XPath。XPath写起来虽然啰嗦，但至少不会因为一个空格或者换行就匹配失败。

有个例外：如果网页是纯文本表格，比如政府公开数据那种<pre>标签里的内容，正则反而比解析器更直观。因为这种页面没有复杂的DOM树，就是一堆字符，正则的字符串处理能力正好对口。

最后说个个人习惯：我写正则解析网页时，一定会加re.DOTALL和re.IGNORECASE，再配个re.finditer而不是findall，这样能拿到匹配位置，方便调试。别小看这些细节，它们决定了你是十分钟搞定还是折腾一下午。

正则表达式是把好刀，但别拿它砍骨头。网页解析这活儿，该上电锯就上电锯。

(责任编辑：百科)