我正在使用RegexKitLite，后者又将ICU用作其引擎。尽管有文档，但在搜索“xxxxxxxxxxx”时，类似于/ x * /的正则表达式将匹配空字符串。它表现得像/ x *？/ should。我想绕过这个错误，当它出现时，我正考虑在正则表达式匹配返回0长度结果时重写任何未转义的* as +。我天真的猜测是，带有+ s的正则表达式总是会返回正确结果的子集。这有什么意想不到的后果？我正确的方式吗？修复正则表达式以解决ICU/RegexKitLite问题
FWIW，ICU也提供* +操作符，但它也不起作用。
编辑：我应该已经更清楚了：这是一个交互式应用程序的搜索领域。我无法控制用户输入的正则表达式。破碎的*支持似乎是ICU中的一个错误。我当然希望我不需要在我的代码中包含该POS，但它是镇上唯一的游戏。
如果单纯改变每*量词为+，正则表达式将无法在该*应该匹配了零个发生这些情况下工作。换句话说，问题将从变化为始终匹配零到从未匹配零。如果你问我，这两种方法都没用。
但是，您可能能够分别处理零事件情况，并带有负向预测。例如，x*可以重写为(?:(?!x)|x+)。我知道这很可怕，但它是我现在可以设想的最独立的解决方案。你也必须为所有格的星星做这个（*+），但不是不情愿的星星（*?）。
这是表格形式：
BEFORE AFTER x* (?:(?!x)|x+) x*+ (?:(?!x)|x++) x*? x*?更复杂的原子都需要有自己的括号保留：
(?:xyz)* (?:(?!(?:xyz))|(?:xyz)+)你也许可以把它们先行里面，但只要不伤害除了可读性任何东西，这是一个失去的无论如何。：d如果
{min,}和
{min,max}形式受到太大，他们将得到同样的待遇（与占有欲变种相同的修改）：
x{0,} same as x*
x{0,n} (?:(?!x)|x{1,n})
它发生，我认为conditionals-- (?(condition)yes-pattern|no-pattern) --would是一个完美的适合在这里;不幸的是，ICU似乎不支持他们。
\*和[*]都是字面星号，所以天真的替换可能不起作用。
事实上，不要做动态重写，它太复杂了。尝试先静态调整你的正则表达式。
x*相当于x{0,}和(?:x+)?。
对，使用该策略：
（伪码）
如果（$海峡=〜/ X */& & $ STR =〜/（X +）/）{ 打印“ '$ 1' \ N“; }
但是真正的问题在于你说的BUG。为什么地球上量词的基本构造被搞砸了？这不是您应该包含在代码中的模块。
我不能说有问题的地方可能出现问题，但我可以放心地说，这个特定的错误不在ICU库中。 （我是ICU正则表达式包的作者。）
我同意上面表达的观点，要做的事情不是试图通过调整正则表达式模式来解决问题，而是要了解根本问题是。可能存在一些简单的错误，从原来提出的问题中不清楚。
您正在使用什么版本的ICU/RegexKitLite？文档的哪一部分会导致您期望获得不同的结果？ – 2011-02-14 17:55:03
我试过Linux上的ICU 4.2以及MacOS（3.6，我认为）。我希望*是贪婪的，因为ICU医生为*操作员说：“匹配0次或更多次，尽可能匹配。”请参阅此pdf的第112页：http：//icu-project.org/userguide/icu.pdf – George 2011-02-15 06:38:17
该PDF已过时。我将删除它。 http://userguide.icu-project.org/是当前的用户指南。 – 2011-02-15 16:16:00