c# - 将正则表达式语法扩展为 'does not contain text XYZ'

Question

我有一个应用程序，用户可以在其中多个地方指定正则表达式。这些在运行应用程序时用于检查文本(例如 URL 和 HTML)是否与正则表达式匹配。通常用户希望能够说出文本匹配 ABC 和不匹配 XYZ 的位置。为了让他们更容易做到这一点，我正在考虑在我的应用程序中扩展正则表达式语法，用一种方式说“并且不包含 ”。图案 '。关于做到这一点的好方法有什么建议吗？

我的应用程序是用 C# .NET 3.5 编写的。

我的计划(在我得到这个问题的真棒答案之前......)

目前我正在考虑使用 ¬ 字符:在 ¬ 字符之前的任何内容都是正常的正则表达式，在 ¬ 字符之后的任何内容都是在要测试的文本中无法匹配的正则表达式。

所以我可能会使用一些像这样(人为的)例子的正则表达式:

on (this|that|these) day(s)?¬(every|all) day(s) ?

例如，这将匹配“男人说的这一天......”但不会匹配“这一天以及之后的每一天......”。

在我处理正则表达式的代码中，我将简单地拆分正则表达式的两部分并分别处理它们，例如:

    public bool IsMatchExtended(string textToTest, string extendedRegex)
    {
        int notPosition = extendedRegex.IndexOf('¬');

        // Just a normal regex:
        if (notPosition==-1)
            return Regex.IsMatch(textToTest, extendedRegex);

        // Use a positive (normal) regex and a negative one
        string positiveRegex = extendedRegex.Substring(0, notPosition);
        string negativeRegex = extendedRegex.Substring(notPosition + 1, extendedRegex.Length - notPosition - 1);

        return Regex.IsMatch(textToTest, positiveRegex) && !Regex.IsMatch(textToTest, negativeRegex);
    }

关于实现这种扩展的更好方法的任何建议？我需要更聪明地拆分 ¬ 字符上的字符串以允许对其进行转义，因此不会只使用上面的简单 Substring() 拆分。还有什么要考虑的吗？

替代计划

在写这个问题时，我也遇到了 this answer这建议使用这样的东西:

^(?=(?:(?!negative pattern).)*$).*?positive pattern

所以我可以建议人们使用一种模式，而不是我原来的计划，当他们不想匹配某些文本时。

这会和我原来的计划一样吗？我认为这是一种非常昂贵的执行方式，因为我有时会解析大型 html 文档，这可能是一个问题，而我认为我的原始计划会更高效。任何想法(除了显而易见的:“尝试并测量它们!”)？

可能与性能有关:有时文本中会出现几个“单词”或更复杂的正则表达式，例如上面示例中的 (every|all)，但还有一些变化。

为什么!？

我知道我原来的方法看起来很奇怪，例如为什么不只有两个正则表达式!？但是在我的特定应用程序中，管理员提供了正则表达式，并且很难让他们能够在当前可以提供一个正则表达式的任何地方提供两个正则表达式。在这种情况下，使用 NOT 的语法要容易得多 - 在这一点上相信我。

我有一个应用程序，可以让管理员在不同的配置点定义正则表达式。正则表达式仅用于检查文本或 URL 是否匹配特定模式；不进行替换，也不使用捕获组。但是，他们通常希望指定一个模式，说明“文本中没有 ABC”。在正则表达式中做 NOT 匹配是出了名的困难，所以通常的方法是有两个正则表达式:一个指定必须匹配的模式，一个指定必须不匹配的模式。如果第一个匹配而第二个不匹配，则文本匹配。在我的应用程序中，在用户现在可以提供的每个位置添加第二个正则表达式的功能需要做很多工作，所以我想扩展正则表达式语法，用一种方式说“ ”并且不包含
图案 '。

Answer 1

您不需要引入新符号。大多数正则表达式引擎已经支持您所需的内容。这只是学习和应用它的问题。

您担心性能问题，但您是否对其进行了测试？您是否测量并证明了这些性能问题？它可能会很好。

正则表达式在许多不同的场景中适用于许多人。它也可能符合您的要求。

此外，您在另一个 SO 问题中发现的复杂正则表达式可以简化。消极和积极的前瞻和后视有简单的表达。?! ?<! ?= ?<=
一些例子

