“向后断言必须是固定长度”的技术原因是什么？在正则表达式中？

Question

例如，下面的正则表达式将导致失败报告lookbehindassertion is not fixed length：

#(?<!(?:(?:src)|(?:href))=["\']?)((?:https?|ftp)://[^\s\'"<>()]+)#S

lookahead不存在这种限制。

Answer 1

Lookahead 和 Lookbehind 并不像它们的名字所暗示的那么相似。前瞻表达式的工作方式与独立正则表达式完全相同，只是它锚定在当前匹配位置并且不消耗其匹配的内容。

Lookbehind 是一个完全不同的故事。从当前匹配位置开始，它一次一个字符地向后遍历文本，尝试匹配每个位置的表达式。如果无法匹配，则回溯必须一直走到文本的开头（记住，一次一个字符），然后才会放弃。将其与前瞻表达式进行比较，后者仅应用一次。

当然，这过于简单化了，并不是所有的口味都这样，但你明白了。后视的应用方式与先行的应用方式根本不同（而且效率低得多）。只有限制回溯必须向后看多远才有意义。

Answer 2

PCRE 不支持浮动lookbehind，因为它可能会导致严重的性能问题。这是因为缺乏从右到左的匹配能力：PCRE只能从固定的左侧开始分支，但可变长度lookbehind的左侧不能固定。

一般来说，如果可能的话，尝试将后视部分分支为固定长度的模式。例如，不要使用：

(?<=(src|href)=")etc.

(1)，而是使用：

(?:(?<=src=")|(?<=href="))etc.

(2) 或使用 \K：

(src|href)="\Ketc.

请注意 \K 不是真正的后向查找，因为它总是在上一场比赛结束时开始搜索（没有可能回退到上一场比赛）。

(3) 在某些复杂的仅向后查找的情况下，您可以使用反向字符串中的“反向”先行表达式进行搜索。不太优雅但有效：

.cte(?="=(ferh|crs))

Answer 3

首先，并非所有正则表达式库（如 .NET）都是如此。

对于 PCRE，原因似乎是：

lookbehind的实现
对于每个替代方案，断言是
暂时移动当前
按固定宽度向后定位并
然后尝试匹配。

（至少，根据 http://www.autoitscript.com/autoit3/pcrepattern.html）。

Answer 4

我遇到了同样的问题并使用 (?: subexpression) 修复了它

定义非捕获组。例如 Write(?:Line)? "WriteLine" 中
“Console.WriteLine()”在“Console.Write(value)”中“写入”

我必须更改下面的正则表达式，该正则表达式应该在 、 或 中的某些内容之前捕获给我后行断言的字符串的开头不是固定长度。

(?<=,|^)

有了这个，

(?:(?<=,)|^)

Answer 5

grep -P '(?<=((three)|(one)) )two' <<< "one two three three two one"
grep: lookbehind assertion is not fixed length

grep -P '((?<=(three) )|(?<=(one) ))two' <<< "one two three three two one"
one two three three two one

为了处理效率PCRE不支持从右到左匹配或递归。当进行后向 PCRE 搜索任何先前匹配字符串的末尾时 - 实现可变大小匹配将需要递归并降低效率。请参阅：查看断言背后