我看到人们反复犯的一个错误是试图用正则表达式解析XML或HTML。以下是解析XML和HTML比较困难的几个原因:

人们希望将文件视为行序列,但这是有效的:

<tag
attr="5"
/>

人们希望将<或<标记作为标记的开始,但这样的东西在野外存在:

<img src="imgtag.gif" alt="<img>" />

人们经常想要匹配开始标签和结束标签,但是XML和HTML允许标签包含自己(传统的正则表达式根本无法处理):

<span id="outer"><span id="inner">foo</span></span> 

人们经常想要匹配文档的内容(例如著名的“在给定页面上查找所有电话号码”问题),但数据可能会被标记(即使在查看时看起来是正常的):

<span class="phonenum">(<span class="area code">703</span>)
<span class="prefix">348</span>-<span class="linenum">3020</span></span>

注释可能包含格式不佳或不完整的标记:

<a href="foo">foo</a>
<!-- FIXME:
    <a href="
-->
<a href="bar">bar</a>

你还知道其他什么陷阱吗?


当前回答

对于这个问题,我给出了一个简化的答案。虽然这并不是100%的标记,但我解释了如果您愿意做一些预处理工作,这是如何实现的。

其他回答

人们使用正则表达式是犯了一个错误,还是仅仅因为正则表达式对他们试图实现的任务足够好?

我完全同意其他人回答的使用正则表达式解析html和xml是不可能的。

然而,如果你的要求不是解析html/xml,而是在html/xml中“已知的好”的部分中获得一小部分数据,那么一个正则表达式甚至一个更简单的“子字符串”就足够了。

人们通常默认编写贪婪模式,通常足以导致未经深思熟虑的。*将大块文件吸进尽可能大的<foo>.*</foo>. *。

关于这个主题,我写了一篇完整的博文:正则表达式的限制

问题的关键在于HTML和XML是递归结构,为了正确地解析它们需要计数机制。真正的正则表达式不能计数。为了计数,必须使用与上下文无关的语法。

前一段有一个小小的警告。某些regex实现现在支持递归的思想。然而,一旦您开始在正则表达式中添加递归,您实际上是在扩展边界,应该考虑使用解析器。

我相信这本经典书里有你要找的信息。你可以在那里的一条评论中找到要点:

我认为这里的缺陷在于HTML是Chomsky Type 2语法 (上下文无关语法),RegEx是Chomsky Type 3语法(常规语法) 表达式)。因为Type 2语法从根本上比 第三型语法——你不可能指望能做到这一点。但许多 会尝试,有人会声称成功,有人会发现错误和 把你搞得一团糟。

更多信息来自维基百科:乔姆斯基等级

我认为问题可以归结为:

The regex is almost invariably incorrect. There are legitimate inputs which it will fail to match correctly. If you work hard enough you can make it 99% correct, or 99.999%, but making it 100% correct is almost impossible, if only because of the weird things that XML allows by using entities. If the regex is incorrect, even for 0.00001% of inputs, then you have a security problem, because someone can discover the one input that will break your application. If the regex is correct enough to cover 99.99% of cases then it is going to be thoroughly unreadable and unmaintainable. It's very likely that a regex will perform very badly on moderate-sized input files. My very first encounter with XML was to replace a Perl script that (incorrectly) parsed incoming XML documents with a proper XML parser, and we not only replaced 300 lines of unreadable code with 100 lines that anyone could understand, but we improved user response time from 10 seconds to about 0.1 seconds.