我看到人们反复犯的一个错误是试图用正则表达式解析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>

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


这取决于你对“解析”的定义。一般来说,XML不能使用正则表达式来解析,因为XML语法根本不是规则的。简单地说,正则表达式无法计数(好吧,Perl的正则表达式实际上可能能够计数),因此您无法平衡打开-关闭标记。


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

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

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


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


实际上

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

不是有效的HTML,也不是有效的XML。

它不是有效的XML,因为'<'和'>'不是属性字符串中的有效字符。它们需要使用相应的XML实体&lt;和比;

它也不是有效的HTML,因为短结尾形式在HTML中是不允许的(但在XML和XHTML中是正确的)。根据HTML 4.01规范,'img'标记也是隐式封闭标记。这意味着手动关闭它实际上是错误的,相当于关闭任何其他标记两次。

正确的HTML版本是

<img src="imgtag.gif" alt="&lt;img&gt;">

XHTML和XML的正确版本是

<img src="imgtag.gif" alt="&lt;img&gt;"/>

下面你给出的例子也是无效的

<
tag
attr="5"
/>

这也不是有效的HTML或XML。标签的名称必须在'<'后面,尽管属性和结束的'>'可以在任何它们想要的地方。有效的XML实际上是

<tag
attr="5"
/>

这里还有一个更时髦的:你实际上可以选择使用"或'作为你的属性引用字符

<img src="image.gif" alt='This is single quoted AND valid!'>

所有其他的原因都是正确的,但是解析HTML的最大问题是人们通常不能正确理解所有的语法规则。浏览器将标记汤解释为HTML这一事实并不意味着您实际上编写了有效的HTML。

编辑:甚至stackoverflow.com也同意我对有效和无效的定义。您的无效XML/HTML没有突出显示,而我的更正版本是。

基本上,XML不是用来用regexp解析的。但也没有理由这么做。每种语言都有很多很多XML解析器。您可以在SAX解析器、DOM解析器和Pull解析器之间进行选择。所有这些都保证比使用regexp解析快得多,然后您可以在生成的DOM树上使用XPath或XSLT等很酷的技术。

因此,我的回答是:用regexp解析XML不仅困难,而且是个坏主意。只需使用现有的数百万个XML解析器中的一个,就可以充分利用XML的所有高级特性。

HTML实在是太难了,你甚至无法自己尝试解析。首先,合法的语法有许多您可能没有意识到的细微之处,其次,HTML在野外只是一个巨大的臭堆(您明白我的意思)。有各种各样的松散解析器库在处理HTML方面做得很好,就使用这些吧。


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

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

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


下面是一些有趣的有效XML:

<!DOCTYPE x [ <!ENTITY y "a]>b"> ]>
<x>
    <a b="&y;>" />
    <![CDATA[[a>b <a>b <a]]>
    <?x <a> <!-- <b> ?> c --> d
</x>

这个快乐的小包裹是有效的HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" [
    <!ENTITY % e "href='hello'">
    <!ENTITY e "<a %e;>">
]>
    <title>x</TITLE>
</head>
    <p id  =  a:b center>
    <span / hello </span>
    &amp<br left>
    <!---- >t<!---> < -->
    &e link </a>
</body>

更不用说所有针对无效结构的浏览器特定解析。

祝你在正则表达式与之对抗时好运!

EDIT (Jörg W Mittag):这是另一个格式良好、有效的HTML 4.01:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd"> 
<HTML/
  <HEAD/
    <TITLE/>/
    <P/>

列表中没有的一个问题是属性可以以任何顺序出现,所以如果你的regex正在寻找一个带有href“foo”和类“bar”的链接,它们可以以任何顺序出现,并且在它们之间有任何数量的其他东西。


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

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

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


我很想说“不要重新发明轮子”。只是XML是一种非常非常复杂的格式。也许我应该说"不要再发明同步加速器"

也许正确的陈词滥调开始于“当你只有一把锤子时……”您知道如何使用正则表达式,正则表达式擅长解析,那么为什么还要费神学习XML解析库呢?

因为解析XML很困难。您不必学习使用XML解析库而节省下来的精力,将被您必须进行的大量创造性工作和错误排查所弥补。为了您自己的利益,谷歌“XML库”并利用其他人的工作。


一般来说,XML不能使用正则表达式来解析,因为XML语法根本不是规则的。简单地说,正则表达式无法计数(好吧,Perl的正则表达式实际上可能能够计数),因此您无法平衡打开-关闭标记。

我不同意。如果你要在regex中使用递归,你可以很容易地找到打开和关闭标记。

这里我展示了一个regex的例子,以避免在第一条消息中解析例子的错误。


我认为问题可以归结为:

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.


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