相關(guān)關(guān)鍵詞
關(guān)于我們
最新文章
- PHP中opcode緩存簡(jiǎn)單用法分析
- thinkPHP控制器變量在模板中的顯示方法示例
- PHP move_uploaded_file() 函數(shù)(將上傳的文件移動(dòng)到新位置)
- dirname(__FILE__)的含義和應(yīng)用說明
- thinkPHP5框架實(shí)現(xiàn)分頁查詢功能的方法示例
- PHP中單雙號(hào)與變量
- PHP獲得當(dāng)日零點(diǎn)時(shí)間戳的方法分析
- Laravel ORM對(duì)Model::find方法進(jìn)行緩存示例詳解
- PHP讀寫文件高并發(fā)處理操作實(shí)例詳解
- 【CLI】利用Curl下載文件實(shí)時(shí)進(jìn)度條顯示的實(shí)現(xiàn)
正則(PCRE.BACKTRACK_LIMIT)最大回溯/遞歸限制
今天,Tank問了一個(gè)問題, 對(duì)于如下的正則:
/<script>.*?<\/script>/i
當(dāng)要匹配的字符串長(zhǎng)度大于100014的時(shí)候, 就不會(huì)得出正確結(jié)果:
$reg = "/<script>.*?<\/script>/is"; $str = "<script>********</script>"; //長(zhǎng)度大于100014 $ret = preg_replace($reg, "", $str); //返回NULL
難道正則對(duì)匹配的串有長(zhǎng)度限制?
不是, 當(dāng)然不是, 原因是這樣的, 在php的pcre擴(kuò)展中, 提供了倆個(gè)設(shè)置項(xiàng).
pcre.backtrack_limit //最大回溯數(shù) pcre.recursion_limit //最大嵌套數(shù)
默認(rèn)的backtarck_limit是100000(10萬).
這個(gè)問題, 就和設(shè)置項(xiàng)backtrack_limit有關(guān)系. 現(xiàn)在要弄清這個(gè)問題的原因, 關(guān)鍵就是什么是”回溯”.
這個(gè)正則, 使用非貪婪模式, 非貪婪模式匹配原理簡(jiǎn)單來說是, 在可配也可不配的情況下, 優(yōu)先不匹配. 記錄備選狀態(tài), 并將匹配控制交給正則表達(dá)式的下一個(gè)匹配字符, 當(dāng)之后的匹配失敗的時(shí)候, 再溯, 進(jìn)行匹配.
舉個(gè)例子:
源字符串: aaab正則: .*?
匹配過程開始的時(shí)候, “.*?”首先取得匹配控制權(quán), 因?yàn)槭欠秦澙纺J? 所以優(yōu)先不匹配, 將匹配控制交給下一個(gè)匹配字符”b”, “b”在源字符串位置1匹配失敗(“a”), 于是回溯, 將匹配控制交回給”.*?”, 這個(gè)時(shí)候, “.*?”匹配一個(gè)字符”a”, 并再次將控制權(quán)交給”b”, 如此反復(fù), 最終得到匹配結(jié)果, 這個(gè)過程中一共發(fā)生了3次回溯.
現(xiàn)在我們來看看文章開頭的例子, 默認(rèn)的backtrack_limit是100000, 而源字符串的開頭是9個(gè)字符, 一共是99997個(gè)字符.
另外, 因?yàn)閙atch函數(shù)自身的邏輯, 在文章開頭的例子下, 會(huì)導(dǎo)致回溯計(jì)數(shù)增3(有興趣的可以參看pcrelib/pcre_exec.c中match函數(shù)邏輯部分), 所以在匹配到”“之前, pcre中的回溯計(jì)數(shù)剛好是100000,于是就正常匹配, 退出.
而, 只要在增加一個(gè)字符, 就會(huì)導(dǎo)致回溯計(jì)數(shù)大于100000, 從而導(dǎo)致匹配失敗退出.
在php 5.2以后, 提供了:
int preg_last_error ( void )Returns the error code of the last PCRE regex execution.
我們應(yīng)該經(jīng)常檢查這個(gè)函數(shù)的返回值, 當(dāng)不為零的時(shí)候說明上一個(gè)正則函數(shù)出錯(cuò), 特別的對(duì)于文章的例子, 出錯(cuò)返回(PREG_BACKTRACK_LIMIT_ERROR)
最后, 在順便說一句, 非貪婪模式導(dǎo)致太多回溯, 必然會(huì)有一些性能問題, 適當(dāng)?shù)脑搶懴抡齽t, 是可以避免這個(gè)問題的. 比如將文章開頭例子中的正則修改為:
/<script>[^<]*<\/script>/i
就不會(huì)導(dǎo)致這么多的回溯了~
而recursion_limit限制了最大的正則嵌套層數(shù), 如果這個(gè)值, 設(shè)置的太大, 可能會(huì)造成耗盡??臻g爆棧. 默認(rèn)的100000似乎有點(diǎn)太大了…
就比如對(duì)于一個(gè)長(zhǎng)度為10000的字符串, 如下這個(gè)看似”簡(jiǎn)”的單正則:
//默認(rèn)recursion_limit為100000 $reg = /(.+?)+/is; $str = str_pad("laruence", 10000, "a"); //長(zhǎng)度為1萬 $ret = preg_repalce($reg, "", $str);
會(huì)導(dǎo)致core, 這是因?yàn)榍短滋? 導(dǎo)致爆棧.
當(dāng)然, 你可以通過修改棧的大小來暫時(shí)的解決這個(gè)問題, 比如修改??臻g為20M以后, 上面的代碼就能正常運(yùn)行, 但這肯定不是最完美的解法. 根本之道, 還是優(yōu)化正則.
最后: 正則雖易, 用好卻難.. 尤其在做大數(shù)據(jù)量的文本處理的時(shí)候, 如果正則設(shè)計(jì)不慎, 很容易導(dǎo)致深度嵌套, 另外考慮到性能, 還是建議能用字符串處理盡量使用字符串處理代替.
用正則表達(dá)式匹配頁面內(nèi)容時(shí)(preg_match(‘/</head>(.*)</html>/isU’,$str)),發(fā)現(xiàn)有時(shí)能正常匹配,有時(shí)不能,可分析頁面結(jié)構(gòu),發(fā)現(xiàn)沒有變化,唯一變化的是頁面大小。
原因:PHP對(duì)正則表達(dá)式匹配長(zhǎng)度是用限制的,用phpinfo可以看到如下
pcre.backtrack_limit 100000 100000
pcre.recursion_limit 100000 100000
發(fā)現(xiàn)只有100K,如果是抓Web頁面的話肯定不夠的,其實(shí)只要在php.ini上做相應(yīng)設(shè)置就行了(或者改變這兩個(gè)值的大?。?br />
pcre.backtrack_limit=-1
pcre.recursion_limit=-1
附說明:
[Pcre]
;Perl兼容正則表達(dá)式模塊
pcre.backtrack_limit = 100000
; PCRE的最大回溯(backtracking)步數(shù)。
pcre.recursion_limit = 100000
; PCRE的最大遞歸(recursion)深度。
; 如果你將該值設(shè)的非常高,將可能耗盡進(jìn)程的棧空間,導(dǎo)致PHP崩潰。
改為-1或者非常大 是有風(fēng)險(xiǎn)的 如果正則寫了無限遞歸的 php很容易崩潰
參考文章:
http://www.laruence.com/2010/06/08/1579.html