我有一个做了一款移动浏览器的朋友。
他有这样一个需求：当用户输入一个站点的url时候。移动浏览器须要识别这个网址是否是一个恶意网址。另外。他有一个恶意网址库。
或许这种解决方法有多种。
当中一种就是把恶意网址库放在本地，移动浏览器拿到一个网址的时候就把它与网址库中的每一个地址匹配一下。依据匹配与否来推断网址的是否为一个恶意地址。
哦，我忘了补充的情况就是这个网址库中有150万条数据，压缩后23M。假设一个浏览器为了识别恶意网址这么一个功能而附加这么大的库，你会没实用户的。
我刚開始给出的解决方法是bloom filter（bloom过滤器）。
关于它的具体机理。吴军先生的《数学之美》中当有提及，我这里仅仅给出一些參数值：数组大小是1500000 * 20 / 8 B(即bitset大小是数据项的20倍)。hash function数目为13，误差率为万分之中的一个。我用C++和Java分别实现了这个算法。測试后效果令人惬意。数组大小仅仅有4M多，再用zip压缩后大小仅仅有2.8M。4G时代移动浏览器附带一个3M大小的库，个人以为是能够让人接受的。
事情到此为止本该就此结束。朋友又有一个需求：当用户输入一个网址的前面一部分数据库的时候。浏览器要给出相关的最多十个相关网址。
这个网址库当然就更大了。并且又要不断地更新，意味着不能放在本地。
可是，每一个人浏览的站点一般不会超过一百个吧，刚開始这个库能够为零，随着用户使用次数增多，统计一下缓存在本地就okay啦。这个不须要去server拉一大堆网址库下来。
再说，真要是匹配不到也无所谓啦。
我想到的算法是trie树。自己实现一个trie树当然是非常蠢笨的事情，我去网上搜罗了一番，在stackoverflow上得到一个提示：dawgdic。
它也自称是最棒的trie树，查找速度最快。并且声称的字典库相对来说比二维数组实现的trie树还要节省空间。我在code.google.com上下载完代码后（最新代码是dawgdic-0.4.5.tar.gz,2011年），把它的example看了一遍，有例如以下功能：
1 依据排列有序的数据，它能够构建出一个很节省空间的dawg dictionary。
2 它的dawg词典库的每一项能够仅仅有一个key，也能够附带插入其value。即每一个数据项是一个key-value对。
3 依据构建好的词典它能够进行kv查询，即给出一个key。返回其value;
4 假设仅仅能给出key的一段前缀。它能够返回全部共同前缀的key，这些结果能够依照字母顺序排列后返回也能够依照value的大小排序后返回；
5 假设仅仅能给出key的一段后缀，它能够返回全部共同后缀的key，这些结果能够依照字母顺序排列后返回也能够依照value的大小排序后返回。
依据以上特性。上面那个需求就稀里哗啦地攻克了（^_^）。我们须要利用的特性是1、2和4。dawg字典的key当然是网址的url，其权值当然是浏览次数。因为dawg词典构建好了以后，不能进行modify，而用户对每一个网址每一段时间内的浏览次数是变化的，这就须要没过一段时间内对这个dawg dictionary进行又一次构建。
事实上上面仅仅是简单地分别列举了两个算法的各自应用场景，事实上这两个算法的应用范围很广。如bloom filter就不说了，dawg树就能够用在搜索中的热搜索提示、一些英汉词典的词语搜索和输入法的个性化提示等。
晚上吃完饭，写出此记，对自己近期一段时间的业余研究做一番总结，接着加班。
附带声明：不经本人同意，诸如推酷“www.tuicool.com”这样的垃圾抄袭站点不得转载本人的blog。
版权声明：本文博客原创文章。博客，未经同意，不得转载。