我正在使用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