你能举例说明为什么用正则表达式解析XML和HTML很困难吗?

我看到人们在制作在和一遍又一遍时犯的一个错误是试图用正则表达式解析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>

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

49136 次浏览
小开

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

小开

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

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

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

小开

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

小开

实际上

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

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

它不是有效的XML，因为属性字符串中的'<'和'>'不是有效字符。它们需要使用相应的XML实体进行转义。和和gt;

它也不是有效的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语法从根本上比 类型3语法-你不可能希望使这个工作。但许多 会尝试，有人会声称成功，有人会发现错误和

一些来自维基百科的更多信息:< >强乔姆斯基层次结构< / >强

小开

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

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

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

小开

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

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

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

小开

我认为问题可以归结为:

  1. 正则表达式几乎总是不正确的。它将无法正确匹配合法的输入。如果您足够努力，您可以使其具有99%或99.999%的正确率，但要使其具有100%的正确率几乎是不可能的，这仅仅是因为XML通过使用实体所允许的一些奇怪的事情。

  2. 如果正则表达式是不正确的，即使是0.00001%的输入，那么就会出现安全问题，因为有人可能会发现一个会破坏应用程序的输入。

  3. 如果正则表达式足够正确，可以覆盖99.99%的情况，那么它将完全不可读和不可维护。

  4. 正则表达式很可能在中等大小的输入文件上执行得非常糟糕。我第一次接触XML是用适当的XML解析器替换(错误地)解析传入XML文档的Perl脚本，我们不仅将300行不可读的代码替换为100行任何人都能理解的代码，而且还将用户响应时间从10秒提高到0.1秒左右。

小开

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


提交答案