(来自http://htmlparsing.com/regexes)

假设您有一个HTML文件，您试图从中提取url < img >标签。

<img src="http://example.com/whatever.jpg">

所以你可以用Perl写一个这样的正则表达式:

if ( $html =~ /<img src="(.+)"/ ) {
    $url = $1;
}

在本例中，$url确实包含 http://example.com/whatever.jpg。但是当 你会得到这样的HTML:

<img src='http://example.com/whatever.jpg'>

or

<img src=http://example.com/whatever.jpg>

or

<img border=0 src="http://example.com/whatever.jpg">

or

<img
    src="http://example.com/whatever.jpg">

否则你就会得到假阳性

<!-- // commented out
<img src="http://example.com/outdated.png">
-->

它看起来很简单，对于一个单一的、不变的文件来说可能很简单，但是对于任意HTML数据，正则表达式只会让你将来头疼。

对于快速´n´dirty regexp就可以了。但是要知道的基本问题是，不可能构造一个正确解析HTML的regexp。

原因是regexp不能处理任意嵌套的表达式。参见正则表达式能否用于匹配嵌套模式?

两个简单的原因:

编写一个能够抵御恶意输入的正则表达式是困难的;比使用预先构建的工具难多了 编写一个正则表达式来处理你不可避免地会遇到的荒谬的标记是困难的;比使用预先构建的工具难多了

关于正则表达式在解析中的适用性:它们并不合适。您是否见过解析大多数语言所需的正则表达式类型?

正则表达式无法解析整个HTML，因为它依赖于匹配开始标记和结束标记，而正则表达式则无法匹配。

正则表达式只能匹配常规语言，但HTML是一种与上下文无关的语言，而不是常规语言(正如@StefanPochmann所指出的，常规语言也是与上下文无关的，因此与上下文无关并不一定意味着不常规)。在HTML上使用regexp唯一能做的事情是启发式，但这并不适用于所有条件。任何正则表达式都可以错误地匹配HTML文件。

You, know...there's a lot of mentality of you CAN'T do it and I think that everyone on both sides of the fence are right and wrong. You CAN do it, but it takes a little more processing than just running one regex against it. Take this (I wrote this inside of an hour) as an example. It assumes the HTML is completely valid, but depending on what language you're using to apply the aforementioned regex, you could do some fixing of the HTML to make sure that it will succeed. For example, removing closing tags that are not supposed to be there: </img> for example. Then, add the closing single HTML forward slash to elements that are missing them, etc.

我将在编写一个库的上下文中使用它，该库允许我执行类似于JavaScript的[x]. getelementsbytagname()的HTML元素检索。我只是拼接了我在正则表达式的DEFINE部分中编写的功能，并使用它来进入元素树，一次一个。

那么，这将是验证HTML的最终100%答案吗?不。但这只是个开始，只要再努力一点，就可以做到。然而，试图在一个正则表达式执行中完成它是不实际的，也不有效。

“这要看情况”。由于这里给出的所有原因，正则表达式不能也不能准确地解析HTML，这是事实。但是，如果错误的后果(比如不处理嵌套标记)很小，如果正则表达式在您的环境中非常方便(比如在入侵Perl时)，那么就继续。

假设您正在解析链接到您站点的网页——也许您是通过谷歌链接搜索找到它们的——并且您想要一种快速方法来大致了解链接周围的上下文。您试图运行一个小报告，可能会提醒您链接垃圾邮件，诸如此类。

在这种情况下，对某些文档进行错误解析并不是什么大问题。除了你自己，没有人会发现错误，如果你足够幸运，你可以单独跟进。

我想我是说这是一种权衡。有时，实现或使用正确的解析器(尽管很简单)可能不值得麻烦，如果准确性不是至关重要的话。

小心你的假设。例如，如果您试图解析将公开显示的内容，我可以想到regexp快捷方式可能适得其反的几种情况。