刚刚在prox45j下测试,没有使用sidki规则,的确,不用免过滤donw_a.js就完美去广告了,谢谢Ray4提醒!如果你过滤了adlist,就不必免过滤donw_a.js了,你可以试试。
另外要说明的是第二条的$TYPE(js),sidki的规则应该修正了的,我需要用$TYPE(htm)才能过滤。
哈哈,这个完全是因为我觉得不管通用的规则是否好用,都应该尽可能的了解下在非sidki下如何实现相应操作,毕竟sidki对我来说过于复杂了些,而是否通用的规则却没有关系,通用是面向所有人的,适用自己的可能需要微调。sidki config set的中心思想是提供通用规则,然后通过blockfile对具体site进行调节。用blockfile可以解决的,你偏要另编条规则来解决,这不是舍近求远吗?
这样说吧,如果phoenix没时间给某些问题解答的话,这时候自己利用sidki过滤却找不到好的解决方法,反而不如针对特定站点编写专门的规则,对于自己用则很合适,就像Ray4所说的,最起码去空白上比sidki要好,看起来舒服。
而sidki的关键字体系是面向所有人,即便自己基于sidki填写blockfile也感到理解困难,这规则写得太生猛了,尽管给出了各种blockfile,还是一头雾水的,可能我还得继续了解sidki吧,这就需要时间来沉淀了,自己写规则虽然要好几个,但是基本能把握住其中关窍,理解简单,规则也简单,只是书写看起来有点麻烦,其实不然;与此相对,sidki的blockfile过滤法添加的虽然只是很简单的几个字符,可是涉及的总是一堆一堆的关键字,调用规则也很复杂,又是minimal模式,又是light模式,又是advanced模式,每个模式都激活了不同的规则,相应的关键字组合也有所变化,很头晕,因为至今还没有去了解其运作模式,最最重要的是使用人数很少,如果像微软的视窗,虽然不了解,可是不怕,即使是垮掉了仍可以找到释疑的高手,而Prox则不行,人少到出乎我的想象,碰到问题可以交流的少之又少,不过呢,即使如此,sidki仍是我的默认CFG,毕竟有强大的规则不用却自己费力编辑那就有点虐待自己了,得站在巨人的肩膀上,适当微调适合自己,如此这般,加之力所能及编点简单规则,就算用的人不多交流的更少,但prox用起来放心、舒心,仅此而已!
这个基本了解了,还得实际中碰到的自己逐渐掌握,且根据phoenix给出的使用blockfile添加通用过滤字,即使碰到问题还可以利用debug模式排除故障的方法,现在有了方向也有了信心去尝试sidki的游戏。另一方面,如果要合并下面的项目,在不会放过广告代码的前提下,我们可以考虑使用范围较宽的关键字。
谢谢phoenix解答,前3个我倒是基本理清包含关系,可i_level:1与前3个的关系不明显,i_level:1是一种整体规则的调整,是从standard到minimal,所以和前3个的关系比较范围就很费解了,望指点。即,如果关键字是a_ads或a_adtab或a_adtab_b或i_level:1,则不进行过滤。
关键字之间是或的关系。从过滤的角度,应该选择范围最小的关键字;否则,使用了范围较宽的关键字,有可能在放行正常代码的同时,也放过广告代码。
---
另外,sidki中的那些blocklist,其中可以针对某些站点处理吗?就是不做成通用过滤字而是之前指定$URL(weburl)针对特定网址,这样可以吗?
看到blocklist分了好几组,有点头晕,只用过ADPaths这样的(AdHosts和AdDomains还没区分开呢)和IncludeExclude-U还有默认带的AllowCookies与Bypass-Lists,别的没动过,似乎sidki的帮助过于简单了,Config_Control.txt和Prox_Menu.txt算是主要的帮助了吧,对应blocklist文件里边的例子太复杂了,想偷懒抄袭下都得啃半天,还不一定正确-_-||