greensea 的 blog

这个帖子竟然绕过了YT的广告帖子防火墙，看了看它的特征，果然啊，这样的广告是YT以前没有遇到过的，于是也就没有针对这种类型的广告的规则，所以就广告帖子防火墙就漏过了这个广告。

对比偶在《YT的反广告贴子的策略》中写的办法，看看这个广告是怎样绕过YT广告帖子防火墙的。

首先发表这个帖子的用户发帖数少于20，并且帖子字数也比较多，于是这两个先决条件满足了，下面再来看看后继的条件。

广告帖子年年有，最近特别多

至少在几年前，广告帖子就已经存在，当时这些帖子主要是由程序自动登录论坛发布的。有这样的一些人，分析各大论坛程序的登录流程，并收集使用这些论坛程序的网站作为一个数据库，使用程序来批量访问这些网站，在上面发布广告。

对付这些注册机是相对简单的，只要设置一个比较好的注册问题就可以了，最常用的还是验证码。在以前，YT使用自己修改过的验证码机制，几乎挡住了所有的注册机器人（也许是所有的，不过没法精确计算）。在使用了信的验证码机制以后，YT的广告帖子数骤然下降。这种大好局面维持了一段时间以后，就被破坏了。

起初还以为是更新的注册机器人已经绕过了YT的验证码机制，不过据后来的情况分析，这些死灰复燃的垃圾帖子似乎并不是和以前一样是由注册机器人发布的，取代机器人的是——活人。

是活人的话，验证码就形同虚设了。到目前为止，我观察到的广告中QQ华夏的广告占了超过一半的份额。看来腾讯财大气粗啊，有如此多的钱来雇佣活人来发布广告。不过我不太清楚QQ华夏这种广告模式的运作过程，希望知道的人能介绍一下。

那天，偶在测试程序，不小心删除了Dv_Topic表
本来是想删除测试数据库中的Dv_Topic表的，没想到失手删除了正在使用的数据库的Dv_Topic
失手过程是，偶用鼠标右键点击表，选择删除，接着另一只手立刻按下了回车，虽然按下回车之后偶立刻发现了这素主数据库，但已经来不及了，回车已经按下去了
这下麻烦大了，在MSSQL2005管理器中找了一下，没有发现恢复功能，于是咨询度谷，发现一个Log Explorer for SQL，说可以根据SQL日志恢复被误删除的表。于是偶就把这东西下载回来，但是安装的时候却提示出错，看安装日志它竟然说无法打开某键值，而那个键值保存的是MSSQL安装路径。偶真是不知道它怎么会无法打开那个键值，明明是一个很普通的键值，没有权限限制的键值，竟然打不开，真囧。
没办法，这软件不能用，只好另寻他法了。
不管怎么样，偶先从一个月前的备份中回复了Dv_Topic表。
偶曾经修改了动网的程序，让Dvbbs.Execute方法把所有执行过的SQL语句都记录下来，不过因为使用了ASP的缓存，所以并不能完整记录所有执行过的SQL语句，不过记录大部分还是没有问题的。首先偶就从这些SQL日志中筛选出INSERT INTO Dv_Topic和UPDATE Dv_Topic的语句，然后把这些语句重新执行一遍，预计可以恢复大部分的主题数据。
接着偶就这么做了，不过完成以后结果并不乐观，有不少帖子的数据还是没有回来，另外主题ID的数据也对不上号，肯定是漏记录了某些INSERT的语句，导致主题ID这个自动编号字段乱了。
又要另寻出路。
想到动网的数据库设计是有很多数据冗余的，Dv_bbsx表就有不少冗余，于是偶就想到可以利用这里的冗余数据来恢复YT的帖子主题数据。
果然这方法很不错，Dv_bbsx表中记录有帖子所在主题的标题和主题ID，有了这两个信息偶就可以回复主题数据了。于是偶写了一个SQL，把丢失的主题数据列出来，接着插入到Dv_Topic表中。插入完毕以后，偶又写了一个SQL语句来更新Dv_Topic中记录的主题的回复数。这方法很管用，大部分的主题都恢复了，仅仅有极少量的帖子主题ID重复，无法回复（实际上要恢复也是可以的，不过偶懒得管这么多了，也就几张帖子而已，而且都素不重要的帖子）。美中不足的就是帖子的点击数无法恢复。

这次灾难影响还不算太大，因为大部分数据都回来了嘛。不过这事还是提醒偶们，在进行诸如此类危险的数据库操作时，千万不要使用键盘，使用鼠标是最安全的。

樱町分成两个形态以后，在线人数和其他的一些论坛数量指标就不容易统计了。现在的情况是，YTD的人很少，而YTX的人很多（当然 = =，现在还是默认进入YTX的）。不过YTD的人少到什么程度，而YTX的人又多到什么程度呢？偶想得知这些数据，于是就写了一个vbs，每隔一分钟从数据库中读取信息并做一个快照，再保存到数据库里。
快照的信息包括YTX和YTD每一分钟的在线游客、在线用户，这一分钟的帖子浏览数，同样也分在线用户进行的浏览和游客进行的浏览。
快照是直接保存在数据库里面的，不容易查看。其实在做这个快照的时候偶就已经打算另外做一个界面来显示快照的信息了。
于是樱町论坛状态监视系统就横空出现！
首先看看截图吧

YT已经分成两个关系很诡异的形态了，而这个分离在很大程度上是基于模板的，这就给模板管理带来了一个问题
两个形态的YT各有各的一套完整模板，而实际上两者之间不同的地方没有多少。就目前来说，不同的地方只有页脚信息不同，其他部分都是相同的
还有一些公共的页面，如登录页面、注册页面，这些页面肯定都是一样的。这样子问题就出来了，当我要修改登录页面的时候，我就必须修改两套模板，这就太费劲了。有一个比较好的办法是，让两个YT在相同的部分共用一个模板，在各自不同的部分才使用自己的模板。
另外还有一点，动网的模板是保存在数据库里的，修改也只能进入后台在网页上进行修改，这不太方便。
为了这两个问题，偶就把动网的这个模板系统改掉了，用上了自己的模板体系。