修复正则表达式以解决 ICU/RegexKitLite 错误

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

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

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

如果你简单地改变每一个*量词 a+，正则表达式在以下情况下将无法工作* should匹配次数为零。换句话说，问题将从always匹配零到never匹配零。如果你问我，这两种方法都没用。

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

这是表格形式：

BEFORE       AFTER
x*           (?:(?!x)|x+)
x*+          (?:(?!x)|x++)
x*?          x*?  

More complex atoms would need to have their own parentheses preserved:

(?:xyz)*     (?:(?!(?:xyz))|(?:xyz)+)  

You could probably drop them inside the lookahead, but they don't hurt anything except readability, and that's a lost cause anyway. :D If the {min,} and {min,max} forms are affected too, they would get the same treatment (with the same modifications for possessive variants):

x{0,}        same as x*
x{0,n}       (?:(?!x)|x{1,n})  

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