修复字符串结尾的否定断言答案

【问题标题】：Fixing Negative Assertion for end of string修复字符串结尾的否定断言
【发布时间】：2017-01-21 18:18:35
【问题描述】：

仅当模式匹配并且组结束前没有特定单词时，我才尝试接受捕获组。我尝试了多种方法，但似乎都没有奏效，显然我没有理解这个概念：

无论我做什么，我的捕获组都会捕获一些东西，我的目标是如果拒绝词存在于模式中间，则不返回匹配项。

RC:\*.*?(?P<Capture>(Bob|David|Ted|Alice))(?!Reject).*

捕获名称组应该返回：

所以“拒绝”表示如果发现 NameGroup Capture 后跟任何以 < 结尾的内容，则捕获它，如果在 NameGroup 和 Reject 之间出现不。

【问题讨论】：

regex101.com/r/iP2xY0/5 仅匹配拒绝
@be_good_do_good 谢谢。然而，我正在寻找的是在 String1 中匹配 Bob，在 String2 中匹配 David 而在 String3 中什么都没有。

【解决方案1】：

我建议将您的否定前瞻放在模式的开头。这首先检查您的拒绝词是否存在于您的字符串中，并且只有当它不存在时才会尝试匹配字符串的其余部分：

(?!.*Rejected.*)RC:\*.*?(?P<Capture>(Bob|David|Ted|Alice)).*

【讨论】：

这实际上是可行的，我想因此是“消极的前瞻”:)。我接受了答案，因为它确实是正确的，但是我在使用 Timeouts 时遇到了问题。我有两个“管道”，第一个表示如果没有出现术语，则使用第一个管道的捕获组，如果出现，则使用第二个管道：regex101.com/r/bU6cU6/1，使用您的 neg lookahead 解决方案来限定第一个管道。然而，否定短语实际上在文本中大约有 3k 个字符，并且正在超时regex101.com/r/bU6cU6/2 有没有办法解决这个问题，或者它只是否定前瞻的功能？
超时的奇怪之处在于，正则表达式只需要 32 个步骤就可以发现第一个管道不能自己工作，而 18 个步骤可以发现第二个管道自己工作。所以不确定Regex在做什么会超时。不应该 a) 检查第一个管道，32 步，拒绝，移动到第二个管道，18 步接受吗？
将前瞻放在RC: 之后，以减少不必要的回溯。