JavaScript 上万关键字瞬间匹配实现代码
人气:0
提到关键字搜索，首先联想到的无非就是使用一些indexOf，replace之类的字符函数，最多加上一些正则表达式而已.实现起来虽然很简单，但是这背后的效率问题可曾仔细考虑过？例如论坛中的关键字过滤，一般情况下需过滤的关键字数量及检测的文本长度都不大，所以这一瞬间的过程没有太多值得关注的地方。但若关键字数量不在是屈指可数，而是有成千上万， 并且待检测的文本也是一长篇大论，结果可不再是那么乐观了。大家都知道，每多一个关键字，就要增加一次全文的检索，最终花费的时间将远远超出可接受的范围内。
既然考虑的是那种极端的关键字搜索，通常的逐个遍历搜索显然是行不通的。如今用的是JavaScript，若不使用Hash表实在是太对不起这门语言了。有着对表特天独厚的支持，不妨就拿出少量的空间来换取大量的时间吧。
先看个例子，比如有如下的关键字: foo1，foo2，bar1，bar2，既然要用空间换时间，因此搜索之前先将他们预处理。前面提到了JS灵活又高效的表，显而易见，使用树的结构是最有优势的。即使不明白，也没关系，最终实现结构正如如下的代码，熟悉JSON同样很亲切：
var Root =
{
f:
{
o:
{
o:
{
: true,
: true
}
}
},
b:
{
a:
{
r:
{
: true,
: true
}
}
}
};
这一层层的结构正如一棵树，每个字符便是树的一个分枝，到了最后一个字符便是树叶，不再有新的节点。
此时你应该明白了，只要对文章的每个字沿着这棵树往下搜就是了。能到达树叶的，就说明当前字符就是关键字的一个；中途寻找不到对应枝干的，当然就不是关键字。
例如foo1，顺着Root结构向下访问，最终到达Root['f']['o']['o']['1']，即完成了一次匹配。之后跳过foo1的长度，继续往后检索。
因此，整篇文章只需一次检索，即可找出每个关键字的位置。
由于JS的hash表性能非常高，所以所谓的寻找枝干也就非常的快了。因为JS的灵活性，实现此效果的代码同样很简短。
事实上可以发现，关键字的数量与搜索的时间并没太多的关系，那仅仅影响了树的宽度而已，只有文章的长度才是决定搜索的时间。
来一次极限测试：
关键字： 成语全集(19830条)
内容：诛仙全集.txt (1659219字)
用时：935ms
(Chrome26 / i3-2312的CPU)
160万字的文章，匹配2万个关键字，还不到1秒的时间。可见，充分利用JavaScript的灵活性，仍能发挥很大的潜力。
既然考虑的是那种极端的关键字搜索，通常的逐个遍历搜索显然是行不通的。如今用的是JavaScript，若不使用Hash表实在是太对不起这门语言了。有着对表特天独厚的支持，不妨就拿出少量的空间来换取大量的时间吧。
先看个例子，比如有如下的关键字: foo1，foo2，bar1，bar2，既然要用空间换时间，因此搜索之前先将他们预处理。前面提到了JS灵活又高效的表，显而易见，使用树的结构是最有优势的。即使不明白，也没关系，最终实现结构正如如下的代码，熟悉JSON同样很亲切：
复制代码 代码如下:
var Root =
{
f:
{
o:
{
o:
{
: true,
: true
}
}
},
b:
{
a:
{
r:
{
: true,
: true
}
}
}
};
这一层层的结构正如一棵树，每个字符便是树的一个分枝，到了最后一个字符便是树叶，不再有新的节点。
此时你应该明白了，只要对文章的每个字沿着这棵树往下搜就是了。能到达树叶的，就说明当前字符就是关键字的一个；中途寻找不到对应枝干的，当然就不是关键字。
例如foo1，顺着Root结构向下访问，最终到达Root['f']['o']['o']['1']，即完成了一次匹配。之后跳过foo1的长度，继续往后检索。
因此，整篇文章只需一次检索，即可找出每个关键字的位置。
由于JS的hash表性能非常高，所以所谓的寻找枝干也就非常的快了。因为JS的灵活性，实现此效果的代码同样很简短。
事实上可以发现，关键字的数量与搜索的时间并没太多的关系，那仅仅影响了树的宽度而已，只有文章的长度才是决定搜索的时间。
来一次极限测试：
关键字： 成语全集(19830条)
内容：诛仙全集.txt (1659219字)
用时：935ms
(Chrome26 / i3-2312的CPU)
160万字的文章，匹配2万个关键字，还不到1秒的时间。可见，充分利用JavaScript的灵活性，仍能发挥很大的潜力。
加载全部内容