我需要匹配所有这些开头标记:
<p>
<a href="foo">
但不是这些:
<br />
<hr class="foo" />
我想出了这个,想确保我做得对。我只是在捕捉a-z。
<([a-z]+) *[^/]*?>
我相信上面写着:
找到一个小于,然后查找(并捕获)a-z一次或多次,然后找到零个或多个空格,然后查找任何字符零次或多次,贪婪,除了/,然后查找大于
我有这个权利吗?更重要的是,你怎么看?
我需要匹配所有这些开头标记:
<p>
<a href="foo">
但不是这些:
<br />
<hr class="foo" />
我想出了这个,想确保我做得对。我只是在捕捉a-z。
<([a-z]+) *[^/]*?>
我相信上面写着:
找到一个小于,然后查找(并捕获)a-z一次或多次,然后找到零个或多个空格,然后查找任何字符零次或多次,贪婪,除了/,然后查找大于
我有这个权利吗?更重要的是,你怎么看?
当前回答
<([a-z][^>\s]*)(?:\s+[^>]+)?>
此正则表达式将匹配由单个单词(例如<p>、<a>等)组成的开头标记,后跟零个或多个空格和任意数量的字符(除了>或空白),然后是结束>字符。它还会将标记与属性匹配,并且不会将标记与包含a-z以外字符的名称匹配。然而,它仍然不会匹配自动关闭标签。
其他回答
这可能会:
<.*?[^/]>
或不带结束标记:
<[^/].*?[^/]>
HTML解析器上的火焰大战是怎么回事?HTML解析器必须解析(并重建!)整个文档,然后才能对搜索进行分类。在某些情况下,正则表达式可能更快/更优雅。我的2美分。。。
我同意解析XML,特别是HTML的正确工具是解析器,而不是正则表达式引擎。然而,正如其他人所指出的,有时使用正则表达式更快、更容易,并且如果您知道数据格式,就可以完成任务。
微软实际上有一节《.NET Framework中正则表达式的最佳实践》,专门讨论了“考虑输入源”。
正则表达式确实有局限性,但您是否考虑过以下问题?
在正则表达式方面,.NET框架是独一无二的,因为它支持平衡组定义。
请参见将平衡构造与.NET正则表达式匹配请参见.NET正则表达式:Regex和平衡匹配请参阅Microsoft关于平衡组定义的文档
因此,我相信您可以使用正则表达式解析XML。然而,请注意,它必须是有效的XML(浏览器对HTML非常宽容,并且允许HTML中有错误的XML语法)。这是可能的,因为“平衡组定义”将允许正则表达式引擎充当PDA。
引用上述第1条:
.NET正则表达式引擎如上所述,不能用正则表达式。但是,.NET正则表达式引擎提供了一些允许平衡构造辨识。(?<group>)-使用名称组。(?<-group>)-从捕获堆栈。(?(组)yes|no)-如果存在组,则匹配yes部分否则,名称组不匹配任何部分。这些构造允许.NET正则表达式模拟通过本质上允许简单版本的堆栈来限制PDA操作:推送、弹出和清空。简单的操作非常简单分别相当于递增、递减和比较为零。这允许.NET正则表达式引擎识别上下文无关语言的子集,特别是那些仅需要一个简单的计数器。这反过来允许非传统的.NET正则表达式,以识别各个正确平衡的构造。
考虑以下正则表达式:
(?=<ul\s+id="matchMe"\s+type="square"\s*>)
(?>
<!-- .*? --> |
<[^>]*/> |
(?<opentag><(?!/)[^>]*[^/]>) |
(?<-opentag></[^>]*[^/]>) |
[^<>]*
)*
(?(opentag)(?!))
使用标志:
单线IgnorePatternHitespace(如果折叠正则表达式并删除所有空格,则不需要)IgnoreCase(不需要)
正则表达式解释(内联)
(?=<ul\s+id="matchMe"\s+type="square"\s*>) # match start with <ul id="matchMe"...
(?> # atomic group / don't backtrack (faster)
<!-- .*? --> | # match xml / html comment
<[^>]*/> | # self closing tag
(?<opentag><(?!/)[^>]*[^/]>) | # push opening xml tag
(?<-opentag></[^>]*[^/]>) | # pop closing xml tag
[^<>]* # something between tags
)* # match as many xml tags as possible
(?(opentag)(?!)) # ensure no 'opentag' groups are on stack
您可以在一个更好的.NET正则表达式测试仪上尝试。
我使用了以下示例源:
<html>
<body>
<div>
<br />
<ul id="matchMe" type="square">
<li>stuff...</li>
<li>more stuff</li>
<li>
<div>
<span>still more</span>
<ul>
<li>Another >ul<, oh my!</li>
<li>...</li>
</ul>
</div>
</li>
</ul>
</div>
</body>
</html>
这找到了匹配项:
<ul id="matchMe" type="square">
<li>stuff...</li>
<li>more stuff</li>
<li>
<div>
<span>still more</span>
<ul>
<li>Another >ul<, oh my!</li>
<li>...</li>
</ul>
</div>
</li>
</ul>
尽管它实际上是这样的:
<ul id="matchMe" type="square"> <li>stuff...</li> <li>more stuff</li> <li> <div> <span>still more</span> <ul> <li>Another >ul<, oh my!</li> <li>...</li> </ul> </div> </li> </ul>
最后,我真的很喜欢杰夫·阿特伍德的文章:解析Html的Cthhulhu方式。有趣的是,它引用了这个问题的答案,目前有超过4万张选票。
首先,回答一个直接的问题:正则表达式有一个bug,因为它会在任何地方排除带有斜线的标记,而不仅仅是在结尾。例如,它将排除这个有效的开头标记:<a href=“foo/bar.html”>,因为它在属性值中有一个斜杠。
我们可以解决这个问题,但更严重的是,这个正则表达式将导致误报,因为它还将匹配内部注释和cdata部分,其中相同的字符不表示有效的标记。例如:
<!-- <foo> -->
or
<![CDATA[ <foo> ]]>
尤其是嵌入脚本中的html字符串很可能会触发误报,JavaScript中经常使用<和>作为比较运算符也是如此。当然还有html的部分,这些部分用<!-->注释掉了。
因此,为了只匹配实际标记,您还需要能够跳过过去的注释和cdata部分。因此,您需要正则表达式来匹配注释和cdata,但只捕获开头标记。这仍然可以使用rexep,但它变得更加复杂,例如:
(
<!-- .*? --> # comment
| <!\[CDATA\[ .*? \]\]> # CData section
| < \w+ ( "" [^""]* "" | ' [^']* ' | [^>/'""] )* /> # self-closing tag
| (?<tag> < \w+ ( "" [^""]* "" | ' [^']* ' | [^>/'""] )* > ) # opening tag - captured
| </ \w+ \s* > # end tag
)
这仅适用于符合HTML兼容性准则的XHTML。如果您想处理任意XHTML,还应该处理处理指令和内部DTD,因为它们也可以嵌入误报。如果您还想处理HTML,还有其他复杂的问题,比如<script>-标记。如果您还想处理无效的HTML,则会变得更加复杂。
鉴于复杂性,我不建议走这条路。相反,寻找一个现成的(X)HTML解析库,它可以解决您的问题。
解析器通常在后台使用正则表达式(或类似的表达式)将文档拆分为“标记”(doctype、开始标记、结束标记、文本内容等)。但其他人会为您调试和测试这些正则表达式!根据解析器的类型,它可以通过匹配开始标记和结束标记来进一步构建元素的树结构。这几乎肯定会为您节省大量时间。
要使用的精确解析器库取决于您的语言和平台以及您正在解决的任务。如果您需要访问实际的标记子字符串(例如,如果您正在为HTML编写语法高亮),则需要使用SAX样式的解析器,该解析器直接公开语法标记。
如果您只执行标记匹配以手动构建元素的语法树,那么DOM解析器将为您完成这项工作。但是DOM解析器不公开底层的标记语法,因此无法解决您描述的确切问题。
您还应该考虑是否需要解析无效的HTML。这是一项复杂得多的任务,但在野生网络上,大多数HTML实际上是无效的。类似Pytons html5lib的东西可以解析无效的HTML。
每当我需要从HTML文档中快速提取内容时,我都会使用Tidy将其转换为XML,然后使用XPath或XSLT来获取所需内容。在您的案例中,类似于:
//p/a[@href='foo']
<\s*(\w+)[^/>]*>
各部分解释如下:
<:起始字符
\s*:标签名称前可能有空格(难看,但可能)。
(\w+):标记可以包含字母和数字(h1)。嗯,w也与“_”匹配,但我想它不会伤害你。如果好奇,请改用([a-zA-Z0-9]+)。
[^/>]*:除了>和/直到关闭>
>:关闭>
不相关的
对于那些低估了正则表达式的人来说,他们说正则表达式的功能和正则语言一样强大:
anbanban不是规则的,甚至不是上下文无关的,可以与^(a+)b\1b\1匹配$
反向引用FTW!