2011-11-29 24 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只是在第二个例子中死亡。 –