我们假设text是一个字符串并包含一个文本。 tags是一个字符串数组。
text = <<-EOS
Lorem ipsum dolor sit amet, consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit
esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est laborum.
EOS
tags = [ "some", "in", "dolor", "laborum", "missing" ]
算法应返回text中至少包含一次的所有标记。在上面的例子中
[ "in", "dolor", "laborum" ]
不需要对结果数组进行排序。另外，我实际上并不需要知道text中每个标记的出现次数。
我带了几个解决方案，但他们都没有真正说服我。有什么建议吗？
答案 0 :(得分：2)
text.gsub!(/[[:punct:]]/,"").split
p tags.select{|x| x if text.include?(x)}
答案 1 :(得分：1)
您正在做的是一个非常迷你版的搜索引擎。您的数据足够小，您可以为要查找的每个字符串轻松浏览，分隔空格。随着你的文字长到100页，这就不那么好了。
你可以做一些疯狂的事情来加快速度。如果你看一下Lucene的源代码（http://lucene.apache.org/java/docs/index.html），你会得到一些提示......因为这基本上是lucene的基本模式（找到大文本Y中文本X的匹配。在内部，我并不是百分之百确定它的作用，但我觉得这是扫描整个巨型文本，并构建单词出现和位置的巨型哈希表。所以它会预先扫描并建立一个可能出现的每个单词的列表......然后如果文本中有“dolor”，你可以很快地问它。
答案 2 :(得分：0)
hsh = {}
text.gsub(/[[:punct:]]/,"").split.each {|t| hsh[t]=true}
tags.select{|x| hsh.has_key?(x)}
我不确定哈希的速度有多快。
答案 3 :(得分：0)
这是一个研究得很好的问题：多字符串模式匹配，其中有许多好的解决方案存在于文献中。 Aho-Corasick提供最坏情况下的最优前向匹配算法（即执行复杂度为O（| P | + | T |），其中| P |是所有要匹配的字符串长度的总和）和| T |是您匹配的文本的长度）。后向oracle匹配（SBOM）算法是具有O（| P | X | T |）最差情况复杂度的良好向后匹配算法的示例，但是平均比Aho-Corasick表现更好。