我看到人们反复犯的一个错误是试图用正则表达式解析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:
<!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>
&<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/>
我认为问题可以归结为:
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.
