正則表達式：瘋狂？

請參考文檔ABC.123.1234.1234和文件CBA.321.4321

我運行兩個不同的正則表達式搜索，分別確定兩個不同的文件標識符。第一個IDENTIFER表達的偉大工程：

ABC.123.1234.1234 = \b[A-Z]{3}\.\d{1,4}\.\d{1,4}\.\d{1,4}\b

現在，我遇到的問題是，試圖使用下面的表達式來提取較小的標識：

\b[A-Z]{3}\.\d{1,3}\.\d{1,4}\b

不幸的是這兩者都返回結果， ABC.123.1234 & CBA.321.4321。我要求第二個表達式返回的唯一結果是CBA.321.4321。

添加了'vb.net'標記，因爲他在評論我的答案時說過。 –

不確定您使用的是哪個正則表達式系統，因爲它們都有稍微不同的語法。

你想要的是一個否定的zero-width lookahead assertion，以確保你得到你的匹配，並且匹配只有在他們沒有跟在\.[A-Za-z]{4}之後纔算數。

此外，數據中的數字實際上是可變寬度的嗎？如果不是，如果您匹配{4}而不是{1,4}，那麼獲得匹配會更容易。前瞻斷言不會像其他方式那樣容易實現。

儘管如此，您仍然可以實施它們。只需讓您的負面預測匹配\d*\.\d{1,4}（\d*是避免部分匹配的重要部分）。

編輯：

由於您使用VB.Net，下面是在正則表達式執行排除模式斷言的語法：

(?!subexpression)

所以你的正則表達式可能會成爲類似：

\b[A-Z]{3}\.\d{1,4}\.\d{1,4}(?!\d*\.\d{1,4}\b)

刪除較長匹配並處理可變寬度編號的重要部分是：

(?!\d*\.\d{1,4}\b)

2011-11-16 03:37:10

我正在使用VB.net 我已將其更改爲{4}並試圖將\。[A-Za-z] {4}如下所示：「[AZ] {3} \。\ d {3} \。\ d {4} \。[A-Za-z] {4}」仍然沒有。對不起，發現它很難學習更復雜的表達式！:-( –

http://msdn.microsoft.com/en-us/library/az24scfc.aspx –

@DavidCampion：它需要時間。它可能是一個租用用戶 - 友好的語言:) –

如果將其更改爲[A-Z]{3}\.\d{1,3}\.\d{1,4}(!\.)，它會使用負向前視來停止匹配，如果有第三個點，則應該只給出您想要的結果。

2011-11-16 03:36:37 mikel

這樣做的問題是'ABC.123.1234.1234'會與你的正則表達式匹配，因爲最後一組數字是'{1,4}'。這場比賽看起來像：ABC.123.123'4.1234。 –

好點，謝謝。我猜如何解決這個問題，完全取決於他的數據的格式以及它將會變得多麼可能，可能沿[AZ] {3} \。\ d {1,3} \。\ d {1， 4}（？=（\ s | $））。 – mikel

HI米克爾，我已經嘗試過你的建議，現在它沒有返回任何結果。林不知道它是否有助於我的情況，但文件標識符是99％的時間包裹在「」（空間）？有沒有一種方法來識別require模式，但只有在字符串的開始和結尾有空格時才返回結果？（然後又不是說什麼/ bxx/b是做什麼的？ –

回答