漢字の検索において、異体字・誤字などを考慮するには、以下の3種類の処理を行う必要があります。 (1) 異体字・誤字・通仮字の「マーク付け」 テキスト入力時に異体字や誤字の情報をXMLなどによってマーク付けします。そして検索用インデックスの作成時にマークで示される代替テキストの方をインデックス用のテキストとして置き換えます。 (2) 検索対象テキスト・検索キーの「フィルタリング」 テキスト中の異体字に対し、検索用インデックス作成時および検索キー入力時に、より一般的な漢字に置換したり、異体字選択子などの除去を行います。 (3) 検索時の「複数候補での検索」 異体字とは言えないものの、よく混同される漢字について、複数の候補で検索をします(「云う」と「言う」など)。 異体字フィルタ(Apache Lucene) 以下は、Apache Lucene にて転置インデックスを作成する際に、異体字をフィル
Searching Numerical Fields NumericRangeQuery (in Lucene Core since version 2.9) Because Apache Lucene is a full-text search engine and not a conventional database, it cannot handle numerical ranges (e.g., field value is inside user defined bounds, even dates are numerical values). We have developed an extension to Apache Lucene that stores the numerical values in a special string-encoded format wi
Erik Hatcher also wrote(message): One more point... caching is done by the IndexReader used for the search, so you will need to keep that instance (i.e. the IndexSearcher) around to benefit from the caching. Using a Filter Instead In many cases (I would argue: all cases) it doesn't make sense to Query on a Range of Dates. More then likely what you really want to do is *Filter* on a Range of Dates.
Although Lucene provides the ability to create your own queries through its API, it also provides a rich query language through the Query Parser, a lexer which interprets a string into a Lucene Query using JavaCC. Generally, the query parser syntax may change from release to release. This page describes the syntax as of the current release. If you are using a different version of Lucene, please co
「第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー」を読んで、面白そうだし、なんだか作れそうな気がした。 処理の概要はこんな感じ。 入力されたキーワードに対して、正しいスペルの候補を返す。 正しいスペルの候補ははてなキーワードのリストをから探す。 実装の概要はこんな感じ。 はてなキーワードのリストからN-gram(今回はbi-gram)インデックスを作成する。 インデックスから正解の候補を探す。 見つかった候補のJaroWinkler距離を求めて、距離の近いものを返す。 いろいろ調べてみると Lucene に以下のようなクラスがあった。 NGramTokenizer JaroWinklerDistance LevensteinDistance 名前の通りのクラス。素晴らしい素晴らしい。 N-Gram や JaroWinklerDistan
昨日は第11回 Kansai.pm でした。 今回は無理を言って自分がホストを担当させていただきましたが、面白い発表が多く開催した自分も非常に満足でした。 PFI の吉田さんによる Cell Challenge での計算機に合わせたアルゴリズムのチューニング手法の発表 (発表資料) は圧巻でした。伊奈さんの本文抽出の話 (発表資料)、はこべさんのコルーチンの話 (発表資料)、いずれも難解になりがちなところを凄く分かりやすく解説されていて、さすがだなと思いました。各々ショートトークも、いずれも良かったです。 スペルミス修正プログラムを作ろう 自分も 20 分ほど時間をいただいて、スペルミス修正プログラムの作り方について発表しました。 スペルミス修正プログラムを作ろうView more presentations from Naoya Ito. スペルミス修正プログラムについてはずばり スペル
i-revo お客様サポート 重要なお知らせ i-revoマイポータル終了のお知らせ(2017年3月31日) 日頃よりi-revoマイポータルをご愛顧いただき誠にありがとうございます。 このたび、当サイトは2017年3月31日付けにてサービスを終了いたしました。 併せて「プニマル」、「i-revo 占い」についてもサービスを終了いたしました。 2006年3月のサービス開始以来、 お客様および関係各社の皆様にはさまざまに、ご協力をいただきました。 ここに御礼申し上げます。 i-revoマイポータルのサービス終了につきまして、なにとぞご理解いただきたく存じます。 今後とも「i-revo」をよろしくお願い申し上げます。 全て見る
ASF JIRAで、NGramTokenizerで検索すると、いくつか引っ掛かってきます。 #LUCENE-1227 NGramTokenizer to handle more than 1024 chars - ASF JIRA 1024文字以降が扱われないといった問題。大きな文章を扱う場合に痛すぎますね。 #LUCENE-1225 NGramTokenizer creates bad TokenStream - ASF JIRA Summaryからしか判断できないのですが、、変なTokenが作られるということでしょうか。(後で、patchの中身みる) あとは、下記の問題は既に対処されているのかな、、 Apache LuceneのNGramTokenizer - 13F
Apache Lucene で全文検索するようなアプリケーションを作成中。とりあえず CJKAnalyzer かと思っていたら こちら で NGramTokenizer という便利そうなものが紹介されていたので使おうとしてみた。 まず Analyzer が必要なので以下のようなものを作成。 public class NGramAnalyzer extends Analyzer { protected int minGram; protected int maxGram; public NGramAnalyzer(int minGram, int maxGram) { this.minGram = minGram; this.maxGram = maxGram; } public TokenStream tokenStream(String fieldName, Reader reader)
IndexReader reader = IndexReader.open(dir,true); IndexSearcher searcher = new IndexSearcher(reader); Analyzer analyzer = new NGramAnalyzer(); QueryParser parser = new QueryParser("contents", analyzer); String target ="石川遼"; target = target.replaceAll(" "," "); Query query = parser.parse(target); System.out.println("Searching for: " + query.toString("contents")); Searching for: "石 川 遼 石川 川遼 石川遼" こん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く