字符串匹配

Question

让我解释一下这个问题：

1. 假设我有一个图书馆，该图书馆包含许多书籍，每本书包含章节，每个章节包含字符串（字符串以点“。”开头和结尾）。
2. 再次顺序，库->书->章->字符串。
3. 我从书本中提取了字符串，我们称它们为“书本字符串”。
4. 我有一个系统，用户可以在搜索表单中输入字符串，并且系统应从“书本字符串”中返回输入字符串的精确匹配项。 如果输入的字符串与书籍字符串中的任何字符串都不匹配，则不会返回任何内容。

我考虑了一下，找到了解决方案，我将所有书籍字符串MD5并保存散列的书籍字符串。 当用户输入要搜索的字符串时，我也会对其进行哈希处理，并在哈希的书本字符串中搜索匹配项。 它比较便宜（每个字符串32或64个字符），比普通搜索要快，并且它只返回精确的匹配项。

有任何意见，想法和更好的解决方案吗？

PS这种算法的名称是什么？ 搜索或匹配？

Answer 1

不错，但是您应该调查Lucene。 它是一种以多种语言实现的公共共享软件文本索引和搜索工具，其中一种是.Net（您使用的是platfporm /语言？），我使用它来对公共互联网上的网站内容进行自由文本搜索。主要模型是在不固定的细分市场中提供内容（大量杂志文章，书摘等）。Lucene对我们来说非常有效。

Lucene

Answer 2

搜索字符串的算法很多，从诸如Boyer-Moore算法之类的简单方法到诸如后缀树之类的复杂数据结构不等。 有关这些内容的完整介绍，请参见：

• Gusfield，Dan（1999），关于字符串，序列和树的算法。 剑桥：大学出版社。

但是，就您的情况而言，将书中的文本分割成单独的标记（单词）并将它们存储在索引中（例如，简单地在Map中，或使用完整的框架进行索引和搜索，如Lucene ）可能更有意义。

Answer 3

这称为哈希 ，可以认为是“搜索”或“匹配”。

您还应该通过比较用于生成哈希的字符串来验证您的MD5哈希正确无误，因此您没有任何误报 。

要考虑的另一件事是， 从某种程度上支持搜索可能是有益的。 考虑

Mary Queen of Scots
Mary Livingston
Mary Had a Little Lamb, and other silly stories

从搜索玛丽开始 ，应该返回这三个记录，甚至可能更多。 尽管MD5哈希的处理速度很快，但也应考虑其他答案中介绍的技术，以根据您的情况找到最佳的收益/成本平衡。

Answer 4

您应该将每本书的章节都转换为后缀树 。 后缀树是Trie的一种（由divo提及）。

后缀树专门用于快速文本搜索。 后缀树的一个优点是，搜索长度为n的字符串的时间为O（n）。 这与算法思想（渐近）一样好（渐近）（因为对字符串进行哈希处理需要O（n）时间），但更加灵活，因为它甚至适用于部分句子。 如果您以句号开始/结束搜索，则可以简化为句子搜索。

说明：更准确地说，您将拥有一棵后缀树。

Answer 5

您可能要使用Trie或其他基于树的数据结构来存储字符串数据。

特里也可以用来替换哈希表，它具有以下优点：

• 与不完善的哈希表相比，在最坏的情况下，在Trie中查找数据的速度更快，为O（m）。 不完善的哈希表可能会发生键冲突。 键冲突是不同键到哈希表中相同位置的哈希函数映射。 不完善的哈希表中最坏情况下的查找速度为O（N）时间，但更通常为O（1），其中O（m）时间用于评估哈希。

• 尝试中没有不同键的冲突。

• 仅当单个键与多个值相关联时，才需要类似于存储键冲突的哈希表存储桶的Trie存储桶。
• 不需要提供哈希函数或更改哈希函数，因为有更多的键添加到了Trie中。
• 特里可以按键提供条目的字母顺序。

尝试确实也有一些缺点：

• 在某些情况下，尝试查找可能比使用哈希表查找数据要慢，尤其是在直接访问数据的硬盘驱动器或某些其他辅助存储设备（与主存储器相比，其随机访问时间较长）上尤其如此。
• 将所有键表示为字符串是不容易的，例如浮点数，对于相同的浮点数，它们可以具有多个字符串表示形式，例如1、1.0、1.00，+ 1.0等。
• 尝试通常不如哈希表节省空间。

（请参阅http://en.wikipedia.org/wiki/Trie ）

Answer 6

一个特里是最好的办法。 这就是所谓的后缀映射。 使用Trie优于哈希概念的好处是，使用Trie可以非常轻松地显示自动完成类型语法。 查找单词的时间为O（n），其中n是单词的长度。 在Trie的每个节点上，您将需要存储包含特定单词的书籍列表。

Answer 7

我同意Trie-加上一个，使用soundx算法为trie id / node转换字符串-因此考虑了拼写错误

Answer 8

这称为哈希。 您的方法可能有效，但不是很灵活。 同样，您将只检索完全匹配的内容。 两个原图像也可能共享同一图像（两个不同的字符串散列为相同的值），但这极不可能，因此这不是真正的问题。 我会建议您这样做，因为它缺乏灵活性，但是如果那不打扰您，那么我想这会为您服务。 这与人们用于存储和验证密码的技术基本相同（显然，您不使用任何“盐”值）。

Answer 9

首先，听起来好像您应该使用的是数据库-这几乎就是数据库的用途。 （如果您希望将其嵌入自己的应用程序中，请查看SQLite ，这是一种轻量级DBMS，旨在用作嵌入式库。）

其次，您的哈希解决方案将仅返回完全匹配的情况并不是很正确...由于MD5摘要为128位，这意味着任何给定的字符串对都具有1-in-2 ^ 128产生相同哈希值的机会。 是的，这是一个很小的数目，但是如果您有很多书，那么就会有很多成对的字符串。 因此，比较散列值后，需要进行全文比较以消除误报。