我一直在使用 John Gruber 的 URL 正则表达式来匹配非结构化文本消息中的 URL。它在大部分时间都运行得非常好,但我发现了一种情况,在这种情况下,性能会严重下降,具体取决于括号内的内容。
// The URL matching regex.
var urls = /\b((?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]+|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))/ig;
// An example URL that has horrible performance in some modern browsers
var url = "www.linkedin.com/people/~:(id,first-name,last-name,email-address,picture-url,phone-numbers,public-profile-url)";
url.replace(urls, "<a href='$1'>$1</a>");
原始帖子包含正则表达式的多行注释版本,可在此处找到:
http://daringfireball.net/2010/07/improved_regex_for_matching_urls
这是一个 JSFiddle,它围绕这个问题做了一些性能计时:
及其在 Chrome 上的输出:
Gruber URL Regex Performance
www.a.com/:(aaaaaaaaaaaaaa)1 MS
www.a.com/:(aaaaaaaaaaaaaaa)0 MS
www.a.com/:(aaaaaaaaaaaaaaaa)0 MS
www.a.com/:(aaaaaaaaaaaaaaaaa)2 MS
www.a.com/:(aaaaaaaaaaaaaaaaaa)3 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaa)5 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaa)11 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaa)22 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaaa)44 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaaaa)87 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaaaaa)174 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaaaaaa)348 MS
www.a.com/:(aaaaaaaaaaaaaaaaaaaaaaaaaa)704 MS
www.a.com/:(aaaaaaaaaaaa)(aaaaaaaaaaaaa)0 MS
有人能确定是什么导致了某些现代浏览器的匹配时间增加吗?我想要么导致匹配失败,要么以某种方式优化正则表达式。
最佳答案
放弃匹配括号的要求使其更快。应该适用于绝大多数 URL...
m/\b((?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)\S+(?:[^\s`!\[\]{};:'".,?«»“”‘’]))/ig;
关于javascript - 为 Javascript 优化 Gruber URL 正则表达式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17733236/