【问题标题】:Lucene RegexQuery doesn't seem to apply Regex?Lucene RegexQuery 似乎没有应用正则表达式?
【发布时间】:2014-07-23 15:03:29
【问题描述】:

代码:

private static void AddTextToIndex(string filename, string pdfBody, IndexWriter writer)
    {
        Document doc = new Document();
        doc.Add(new Field("fileName", filename.ToString(), Field.Store.YES, Field.Index.NOT_ANALYZED));
        doc.Add(new Field("pdfBody", pdfBody.ToString(), Field.Store.NO, Field.Index.NOT_ANALYZED));
        writer.AddDocument(doc);
    }

protected void txtBoxSearchPDF_Click(object sender, EventArgs e)
{
//some code
    string searchQuery = txtBoxSearchString.Text;
    Term t = new Term("fileName",searchQuery+"/i"); 
    RegexQuery regQuer = new RegexQuery(t);

TopDocs resultDocs = indexSearch.Search(regQuer, indexReader.MaxDoc); 

            var hits = resultDocs.ScoreDocs;
            foreach (var hit in hits)
            {
                var documentFromSearcher = indexSearch.Doc(hit.Doc);
                string getResult = documentFromSearcher.Get("fileName");
                string formattedResult = getResult.Replace(" ", "%20");
                sb.AppendLine(@"<a href=https://de.com.edu/search/COM-Syllabi/" + formattedResult+ ">" + getResult+"</a>");
                sb.AppendLine("<br>");
            }
}

基本上我要做的就是使用正则表达式,这样我就可以完全匹配,但我希望搜索不区分大小写。但是添加/i 选项实际上并没有使它成为一个正则表达式,它似乎所做的只是让搜索词在文本框中输入与/i 连接的任何内容。

有什么想法吗?

【问题讨论】:

    标签: c# asp.net regex lucene


    【解决方案1】:

    区分大小写主要取决于您使用的Analyzer

    RegexQueryMultiTermQuery,这意味着它将被重写为类似于 BooleanQuery 的内容,并且在与正则表达式匹配的所有术语上出现 SHOULD

    在搜索时,索引中的术语将被枚举并与您的正则表达式匹配。匹配的术语将作为子句添加到BooleanQuery

    您的正则表达式显然无法通过分析器,因此您必须手动调整它以匹配您的条款。

    而且,正则表达式语法不支持许多功能...See the docs

    实际上,我简化了解释,真正发生的事情更复杂,因为发生了许多优化(所有术语都没有枚举,正则表达式被编译为有限状态自动机,查询不一定被重写为@987654328 @ ETC)。但幕后发生的事情将与我在这里解释的结果相同。

    【讨论】:

    • 好吧,我不知道您手动调整它的确切含义。当搜索时间到来时,我不会使用指定分析器的解析器进行搜索。我正在使用 SingleCharTokenAnalyzer 创建索引,但是,当我将项目添加到索引时,我的字段设置为“NOT_ANALYZED”,这并不意味着如果未分析字段,则分析器的属性不是' t 适用于索引的内容?编辑:我在我的问题中添加了更多代码以帮助创建更多上下文。
    • 哎哟!您通过不分析您的 PDF 正文来破坏 Lucene 的目的......假设它包含多个单词,一旦您拥有更多文档,这将变得非常缓慢。 Lucene 的优势来自于对文本的分析。你应该在那里重新考虑你的整个方法。
    • 我遇到的问题是,大多数分析器都不能准确地搜索文件名和 pdf 文本。由于某些文件名可能是 BIOL-1322-001IN-JohnsonFA2104.pdf,因此标准分析器、关键字分析器和简单分析器由于标记化的方式而无法识别。没关系,SingleCharTokenAnalyzer 非常适合文件名,但它可以识别单词中出现的字符串。例如,如果我搜索“Orr”,我会看到“正确”之类的词。我正在尝试将两者与正则表达式混合。
    • 看看PerFieldAnalyzerWrapper 类,它可以让你为你的领域选择不同的分析器。我不知道您的需求,但您仍然应该正确标记文本并使用它。您可能还对WildcardQuery 感兴趣,尽管最终结果将与RegexQuery 相同,只是通配符更简单。当然,您可以编写自己的分析器来满足您的需求,这非常容易。
    • 并非如此。这取决于您的需求。分析器只不过是一个包装标记器和标记过滤器链的对象。在这里找到正确的标记器和标记过滤器组合是真正的挑战,完全取决于您的需求。 Lucene 中有很多标记过滤器(可以进行词干提取、停用词删除、ascii 折叠、小写等操作),当然您也可以编写自己的过滤器。看看源代码。另外,请记住您用于搜索的分析器必须与您用于索引的分析器兼容(即它们产生可匹配的标记)。
    猜你喜欢
    • 2012-07-28
    • 1970-01-01
    • 2016-01-31
    • 1970-01-01
    • 1970-01-01
    • 2021-08-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多