2

我正在使用 RegexKitLite，而后者又使用 ICU 作为其引擎。尽管有文档，当搜索“xxxxxxxxxxx”时，像 /x*/ 这样的正则表达式将匹配空字符串。它的行为类似于 /x*?/ 应该。我想在它存在时绕过这个错误，并且我正在考虑将任何未转义的 * 重写为 + 当正则表达式匹配返回 0 长度结果时。我天真的猜测是用 +s 代替 *s 的正则表达式将始终返回正确结果的子集。这会带来什么意想不到的后果？我走对了吗？

FWIW，ICU 还提供了一个 *+ 运算符，但它也不起作用。

编辑：我应该更清楚：这是用于交互式应用程序的搜索字段。我无法控制用户输入的正则表达式。损坏的 * 支持似乎是 ICU 中的一个错误。我当然希望我不需要在我的代码中包含那个 POS，但这是城里唯一的游戏。

4

4 回答 4

1

如果您只是将每个*量词更改为 a +，则正则表达式将无法在* 应该匹配零次出现的情况下工作。换句话说，问题将从总是匹配零变成从不匹配零。如果你问我，无论哪种方式都没有用。

但是，您可能能够单独处理零出现情况，并采用负前瞻。例如，x*可以重写为(?:(?!x)|x+). 我知道这很可怕，但这是我目前能想到的最独立的解决方案。你也必须对占有欲的明星这样做（*+），但不情愿的明星（*?）。

这是表格形式： 

之前 之后
x* (?:(?!x)|x+)
x*+ (?:(?!x)|x++)
X*？X*？
更复杂的原子需要保留自己的括号： 
(?:xyz)* (?:(?!(?:xyz))|(?:xyz)+)
您可能可以将它们放在前瞻中，但除了可读性之外，它们不会损害任何东西，无论如何这都是一个失败的原因。:D 如果{min,}和{min,max}形式也受到影响，它们将得到相同的处理（对所有格变体进行相同的修改）：

x{0,}        与 x* 
x{0, n } (?:(?!x)|x{1, n })相同

我突然想到，条件(?(condition)yes-pattern|no-pattern)句——在这里非常合适；不幸的是，ICU 似乎并不支持他们。

于 2011-02-13T00:31:46.447 回答
1

我不能说有问题的代码哪里出了问题，但我可以自信地说这个特定的错误不在 ICU 库中。（我是ICU正则表达式包的作者。）

我同意上面表达的观点，要做的不是试图通过调整正则表达式模式来解决问题，而是要了解潜在的问题是什么。可能会犯一些简单的错误，从提出的原始问题中不清楚。

于 2011-02-24T00:46:39.700 回答
0

是的，使用该策略：（
伪代码）

if ($str =~ /x*/ && $str =~ /(x+)/) { print "'$1'\n"; }

但真正的问题是你所说的BUG。为什么量词的基本结构搞砸了？这不是您应该包含在代码中的模块。

于 2011-02-12T23:48:43.017 回答
0

两者\*和[*]都是字面星号，因此天真的替换可能行不通。

其实不要做动态重写，太复杂了。首先尝试静态调整您的正则表达式。

x*等价于x{0,}和(?:x+)?。

于 2011-02-12T22:32:41.557 回答