扩展正则表达式是否支持反向引用？答案

【问题标题】：Do extended regexes support back-references?扩展正则表达式是否支持反向引用？
【发布时间】：2012-11-10 14:41:29
【问题描述】：

Wikipedia says 扩展正则表达式“放弃了对反向引用的支持”，因此必须使用“基本”正则表达式模式来启用这些。但是，似乎许多实现确实支持扩展正则表达式的反向引用。例如，Ubuntu Precise 上的 gcc 4.6 支持它们。 FreeBSD 实现 seem to 仅在基本模式下支持它们。

Boost says（并且似乎同意维基百科）扩展的正则表达式不支持反向引用，但 Boost::Regex 将它们作为扩展添加。

这只是标准中定义不明确的部分，每个实现都有不同的解释吗？

【问题讨论】：

维基百科并不总是可靠信息的最佳来源。我认为没有理由在任何实现/环境中的扩展正则表达式中不支持反向引用。 POSIX 标准不支持扩展正则表达式的反向引用，但我不知道任何遵循这个“标准”的实现。
+Ωmega 显然 FreeBSD 实现确实遵循这一点。阅读“re_format”手册页，添加了一个特殊的“增强”模式以支持扩展模式下的反向引用
FreeBSD 中的egrep 似乎支持它们。
OpenBSD，OTOH，似乎只保留对 BRE（基本正则表达式）的反向引用

标签： c regex posix

【解决方案1】：

正如其他人已经指出的那样，很明显 POSIX ERE 不支持反向引用。

OpenGroup Base Specifications Issue 7 中给出的不向 ERE 添加反向引用的理由如下：

有人建议，除了区间表达式，还应将反向引用 ('\n') 添加到 ERE。这被标准开发人员拒绝，因为这可能会降低共识。

引用自：Rationale: Base Definitions: Extended Regular Expressions

此限制的主要原因是允许将 POSIX ERE 转换为确定性有限自动机 (DFA)，实际上 Unix 中 ERE 的原始实现是作为 DFA 完成的。使用 DFA 可以保证实现的性能。与（无限数量的）反向引用的模式匹配是一个 NP 难题，甚至可能是一个 NP 完全问题。如果为 ERE 提议反向引用，那么 POSIX 标准委员会将永远无法达成共识，因为这将迫使所有使用原始 Unix 实现的公司将其代码更改为非确定性实现并放弃其性能保证，并且一些这些公司中有委员会成员。

还注意到，RE 中的反向引用对于用户或实施者来说都不直观，而且实际上它们比现在更经常引起极度混乱。例如参见RE-Interpretation: The Dark Corners中给出的示例

注意： RE 中的反向引用与 sed 等工具中替换文本中对子模式的引用不同。

【讨论】：

【解决方案2】：

根据IEEE/Open Group standard，扩展正则表达式不支持反向引用（第 9.5.1 节），尽管一些实际实现支持。

【讨论】：

【解决方案3】：

根据POSIX.1-2008 standard，只有基本正则表达式支持反向引用。 Section 9.3.6 描述了它们在 BRE 中的工作方式。扩展正则表达式部分根本没有提及它们，9.5.1 部分中的Grammar Lexical Conventions 表示反向引用标记仅适用于 BRE。

【讨论】：