2011-11-29 54 views
3

最近,我開始在我的Rails模型中使用來自JQuery validation插件的電子郵件驗證正則表達式。正則表達式在Ruby中與JavaScript相比表現不佳

EMAIL_REGEXP=/^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))$/i 

"[email protected]".match EMAIL_REGEXP # returns immidiately 
"[email protected]".match EMAIL_REGEXP # takes a long time 

正則表達式採用當一個無效電子郵件已經許多圓點分隔的標記長的時間(延續:[email protected])。同樣的表達works without JavaScript中任何明顯的延遲。

爲什麼Ruby和JavaScript正則表達式解析器在性能上有這樣的差異?有什麼我可以做的,以提高響應時間?

我在Ruby 1.8.7上。我在Ruby 1.9.2上看不到相同的問題。

注意

我知道REG-EXP長。由於它被jQuery使用,我想過使用它。我可以隨時將其更改回更簡單的正則表達式,如here所示。我的問題主要是找出爲什麼同樣的正則表達式在JS中快得多的原因。

參考:

JQuery Validation Plugin Source

Sample form with jQuery email validation

+2

這是一個巨大的正則表達式。你爲什麼不使用電子郵件解析器? – Blender

+0

@如果你提供了一個鏈接,Blender的評論質量會大大提高 – tekknolagi

+2

這個正則表達式來自官方的'jQuery'插件,它被廣泛使用。所以我認爲這是一條安全的路線。如果我無法使RegExp正常工作,我可能會走自定義驗證的路線。 –

回答

1

不知道爲什麼1.8.7的正則表達式解析器比1.9.2中的JS或Oniguruma的解析器慢得多,但可能是這個特定的正則表達式可以受益於包裝其前綴,包括@符號與原子組像即:在這種情況下

EMAIL_REGEXP =/
^
    (?>((# atomic group start 
    ([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+ 
    (\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)* 
    ) 
    | 
    (
    (\x22) 
    (
     (((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)? 
     (
     ([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
     | 
     (\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])) 
     ) 
    )* 
    (((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)? 
    (\x22) 
    ) 
) 
    @) # atomic group end 
    (
    (
     ([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
     | 
     (
     ([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
     ([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])* 
     ([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
    ) 
    ) 
    \. 
)+ 
    (
    ([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
    | 
    (
     ([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
     ([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])* 
     ([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]) 
    ) 
) 
    $ 
    /xi 

puts "[email protected]".match EMAIL_REGEXP # returns immediately 
puts "[email protected]".match EMAIL_REGEXP # takes a long time 

原子團應防止解析器匹配以後的部分時,返回的字符串的第一部分@符號失敗。它顯着提高了速度。雖然,我不是100%肯定它不會破壞正則表達式邏輯,所以我會很感激任何意見。

另一件事是使用非捕獲組,當你不需要對組進行反向引用時應該更快一些,但是在這種情況下他們沒有給出任何明顯的改進。

1

的問題可能是你的正則表達式中包含一個貪婪的量詞,使紅寶石那些量詞需要嘗試檢查所有組合。解決方案可能是使用Possessive Quantifiers,所以查找應該更快,但它會改變正則表達式,因此一些字符串將不再匹配。簡短的例子(維基百科):

'aaaaaaaaaaaaaaaaaaaaaaaaa' =~ /(a+a+)/ => match 
'aaaaaaaaaaaaaaaaaaaaaaaaa' =~ /(a++a+)/ => not match 

的differense是在查找過程和貪婪量詞引擎試圖查找回來,如果不匹配,在佔有慾量詞的情況下,發動機從來沒有回頭看。

+0

我期待正則表達式由於貪婪的量詞而變慢。令我驚訝的是同一個reg-exp在JS和Ruby執行時間之間的性能差異。 –

+1

我嘗試過[tryruby](http://tryruby.org/)中的exmaple,代碼執行沒有大的延遲。順便說一下,第二個字符串dosnt匹配。 –

+0

Tryruby使用1.9.2有新的正則表達式引擎,並處理這個正則表達式非常好。另一方面,1.8.7只是在第二個例子中死亡。 –