Drupal网站在Site information的设置中有一个404错误页面可以定制到自己希望的网址，如果你在日志中发现大量404错误，而其中很多都是同一个类型可以引导到对用户更有帮助的内容页面，那么就可以在这个定制的404错误网址中进行判断、导向。

　　我做的例子是http://ak.postcodebase.com/not_found ，因为来自外部网站的链接中，有一部分是这个站内找不到或者错误的邮编，就可以根据URI进行判断：

• 如果访问9位邮编页面不存在但前面5位邮编分类页面存在，则转到5位邮编分类页面；

　　我们很多年前开始做网站就一直遇到被采集的问题，很多次都是让我们服务器不堪负重，需要排除、采取针对性措施来屏蔽，所以我一直对采集这种方式很排斥。另外，国内太多用采集做成的复制网站、山寨网站、垃圾网站了，在搜索引擎中也不会有长期良好表现，违反了SEO的原则，所以我们一直都没有用采集的方式来获取数据。

　　但这两年也一直有尝试采集软件的想法，我们不会去复制网站，但可以用来获取需要的一些数据，然后再做处理利用，去年也提过但一直没有实施，今年初再次提到这个想法，我也去看过、比较过一些采集软件，火车头采集软件在这方面比较领先，最近同事去详细了解、试用，感觉还不错，我们就干脆去购买

　　从开封返回郑州已经是下午4点多，打车会宾馆拿东西，又先让的哥把几位要到郑州火车站坐4点40分火车的跑友送过去，再返回到秦朝宾馆，拿了行李后再打车去郑州东站坐高铁回家。在东站的面馆里再次吃了一大碗羊肉烩面，还遇到另外三位跑友又一起吃了一只道口烧鸡。

　　回来的高铁列车稍慢一些，6点40上车到汉口站是9点20，然后在火车站内及周边又打不到出租车，害得我拖着行李箱走了有一站路在另外一个路口才等到一辆出租车，回家已经是晚上10点了。回来给老婆孩子讲了些趣闻趣事、洗澡休息。

　　周一早上就恢复送儿子上学、自己上班了，腿又酸了两天，到周三基本上好了，晚上去打了羽毛

　　早上5点刚过就起来了，洗澡、如厕、换衣、换鞋、早餐、收拾行李退房，这次同房间一起住的是武汉的跑友“三一慢跑”，他比我起得更早，烧好开水，还给我也冲了一碗麦片和一碗蜂蜜水喝，蜂蜜水很浓很甜，喝起来倒是不错，只是没有想到后来出了点问题。

　　郑开马拉松的最大特点是在两个城市之间跑，要凑好42.195公里的距离，终点设在开封的大梁门附近，起点就在郑开大道的白沙检查站，早上选手都是集中在紫荆山公园附近集合，由组委会提供的大巴运送到白沙检查站，这个过程也需要大半个小时。

　　整个10车道的郑开大道全部封闭了，白沙检查站附近也没有特别的车和

　　去年的12月初在上海马拉松拼尽全力跑到4小时以内后，终于算是达成了第一年跑马拉松的目标，随后也放松进入了“冬歇期”，很少再跑长距离，甚至跑步和其它锻炼都减少了很多，再加上冬季、春节吃得多，体重也明显增加了。春节放假期间倒是有时间，去地质大学和江滩跑了几次，但最长也就是10-20KM。

　　今年开始武汉市也公布了9个城区采样点的PM2.5值，1月份前后高得离谱，天空极其昏暗，雾霾严重，我在家里、单位都购买了空气净化器，甚至还自己掏3000多元购买了一台便携的PM2.5和PM10测量仪。我自己感觉空气污染严重的时候嗓子不舒服很明显，所以也减少了跑步

过春节前在网上与@谷歌AdSense官方微博 约好年后进行一次微博访谈活动，年后我还专门快递了5本签名书给Google公司作为该活动的奖品，3月7日活动已经在微博上进行，现在Google的编辑已经整理出来可以下载：《JamesQi 访谈内容归纳.docx》，我转发到博客中如下：

AdSense成功故事访谈
之 祁劲松

小编：今天我们很荣幸邀请到《 AdSense实战宝典 - 谷歌广告网上赚钱揭秘》

　　前几年一直用MediaWiki，从2006年到2010年，在2011年初改用Drupal后，以前的Wiki网站就基本上停止了更新，MediaWiki的版本也停在了1.16，后来还遇到不少网友站长咨询这方面的事情，我也只好告诉对方后面的版本我都不熟悉了。

　　虽然网站平台停止了更新，但运用还在继续，除了把一些站的留言关闭外，还是有几个历史悠久的网站保留了用户留言、交互的功能，依然需要解决一些遗留的小问题。近期花了一些时间来解决下面几个问题，记录如下：

反垃圾：

　　这两年国外的垃圾信息没有停，间隔着几天发几条、几十条，挺讨厌的，但又没有到必须用技

　　2011年初改用Drupal建站一个原因就是看中了对多语言的支持，2011年9月做了“多语言的中国邮政编码系列子网站”。

　　但当时对多语言的认识并不是很充分，只是单个网站用某一种语言，不了解同一套数据库做多种语言，所以当时做的多语言的中国邮政编码系列子网站

　　从用MediaWiki做网站开始，服务器负载一直就是个问题，为了解决这个问题，我们添加了各种缓存，如MediaWiki的多种缓存机制，包括File Cache，也加上了外部的Squid。后来做Drupal网站并不需要Squid，但因为服务器上已经安装了Squid，我们也只好把Drupal架设在Squid之后，另外Drupal也采用了内部core缓存和Boost缓存。

　　这些缓存机制可以解决不少问题，但缓存主要对数据量小、每页访问多的网站有明显效果，而对于数据量很大、每页访问少的网站起不到明显效果，有时甚至因为缓存文件过多起到反效果，而且缓存更新机制也有些小问题。

　　在《Drupal的MySQL过度膨胀，清理缓存、翻译表》这篇2012年8月的博文中，提到有些非英文网站的locales_source表不断变大的问题，当时在网上找了一些资料，临时先用删除表中某些特征的数据来解决，半年后再次逐步变大导致网站访问困难，又编写了一个自动删除表中记录的脚本来解决，但始终是治标不治本。

　　这些天在对其它网站进行多语言扩充的时候，发现有些网站也有类似问题，都是locales_source中包含大量不需要进行翻译的内容，再次查找资料并逐步调试，终于是找到问题的根源并可以解决了，有两种情况：

1. Drupal为每