捕获组内的贪婪修饰符的奇怪行为答案

【问题标题】：Odd Behavior with Greedy Modifiers Inside Capture Groups捕获组内的贪婪修饰符的奇怪行为
【发布时间】：2014-03-30 03:30:32
【问题描述】：

考虑以下命令：

text <- "abcdEEEEfg"

sub("c.+?E", "###", text)
# [1] "ab###EEEfg"                          <<< OKAY
sub("c(.+?)E", "###", text)
# [1] "ab###EEfg"                           <<< WEIRD
sub("c(.+?)E", "###", text, perl=T)
# [1] "ab###EEEfg"                          <<< OKAY

第一个完全符合我的预期，基本上只匹配第一个 E。第二个应该基本上与第一个相同，因为我所做的只是添加一个捕获组（尽管我没有使用它），但由于某种原因，它捕获了一个额外的 E。也就是说，它并不是完全贪婪的（即，如果它是，它会捕获所有的 E）。更奇怪的是，它实际上仍然匹配模式，即使sub 结果表明.+? 部分被遗漏了EE，它不能再被正则表达式的其余部分匹配。这表明在计算匹配子表达式的长度时存在偏移问题，而不是在实际匹配中。

最后一个完全相同，但使用 PCRE 运行，并且按预期工作。

是我遗漏了什么还是这种行为没有记录/有问题？

【问题讨论】：

这闻起来像 R 中的一个错误。
在 Tre github 页面上以 a bug 的身份发布。

标签： regex r posix-ere

【解决方案1】：

R 使用 libtre，版本 0.8。为了更稳定，您应该始终使用perl = TRUE。

注意

sub("c(.+?)E?", "###", text)

有效。

【讨论】：

这是我一直在做的事情，但有些事情没有用perl = T 标志（特别是regexec）实现。我在尝试使用regexec（或者更具体地说，依赖它的stringr 中的str_match_all/etc.工具）时出现了我的实际错误，我同样能够通过在之后添加.* 来解决它该模式，尽管对于sub 示例，它显然不起作用。到早上没有其他人有更多信息，我会以此为答案。你知道是否有更新图书馆的计划吗？看起来 0.8 已经存在 4 年了。
其实看起来像TRE library has already been updated（搜索TRE）。
我修正了我的答案以反映更新。 libtre 上似乎没有继续开发。有几个未解决的问题，one 其中与 R 有关。我认为这应该作为 R 开发团队的错误提出。
我将此提交给 R 并收到包装建议我将其提交给 TRE。我也将它提交给了 laurikari，尽管我怀疑你是对的，你链接的是同一个问题。