假设示例文本是 <tr valign='top'><td>Albatross</td></tr>
鉴于以下正则表达式，这些是您将看到的结果:

tr - 匹配

td - 匹配

^td - 不匹配

^tr - 不匹配

^<tr - 匹配

^<tr>.*</tr> - 不匹配

^<tr.*>.*</tr> - 匹配

^<tr.*>.*</tr>(?<tr>) - 匹配

^<tr.*>.*</tr>(?<!tr>) - 不匹配

^<tr.*>.*</tr>(?<!Albatross) - 匹配

^<tr.*>.*</tr>(?<!.*Albatross.*) - 不匹配

^(?!.*Albatross.*)<tr.*>.*</tr> - 不匹配

说明

前两个匹配，因为正则表达式可以应用于示例(或测试)字符串中的任何位置。后两个不匹配，因为 ^ 表示“从头开始”，并且测试字符串不以 td 或 tr 开头 - 它以左尖括号开头。

第五个示例匹配，因为测试字符串以 <tr 开头。
第六个不是，因为它希望示例字符串以 <tr> 开头，在 tr 之后紧跟一个右尖括号，但在实际测试字符串中，开头的 tr 包含 valign 空格属性，因此 079145 之后是 079145第 7 个正则表达式显示了如何使用通配符允许空格和属性。

第 8 个正则表达式使用 tr 对正则表达式的末尾应用正向后视断言。它说，只有当测试字符串中光标之前的内容与括号中的内容匹配时，才匹配整个正则表达式，紧跟在 ?< 之后。在这种情况下，接下来是 ?< 。评估 ``^.* tr> tr>` 后，匹配测试字符串的结尾，结果为 TRUE。因此，正向后视评估为真，因此整体正则表达式匹配。

第九个例子展示了如何使用 , the cursor in the test string is positioned at the end of the test string. Therefore, the 插入一个否定的lookbehind断言。基本上它说“如果此时光标后面的内容与括号中 ?<! 后面的内容不匹配，则允许正则表达式匹配，在这种情况下为 ?<! 。断言之前的正则表达式位 tr> 匹配到并包括字符串的结尾。因为模式 ^<tr.*>.*</tr> 确实匹配了字符串的结尾。但这是一个否定断言，因此它的计算结果为 FALSE，这意味着第 9 个示例不匹配。

第 10 个示例使用另一个否定的后视断言。基本上它说“如果此时光标后面的内容与括号中的内容不匹配，则允许正则表达式匹配，在这种情况下为 tr> 。断言之前的正则表达式位 Albatross 匹配到并包括结尾字符串。检查“信天翁”与字符串的末尾会产生否定匹配，因为测试字符串以 ^<tr.*>.*</tr> 结尾。因为否定后视的括号内的模式不匹配，这意味着否定后视评估为 TRUE，这意味着第 10 个例子是一场比赛。

第 11 个示例扩展了负向后视以包含通配符；在英语中，负向后视的结果是“仅当前面的字符串不包含信天翁这个词时才匹配”。在这种情况下，测试字符串 DOES 包含单词，否定的lookbehind 评估为 FALSE，并且第 11 个正则表达式不匹配。

第 12 个示例使用否定前瞻断言。与lookbehinds一样，lookaheads是零宽度的——它们不会为了字符串匹配而在测试字符串内移动光标。在这种情况下，先行会立即拒绝该字符串，因为 </tr> 匹配；因为它是一个负面的前瞻，它的计算结果为 FALSE，这意味着整个正则表达式无法匹配，这意味着对测试字符串的正则表达式的评估在那里停止。

示例 12 总是计算出与示例 11 相同的 bool 值，但它在运行时的行为不同。在 ex 12 中，首先执行否定检查，立即停止。在 ex 11 中，在检查后视断言之前，应用了完整的正则表达式，并评估为 TRUE。因此，您可以看到在比较前瞻和后视时可能存在性能差异。哪一个适合您取决于您​​匹配的是什么，以及“正匹配”模式和“负匹配”模式的相对复杂性。

有关此内容的更多信息，请阅读 http://www.regular-expressions.info/

或者获取正则表达式评估器工具并尝试一些测试。

像这个工具:


source and binary