DNA的匹配毕竟离生活还是远了点，既然是字符串匹配，可不可以做个拼写错误检查呢？
首先要引入一个概念，编辑距离（Edit Distance）。编辑距离指的是一个字符串修改到另一个字符串所需要的工序。通常有三种情况：
1.插入："ac" -----> "abc"，编辑距离为1
2.删除："abc" ------> "ac", 编辑距离为1
3.替换："abc" ------>"adc", 编辑距离为1
在这里我们定义两个字符串 x 和 y 的编辑距离为：
dist ＝ len(x) + len(y) - score(x, y)
score指的是全局匹配返回的分数。但是scoring_matrix怎么办呢？我找了一些我自己可以数得出来编辑距离的字符串，然后把一些可能的值一个一个去算。这里提到的scoring_matrix的参数有三个：diag_score(字符相同), off_diag_score(两个字符，但是不同), dash_score(一个字符，一个 ‘-‘ )。然后发现了这三个值分别是：
diag_score: 2 off_diag_score: 1 dash_score: 0
这里注意的是，别选择过于复杂的字符串，那样的话编辑距离很容易数错，比如"abcdged"与"acdad"，我们仅仅靠自己匹配，很难找出最佳的匹配。
在源代码中也有一个word_list.txt，里面存放了7万多个单词。这样我们就可以从中与给定字符串相差固定编辑距离的单词了。
def check_spelling(checked_word, dist, word_list):
alphabet = set('qwertyuiopasdfghjklzxcvbnm')
scoring_matrix = scoring_matrix = build_scoring_matrix(alphabet=alphabet, diag_score=2, off_diag_score=1, dash_score=0)
answer = set([])
for word in word_list:
edit_distance = get_edit_distance(checked_word, word, scoring_matrix)
if edit_distance <= dist:
answer.add(word)
return answer
其中get_edit_distance其实就是按照前面给出的公式计算出编辑距离的函数。我稍微测试了一下，寻找编辑距离为1的相似单词，十几秒就可以完成（可能是我的电脑的配置较高的缘故）。但是拼写检查还是追求的实时性，我一旦写错了一个单词，按下空格的时候，就应该有提示。十几秒不是可以接受的。
————————番外————————
这里测试了一下set和list的迭代效率，发现list的迭代效率高于set，而查找一个元素是否在对象内，set的效率远超list，而且set占据的内存相对list要下
————————番外结束——————
当用户输入一个单词，我们首先可以查找单词是否在正确拼写的单词集合内（查找一个对象是否在一个集合的效率是很高的）。如果不在，就打上波浪线，然后就可以进入查找dist为1或者2的单词集合了。
我突然想到word早期版本的拼写错误检查，打波浪线很快，但是进行拼写错误检查的时候要等半天，是否就是采用这样的办法？
然后进入查找程序之后，进行匹配之前，可以先检查单词的长度，如果长度相差多于给定的dist，那么就不用进入匹配了，直接抛弃即可。效率应该又可以提高一些。
在互联网的时代，云计算的性能不言而喻，而在线编辑的时候也要实时保存，传送一个单词的带宽也很窄，因此可以把计算放到云上，这样几乎就是实时的。而检查一个单词是否在正确拼写的集合内的操作可以让JavaScript来做，既可以减轻服务器的负担，在用户这边，又感觉不到丝毫的卡滞。
一口气写完了字符串匹配的三篇文章，真是神清气爽，而文章的抄袭检查也是呼之欲出了。因为最近要找工作，第四篇可能会稍微晚一点，敬请期待吧。
源代码：Github