贪婪的量词

2018-06-27 12:29:01

我正在读K.Sierra并发现以下错误：

贪婪的量词实际上读取整个源数据，然后它向后（从右边）工作，直到找到最右边的匹配。在这一点上，它包含了源数据之前的所有内容以及包含最右边匹配数据的数据。

现在，假设我们有一个来源如下：

"proj3.txt,proj1sched.pdf,proj1,proj2,proj1.java"

和模式： proj1([^,])*

为什么它不符合整个文本？贪婪它应该匹配最右边的“proj1.java”，返回的匹配应该是最右边最匹配之前的整个源码？相反，它会返回：

proj1sched.pdf
proj1
proj1.java

为什么它不符合整个文本？

因为你声明它必须以proj1开头

贪婪它应该匹配最右边的“proj1.java”

正确。

并且返回的比赛应该是最右边最匹配之前的整个来源？

不知道为什么你会这么想，或者为什么这会有用。你可以做.*proj1.*如果这是你想要的。

为什么它不符合整个文本？

哦，它试过了。但它发现序列p ， r ， o ， j ， 1在一个点上，然后继续查找零个或多个字符不是逗号，因此匹配. ， p ， d ， f 。它停在那里，因为下一个字符，逗号，不匹配[^,] 。

请注意，下一个匹配尝试将从下一个字符开始，即r ，依此类推直到找到p ; 当它找到一个时，它会尝试r等等。

整个正则表达式得到满足，引擎决定它是成功的，并没有尝试任何进一步的，即使有超过这一点的比赛。

因此匹配的文本是proj1.pdf 。而不是整个输入。正则表达式很懒，它们只匹配他们需要匹配的东西，永远不会进一步。

但。这就是它变得有趣的地方。有些引擎不能这样工作。

考虑正则表达式cat(|flap)和输入文本catflap 。 POSIX已经在正则表达式引擎中做出了决定，并且规定正则表达式引擎应该匹配最左边最长的匹配。

所以，如果一个正则表达式引擎服从POSIX，它应该匹配catflap 。但是现存的大部分正则表达式引擎只能匹配cat ：空的替换匹配首先，正则表达式满足，故事结束！

现在，问题的核心：量词有三种类型，贪婪，懒惰和占有欲：

贪婪：默认， * ;

懒惰，又被滥用： *? ;

所有格： *+ 。

一个贪婪的量词会尝试尽可能多地匹配文本，只有在必要时才会给予回馈; 一个懒惰的量词会尝试尽可能少地匹配文本; 一个占有量词将尽可能地匹配尽可能多的文本，并且不会给文本返回。

插图：这里是输入文字：

The answer to everything is 42, says the mouse

这里有三个正则表达式来匹配这个文本和一个捕获组：

.*(d+) （贪婪）;

.*?(d+) （懒惰）;

.*+(d+) （所有格）。

问题：这些表达式在每个表达中将会捕获什么？回答：

第一个： 2 ;

第二： 42 ;

第三：甚至不会匹配文本！ .*+会吞噬一切，但不会放弃， d+因此留下没有任何可匹配的东西，正则表达式失败。

我们有proj1([^,])*其中 -

([^,])*表示它将连接任何字符组合（零次或多次出现）的子字符串，它不包含char'，'与字符串“proj1”，如“sched.pdf”或“ “或”.java“全部三个不包含'，'字符。因此，结果。

链接地址: http://www.djcxy.com/p/76931.html