正则表达式：疯狂？

请参考文档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是做什么的？ –

回答