似乎在stackoverflow上的每个问题中，提问者使用regex从HTML中获取一些信息，将不可避免地有一个“答案”，说不要使用regex解析HTML。
为什么不呢?我知道有一些所谓的“真正的”HTML解析器，比如Beautiful Soup，我相信它们是强大而有用的，但如果您只是在做一些简单、快速或简单的事情，那么当一些正则表达式语句就可以很好地工作时，为什么要麻烦使用如此复杂的东西呢?
此外，是否只是因为我不理解正则表达式的某些基本原理，才使得它们在解析中成为一个糟糕的选择?
当前回答
这个表达式从HTML元素中检索属性。它支持:
未加引号/加引号的属性， 单引号/双引号， 属性中的转义引号， 等号周围的空格， 任意数量的属性， 只检查标签内的属性， 转义注释，以及 在一个属性值中管理不同的引号。
(?:\<\!\-\-(?:(?!\-\-\>)\r\n?|\n|。)*?-\-\>)|(?:<(\ S+)\s+(?=.*>)|(?<=[=\s])\G)(?:((?:(?!\s|=).)*)\s*?=\ s*?[\"']?((?:(?<=\"))(?:(?<=\\)\"|[^\"])*|(?<=')(? : (?<=\\)'|[^'])*)|(?:(?!\"|')(?:(?!\/>|>|\s).)+)[\ "']?\s*)
来看看。在演示中，使用“gisx”标志效果更好。
其他回答
对于快速´n´dirty regexp就可以了。但是要知道的基本问题是，不可能构造一个正确解析HTML的regexp。
原因是regexp不能处理任意嵌套的表达式。参见正则表达式能否用于匹配嵌套模式?
在某些情况下，使用正则表达式解析HTML中的某些信息是正确的——这在很大程度上取决于具体情况。
上面的共识是，总的来说，这是一个坏主意。然而，如果HTML结构是已知的(并且不太可能改变)，那么它仍然是一种有效的方法。
HTML/XML分为标记和内容。 Regex只对词法标记解析有用。 我想你可以推断出内容。 对于SAX解析器来说，这是一个很好的选择。 标签和内容可以传递给用户 定义了嵌套/闭包元素的函数 可以被追踪。
只要解析标记就可以了 正则表达式，用于从文档中删除标记。
经过多年的测试，我发现了秘密 浏览器解析标签的方式，包括良好的和不良的形式。
普通元素的解析形式如下:
这些标记的核心使用这个正则表达式
(?:
" [\S\s]*? "
| ' [\S\s]*? '
| [^>]?
)+
你会注意到这个[^>]?作为一种替代。 这将匹配格式不正确的标签中的不平衡引号。
它也是正则表达式的所有邪恶之源。 它的使用方式将触发一个碰撞，以满足它的贪婪，必须匹配 量化的容器。
如果被动地使用，就永远不会有问题 但是，如果你通过穿插一些东西来强制匹配 一个需要的属性/值对，并且没有提供足够的保护 从回溯来看，这是一场失控的噩梦。
这是普通旧标签的一般形式。 注意到代表标记名称的[\w:]了吗? 实际上，表示标记名称的合法字符 是一个难以置信的Unicode字符列表。
<
(?:
[\w:]+
\s+
(?:
" [\S\s]*? "
| ' [\S\s]*? '
| [^>]?
)+
\s* /?
)
>
继续前进，我们还看到您不能搜索特定的标记 无需解析所有标记。 我的意思是你可以，但它必须使用的组合 像(*SKIP)(*FAIL)这样的动词，但仍然必须解析所有标签。
原因是标记语法可能隐藏在其他标记中，等等。
因此，要被动地解析所有标签，需要一个如下所示的正则表达式。 这个特殊的匹配不可见内容。
作为新的HTML或xml或任何其他开发的新结构，只需将其添加为 其中一种变化。
网页注释-我从未见过一个网页(或xhtml/xml)，这 有麻烦。如果你找到了，请告诉我。
性能说明-它很快。这是我见过的最快的标记解析器 (也许会更快，谁知道呢)。 我有几个具体的版本。它也是优秀的刮板 (如果你是亲力亲为的类型)。
完成原始正则表达式
<(?:(?:(?:( applet | style |物体|脚本嵌入| | noframes | noscript | noembed) (: \ s + (? > [s \ s] * ?”|’s \ s ]*?'|(?:(?!/>)[^>])?)+)?\ s * >) [s \ ' s] * ? < / 1 \ s *(?=>))|(?:/?[\ w: +] \ s */?)|(?:[\ w: + s + s(?):“\ \ s] * ?’”| [s \ ]*?'|[^>]?)+\ s * / ?) | " s \ \ ? [ ]*?\?|(?:!(?:(?: DOCTYPE [S \ S ]*?)|(?:\[ CDATA [S \ \ S ]*?\]\])|(?:--[\ S \ ]*?--)|(?: ATTLIST [S \ S] *) |(?:实体[S \ S] *) |(?:元素[S \ S] * ?)) >
格式化的看
<
(?:
(?:
(?:
# Invisible content; end tag req'd
( # (1 start)
script
| style
| object
| embed
| applet
| noframes
| noscript
| noembed
) # (1 end)
(?:
\s+
(?>
" [\S\s]*? "
| ' [\S\s]*? '
| (?:
(?! /> )
[^>]
)?
)+
)?
\s* >
)
[\S\s]*? </ \1 \s*
(?= > )
)
| (?: /? [\w:]+ \s* /? )
| (?:
[\w:]+
\s+
(?:
" [\S\s]*? "
| ' [\S\s]*? '
| [^>]?
)+
\s* /?
)
| \? [\S\s]*? \?
| (?:
!
(?:
(?: DOCTYPE [\S\s]*? )
| (?: \[CDATA\[ [\S\s]*? \]\] )
| (?: -- [\S\s]*? -- )
| (?: ATTLIST [\S\s]*? )
| (?: ENTITY [\S\s]*? )
| (?: ELEMENT [\S\s]*? )
)
)
)
>
正则表达式并不是为处理嵌套的标记结构而设计的，要处理真正HTML中可能出现的所有边缘情况，往好里说是复杂的(往坏里说是不可能的)。
就解析而言，正则表达式在“词法分析”(lexer)阶段很有用，在这个阶段，输入被分解成标记。它在实际的“构建解析树”阶段用处不大。
对于HTML解析器，我希望它只接受格式良好的HTML，而这需要正则表达式所不能做到的功能(它们不能“计数”并确保给定数量的开始元素与相同数量的结束元素相平衡)。
