我看到人们制作over和over again的一个错误是试图用正则表达式解析XML或HTML . 以下是解析XML和HTML很难的几个原因:
人们希望将文件视为一系列行,但这是有效的:
<tag
attr="5"
/>
人们希望将<或<tag视为标记的开头,但是这样的东西存在于野外:
<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>
你还知道其他什么问题?
12 回答
人们实际上是通过使用正则表达式犯了错误,还是仅仅对他们想要实现的任务足够好?
我完全同意使用正则表达式解析html和xml是不可能的,因为其他人已经回答 .
但是,如果你的要求不是要解析html / xml,而只是在html / xml的“已知良好”位中得到一小部分数据,那么正则表达式甚至更简单的“子串”就足够了 .
这取决于“解析”的含义 . 一般来说,使用正则表达式无法解析XML,因为XML语法绝不是常规的 . 简而言之,正则表达式无法计算(好吧,Perl正则表达式实际上可以计算内容),因此您无法 balancer 开闭标签 .
人们通常默认编写贪婪的模式,通常足以导致无法思考 . *将大块文件啜饮到最大可能的<foo> . * </ foo> .
我不同意 . 如果您将在regex中使用递归,则可以轻松找到打开和关闭标记 .
Here我展示了正则表达式的示例,以避免解析第一条消息中的示例错误 .
我给出了这个问题的简化答案here . 虽然如果你愿意做一些预处理工作,它就不可能实现 .
你的列表中没有一个问题是属性可以按任何顺序出现,所以如果你的正则表达式正在寻找带有href“foo”和类“bar”的链接,它们可以按任何顺序排列,并且有任意数量的其他他们之间的事情 .
其实
是无效的HTML,也不是有效的XML .
它不是有效的XML,因为'<'和'>'在属性字符串中不是有效字符 . 它们需要使用相应的XML实体进行转义&lt;和&gt;
它不是有效的HTML,因为HTML中不允许使用简短的结束表单(但在XML和XHTML中是正确的) . 根据HTML 4.01规范,'img'标签也是隐式封闭标签 . 这意味着手动关闭它实际上是错误的,相当于两次关闭任何其他标签 .
HTML中的正确版本是
XHTML和XML中的正确版本是
您提供的以下示例也无效
这也不是有效的HTML或XML . 标签的名称必须位于“<”后面,尽管属性和结束“>”可能位于他们想要的任何位置 . 所以有效的XML实际上就是这样
这是另一个更有趣的一个:你实际上可以选择使用“或”作为你的属性引用字符
发布的所有其他原因都是正确的,但解析HTML的最大问题是人们通常无法正确理解所有语法规则 . 您的浏览器将您的tagsoup解释为HTML并不意味着您实际上已经编写了有效的HTML .
编辑:甚至stackoverflow.com也同意我关于有效和无效的定义 . 您的无效XML / HTML未突出显示,而我的更正版本是 .
基本上,XML不能用regexp解析 . 但也没有理由这样做 . 每种语言都有许多XML解析器 . 您可以选择SAX解析器,DOM解析器和Pull解析器 . 所有这些都保证比使用正则表达式解析要快得多,然后您可以在生成的DOM树上使用XPath或XSLT等酷技术 .
因此,我的回答是:不仅难以使用正则表达式解析XML,而且这也是一个坏主意 . 只需使用数百万个现有XML解析器中的一个,并利用XML的所有高级功能 .
HTML甚至难以自己解析 . 首先,法律语法有许多你可能不知道的微妙之处,其次,野外的HTML只是一堆巨大的(你得到我的漂移) . 有各种松散的解析器库,可以很好地处理像标签汤这样的HTML,只需使用它们 .
我写了一篇关于这个主题的完整博客文章:Regular Expression Limitations
问题的关键在于HTML和XML是递归结构,需要计数机制才能正确解析 . 真正的正则表达式无法计数 . 您必须具有无上下文语法才能计算 .
前一段有一点需要注意 . 某些正则表达式实现现在支持递归的想法 . 但是,一旦你开始在你的正则表达式中添加递归,你实际上是在扩展边界,应该考虑一个解析器 .
我相信this classic 有您正在寻找的信息 . 您可以在其中一条评论中找到要点:
来自维基百科的更多信息:Chomsky Hierarchy
这里有一些有趣的有效XML:
而这一小小的快乐是有效的HTML:
更不用说针对无效结构的所有特定于浏览器的解析 .
祝好运对阵正则表达式!
编辑(JörgWMittag):这是另一个结构良好,有效的HTML 4.01:
我认为问题归结为:
正则表达式几乎总是不正确的 . 有合法的输入,它将无法正确匹配 . 如果你努力工作,你可以使其99%正确,或99.999%,但使它100%正确几乎是不可能的,如果只是因为XML允许使用实体的奇怪的东西 .
如果正则表达式不正确,即使对于0.00001%的输入,那么您也会遇到安全问题,因为有人可以发现一个会破坏您的应用程序的输入 .
如果正则表达式足以覆盖99.99%的案例,则它将完全不可读且无法维护 .
正则表达式很可能在中等大小的输入文件上表现非常糟糕 . 我第一次遇到XML就是用一个合适的XML解析器替换一个(错误地)解析传入XML文档的Perl脚本,我们不仅用100行代替300行不可读代码,而且我们改进了用户响应时间从10秒到大约0.1秒 .
我很想说"don't re-invent the wheel" . 除了XML是一种非常非常复杂的格式 . 所以也许我应该说"don't reinvent the synchrotron."
也许正确的陈词滥调开始“当你拥有的只是一把锤子......”你知道如何使用正则表达式,正则表达式擅长解析,那么为什么还要学习XML解析库呢?
因为解析XML很难 . 通过不必学习使用XML解析库而节省的任何努力将超过您必须做的创造性工作量和错误捕获量 . 为了你自己,谷歌"XML library"并利用别人的工作 .