我需要匹配所有这些开头标记：
<p>
<a href="foo">
但不是这些：
<br />
<hr class="foo" />
我想出了这个，想确保我做得对。我只是在捕捉a-z。
<([a-z]+) *[^/]*?>
我相信上面写着：
找到一个小于，然后查找（并捕获）a-z一次或多次，然后找到零个或多个空格，然后查找任何字符零次或多次，贪婪，除了/，然后查找大于
我有这个权利吗？更重要的是，你怎么看？
当前回答
尽管为此目的使用正则表达式并不合适和有效，但有时正则表达式为简单的匹配问题提供了快速解决方案，在我看来，将正则表达式用于琐碎的工作并不可怕。
有一篇关于匹配StevenLevithan编写的最内部HTML元素的权威博客文章。
其他回答
我以前使用过一个名为HTMLParser的开源工具。它被设计为以各种方式解析HTML，并且很好地达到了目的。它可以将HTML解析为不同的树节点，您可以轻松地使用它的API从节点中获取属性。看看它，看看这对你有没有帮助。
的确，在编程时，在处理HTML时，最好使用专用解析器和API，而不是正则表达式，尤其是在准确性至关重要的情况下（例如，如果您的处理可能涉及安全问题）。然而，我并不认为XML风格的标记永远不应该用正则表达式来处理。在某些情况下，正则表达式是一个很好的工具，例如在文本编辑器中进行一次性编辑，修复损坏的XML文件，或者处理看起来像但不太像XML的文件格式。有一些问题需要注意，但它们并非不可逾越，甚至不一定相关。
像<（[^>“']|”[^“]*”|'[^']*'）*>这样的简单正则表达式通常足够好，例如我刚才提到的那些情况。这是一个天真的解决方案，但它确实允许在属性值中使用未编码的>符号。如果您正在查找，例如，表标签，您可以将其调整为</？表\b（[^>“']|”[^“]*”|'[^']*'）*>。
为了了解更“高级”的HTML正则表达式会是什么样子，以下内容在模拟真实世界的浏览器行为和HTML5解析算法方面做了相当出色的工作：
</?([A-Za-z][^\s>/]*)(?:=\s*(?:"[^"]*"|'[^']*'|[^\s>]+)|[^>])*(?:>|$)
以下内容与相当严格的XML标记定义相匹配（尽管它没有考虑XML名称中允许的全部Unicode字符集）：
<(?:([_:A-Z][-.:\w]*)(?:\s+[_:A-Z][-.:\w]*\s*=\s*(?:"[^"]*"|'[^']*'))*\s*/?|/([_:A-Z][-.:\w]*)\s*)>
当然，这些不考虑周围的上下文和一些边缘情况，但如果您真的想处理这些问题（例如，通过在另一个正则表达式的匹配项之间进行搜索），也可以处理这些问题。
在一天结束时，使用最适合该作业的工具，即使该工具恰好是正则表达式。
OP似乎没有说他需要用标签做什么。例如，他需要提取内部文本，还是只检查标签？
我坚定地认为正则表达式不是万能的文本解析器。我已经编写了大量的文本解析代码，包括用于解析HTML标记的代码。
虽然我确实对正则表达式不太在行，但我认为正则表达式太死板，很难维护这种解析。
中国古代军事家、将军和哲学家孙子说过：
据说，如果你了解你的敌人，了解你自己，你可以赢得百战百胜，而不会一败涂地。如果你只了解自己，而不了解对手，你可能会赢，也可能会输。如果你既不了解你自己也不了解你的敌人，你将永远危及自己。
在这种情况下，你的敌人是HTML，你要么是你自己，要么是正则表达式。您甚至可能是带有不规则正则表达式的Perl。了解HTML。了解自己。
我写了一首描述HTML本质的俳句。
HTML has
complexity exceeding
regular language.
我还写了一首俳句，描述Perl中正则表达式的性质。
The regex you seek
is defined within the phrase
<([a-zA-Z]+)(?:[^>]*[^/]*)?>
我同意解析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万张选票。
