AdBlock广告拦截插件的实现原理

前端之家收集整理的这篇文章主要介绍了AdBlock广告拦截插件的实现原理前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

在这里,我不会解释太多的代码,没有必要,说说原理就可以了。

AdBlock的广告拦截实际上分为2个部分:

1、对于URL请求的拦截


这一般都是页面中DIV元素嵌入一个IFRMAE/IMAGE元素,然后加载一个广告链接或者GIF图片什么的。

这部分的规则库描述比较复杂。规则大概有几万条,即使对于国内的使用,可能也会有个1000条左右。

不过我觉得没必要搞这么复杂,可以通过提取出最常见的100条,然后用这100条屏蔽80%的请求,就可以了。

这些规则的语法,基本上是对于URL中domain和path的字符串前缀或后缀匹配。可能附带一些额外的属性(理论上说来,这些属性都应该可以从NetworkRequest对象中获取到)

AdBlock Plus的作者实际上是使用JavaScript把这些URL匹配规则映射为了正则表达式,然后再用正则表达式对目标URL进行匹配过滤。

当然,也可以用Java来实现。前面已经说了,正则表达式是基于前缀或者后缀的,前缀可以用Trie树,后缀可以反转后当作前缀处理。

而对于keyword in查询,可以使用基于编译自动机的AC算法(我认为AC算法其实就是一个简化版的 key1|key2|key3|...|keyn 这种形式的正则表达式而已)

一旦匹配上,在shouldOverrideUrlLoading函数里return true;代表已额外处理,实际上不处理,这样就屏蔽了此URL请求。(shouldOverrideUrlLoading主要是用于特殊的scheme协议的,用于URL请求拦截实属误用),好像有额外的shouldIgnoreNetworkRequest


2、对于页面DOM嵌入广告内容的处理

基于规则是,通过CSS3 Selector定位到这些DOM元素,然后设置其display等于none !important。

AdBlock Plus对于页面内容的广告过滤是特定于网站的,也就是说,是对于domain字符串的精确匹配。这里使用一个简单的HashMap性能也就足够可以了。

问题是,有些广告内容是延迟加载的(通过setTimer),对于这部分内容,只能等个几秒钟等广告内容出来之后,才注入执行JS脚本。

当然,这种方法不是很好,最好是在浏览器内核里做一个DOM Mutation事件监控的daemon:如果检测到有新的DOM节点加入,当然必须是在DOM Content Loaded之后,就发送一个通知给客户端,客户端再调度广告屏蔽脚本的重新执行。


上面2类处理看起来有效,实际上无效。设想网站要求用户必须访问广告服务器,以提高一个特殊的cookie,这样才允许用户访问资源。这样第1种方法其实就没用武之地了。对于第2种则更简单,原则上来说,如果把广告跟正常内容混合在一起,你是没办法用计算机算法来区分谁是广告谁是正常内容的,除非用人来维护。或者立法。

从个人角度考虑,某部分广告则让让它下载显示也无不可,如果用户觉得它烦,就提供一个规则添加的UI交互入口。而对于弹窗、闪烁的GIF这类比较恶心的,杀之可也。


1/15更新:

AdBlockPlus做到的优化:假如一个URL为a.b.c,那么这个URL只会跟过滤规则里包含a,或者b,或者c的规则做匹配,后者还是得一个一个的执行JS正则表达式线性匹配

好处就是那些规则中不包含a,b,c的将不会与这个url做匹配。这可能使得把一个10000条规则的总线性扫描降低到了1000条的规模。

但是,它还是没有猎豹浏览器的做法好:AdBlockPlus最终URL与过滤规则的匹配还是用JS正则表达式来执行的(当然,JS里的字符串高级处理都只能用用正则表达式,逐个字符比较对JS代码来说不现实),猎豹对于简单的前缀/后缀匹配可以使用Trie树或AC自动机,但这是基于字符的,只能在Java里执行才有效率。

不过,我想,更有技术含量的,是引入协作式过滤:当用户标明网页中的某个元素属于广告,那么,浏览器内核可以智能地定位到这个DOM元素,并生成一个有效的CSS Selector(这个就是难度之所在了),这样就可以动态地扩展用户的本地过滤规则库,然后再通过上传到云端服务器形成大数据,从中挖掘出公共的广告拦截规则库。
原文链接:https://www.f2er.com/regex/360855.html

猜你在找的正则表达式相关文章