與貪婪修飾符內捕捉組

考慮下面的命令奇數行爲：與貪婪修飾符內捕捉組

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。這說，它不是完全貪婪的（即如果它是它會捕獲所有ES）。即使是奇怪的，它實際上仍然匹配模式，即使sub結果暗示.+?塊遺漏了EE，它不能再與正則表達式的其餘部分匹配。這表明在計算匹配子表達式的長度時存在偏移問題，而不是在實際匹配中。

最後一個是完全一樣的，但與PCRE一起運行，並按預期工作。

我錯過了什麼，或者這種行爲沒有文件/馬車？

來源

2014-02-26 BrodieG

這聽起來像一個錯誤在R – nneonneo

發佈爲** [一個bug]（https://github.com/laurikari/tre/issues/21）**在tre github頁面。 – BrodieG

R使用libtre，版本0.8。爲了更加穩定，您應該始終使用perl = TRUE。

注意

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

作品。

來源

2014-02-27 02:16:04

這是我總是這樣做的，但有些東西沒有用'perl = T'標誌（特別是'regexec'）實現。我嘗試使用'regexec'（或者更具體地說，'stringr'中的'str_match_all'/etc。工具依賴於它），我也遇到了實際的錯誤，我同樣可以通過添加'。*'來解決它。在模式之後，儘管對於'sub'示例，它顯然不起作用。今天早上沒有其他人有更多信息我會以此作爲答案。你知道是否有計劃更新圖書館？看起來0.8已經有4年了。 – BrodieG

實際上，看起來像** [TRE庫已更新]（http://cran.r-project.org/bin/windows/base/old/2.15.2/NEWS.R-2.15.2.html ）**（搜索TRE）。 – BrodieG

我修復了我的答案以反映更新。它看起來似乎正在繼續'libtre'的開發。有幾個公開的問題，其中一個是關於R的（https://github.com/laurikari/tre/issues/11）。我認爲這應該作爲R開發團隊的一個缺陷提出來。 –

與貪婪修飾符內捕捉組

回答

相關問題