オープンソースの全文検索ソフト
オープンソースに限りませんが、全文検索ソフトのリストがこちらにあります。
日本語全文検索エンジンソフトウェアのリスト
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/other-system.html
THX to 馬場さん@宇物 Namazu など、日本語を扱うことができる全文検索ソフトの多くは、
kakashi や chasen などの補助ソフトを使っています。
KAKASI - 漢字→かな(ローマ字)変換プログラム
http://kakasi.namazu.org/
Morphological Analyzer ChaSen
http://chasen.aist-nara.ac.jp/
○参考リンク
日本語全文検索での索引作成・検索アルゴリズム
http://www-6.ibm.com/jp/software/data/cm/txt.html
ASCII24 デジタル用語辞典 - 形態素解析
http://yougo.ascii24.com/gh/60/006070.html Snatcher Full-text Search System ver. 3
http://www.arc.ritsumei.ac.jp/kachina/mikio/snatcher.html (English)
http://www.arc.ritsumei.ac.jp/kachina/mikio/snatcher-ja.html (Japanese)
Copyright (c) 2002 Mikio Hirabayashi. All rights reserved
概要(上記サイトより引用)
Snatcherは、全文検索システムです。
GoogleやAltaVistaをご存じの方は、それが個人向けに簡単になったものだと思ってください。
検索フォームに検索語を入力すると、その語を含む文書の情報を一覧することができます。
検索結果は、該当文書の検索条件への適合度(スコア)の順で、文書の要約とともに表示されます。
Snatcherは、中規模(文書数100000、総容量1GB程度まで)のWebサイトやファイルサーバでの運用に適したシステムです。
それ以外に、メールボックスやオンラインマニュアルの検索にも使うことができます。 入力ファイルから日本語部分を削除するのに使えそうな方法。
【Linux板】namazuでサーバーを立てたい
http://pc.2ch.net/test/read.cgi/linux/989179375/357n
Namazu, Snatcher などでは日本語を扱うことができます。
しかし多くのオープンソースの全文検索ソフトでは日本語を適切に扱うことができません。
無理やり日本語ファイルをインデックス化すると、
2バイトコードのかけらなどを単語として認識してしまい、
インデックスファイルのサイズが異常に大きくなってしまうことがあります。 ファイル形式の判別には、拡張子あるいはパス名と正規表現のマッチングで行っているものが多いようですが、
Namazu など Perl ベースで書かれているものは File::MMagic を使っているようですね。
http://search.cpan.org/dist/File-MMagic/ Namazu の mknmz で ~/Mail/inbox をインデックス化してみました。
分かち書きには kakasi -w を使っています。
[Append]
Date: Fri Nov 1 21:02:37 2002
Added Documents: 981
Deleted Documents: 2
Size (bytes): 10,434,220
Total Documents: 981
Added Keywords: 61,229
Total Keywords: 62,044
Wakati: module_kakasi -ieuc -oeuc -w
Time (sec): 447
File/Sec: 2.19
System: linux
Perl: 5.006001
Namazu: 2.0.10
real 7m28.223s
user 1m57.340s
sys 0m3.600s できたインデックス (NMZ.* ファイルたち) の大きさは、合計で 3200KB でした。 >>5 こんなのも。
MeCab: Yet Another Part-of-Speech and Morphological Analyzer
Mhttp://cl.aist-nara.ac.jp/~taku-ku/software/mecab/
C++ で書かれていて ChaSen よりも高速らしい。
他言語への binding も豊富。
>>12
情報ありがとうございます。
しばらく namazu をいじってました。
独自フィルタを作る方法を知りたくって。
namazuでサーバーを立てたい
http://pc.2ch.net/test/read.cgi/linux/989179375/ Windows で namazu + chasen を使ってみました。
namazu も chasen もそれぞれ Windows 用バイナリが用意されているのですが、
組み合わせて使おうとすると cygwin 上でソースからコンパイルしたものが必要です。
Namazu全文検索システム
http://pc.2ch.net/test/read.cgi/php/992477868/99-102 namazu + kakashi/chasen で決まりでしょう。
んでもってapache上でnamazu.cgi動かす。
glimpseって有料じゃなかったかな?
ht://dig は日本語とおらないし。 >>15 GETA って scheme や Haskell との interface も考えてたりして、 ちょっとマニアックかも >>17
まず形態素解析器で形態素を解析します。(Chasen, Juman, MeCab)
その後、必要であれば、どの文節がどの文節に係っているか(係り受け構造)を構文解析器にて、解析します。(CaboCha, KNP)
構文解析器に関しては、以前はKNPが良く利用されていたようですが、最近は CaboCha が良く使われるようです。
# SVM を使用していて精度が高い (らしぃ >>19
FreeBSDをベースに開発している所からしてマニアックdayo! ひさびさにmknmzちう...たぶん今日中にはIndexができているだろう。
@@ Processing gzip file ... (using Compress::Zlib)
70/27876 - /usr/share/doc/HOWTO/en-txt/Encourage-Women-Linux-HOWTO.gz [text/plain]
71/27876 - /usr/share/doc/HOWTO/en-txt/Enterprise-Java-for-Linux-HOWTO [text/plain]
@@ モジュール: html.pl
@@ Processing html file ...
72/27876 - /usr/share/doc/HOWTO/en-txt/Esperanto-HOWTO [text/html]
@@ モジュール: gzip.pl
@@ Processing gzip file ... (using Compress::Zlib)
73/27876 - /usr/share/doc/HOWTO/en-txt/Ethernet-Bridge-netfilter-HOWTO.gz [text/plain]
74/27876 - /usr/share/doc/HOWTO/en-txt/Ethernet-HOWTO [text/plain]
インデックスを書き出しています...
所要時間 8.5h でした。
インデックスを書き出しています...
[追加]
日付: Mon Jan 6 19:44:54 2003
追加された文書の数: 22,453
削除された文書の数: 2,890
更新された文書の数: 4,916
サイズ (bytes): 275,352,781
合計の文書数: 40,141
追加キーワード数: 840,373
合計キーワード数: 2,874,103
わかち書き: module_kakasi -ieuc -oeuc -w
経過時間 (秒): 30,674
ファイル/秒: 0.89
システム: linux
Perl: 5.006001
Namazu: 2.0.12
IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/
1 名前:ひろゆき ◆3SHRUNYAXA @どうやら管理人 ★ 投稿日:03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。
27 名前:心得をよく読みましょう 投稿日:03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か?
38 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。
73 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:27 ID:rLfxQ17l
>ところで、IPが抜かれて何か今までと変わることってあるのでしょうか?
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。 >>292
>245
>働かざるもの食うべからず。
ということで、ひろゆきちゃんが保存(w IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/
1 名前:ひろゆき ◆3SHRUNYAXA @どうやら管理人 ★ 投稿日:03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。
27 名前:心得をよく読みましょう 投稿日:03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か?
38 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。
73 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:27 ID:rLfxQ17l
>ところで、IPが抜かれて何か今までと変わることってあるのでしょうか?
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。 >97
2chやってるからヒッキーって責任転嫁が既に敗北者っぽ・・。 原田さんの(odinじゃないやつ)http://www.ingrid.org/~harada/interface/
☆^〜^★「探し物とくとくページ」☆^〜^★
http://sagatoku.fc2web.com/
あなたの探し物きっとみつかります
ほぼ毎日 新着情報追加 毎日更新
新着情報メールでお知らせ
おい、聞いてくれ!
リナックス板の自治厨が、一切規定に反していない
ディストリスレを、通告もなく一方的に削除しやがった!
これは、そのディストリを発売した会社に対する
侮辱であり、1の言論の自由を侵害し
ユーザーに対する差別的行為だ!
まじで、どうにかしてくれ!
2ちゃんねるは、削除人が横暴すぎる!
革命を起こそう!正常化を図るのだ!
>>51
Ruby用APIも入ったみたいだね。
あとメジャーどころでサポートされていないのは
PHPとPythonくらいか。 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧
ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。
=〔~∪ ̄ ̄〕
= ◎――◎ 山崎渉
__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄ ∧_∧ ∧_∧
ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ ( ・∀・) | | ガッ
と ) | |
Y /ノ 人
/ ) < >__Λ∩
_/し' //. V`Д´)/
(_フ彡 / ←>>57-59 (⌒V⌒)
│ ^ ^ │<これからも僕を応援して下さいね(^^)。
⊂| |つ
(_)(_) 山崎パン >>15
8/28 に GETA の微修正があったらすぃ 外国産検索ソフトを日本語化してるようなプロジェクトって無いの? >>70 ほかに適当な板が無かったから…
あと、ビジネスソフト板とウィンドウズ板にはすでにスレッドがあったけど、
そっちはパッケージソフトの話題がメインだったから。 ソフト板に立てたら、オープンソースという言葉だけで変なのが沸いてくるよ。 インデックス作るのが面倒なんでインデックス作らないソフトでのお勧めは何ですか? Snatcherの掲示板より
> とりあえず、QDBMの全文検索機能を日本語化しただけのものを作ってみました。
> 以下の場所に置いてあります。
>
> http://estraier.sourceforge.net/
全然気がつかなかったけど、キテタ━━(゚∀゚)━( ゚∀)━( ゚)━( )━( )━(゚ )━(∀゚ )━(゚∀゚)━━!!!!! うへ、QDBMもEstraierもリリース頻繁杉…
いや、まあいいことなのかもしれないけど、人柱になるのも大変だな。 とか言ってる間にもまた新しいバージョン出てるし。
ハングルの需要とかあんのか? > ハングルの需要とかあんのか?
少なくとも日常的にハングルの読み書きをしている人たちには
需要はあるんじゃない? Estraierに移行するからSnatcherの保守は停止するって掲示版に書いてあった。
それはいいとして、代わりにできたMLが英語だけっぽいのがどうにもこうにも。 msearch使ってるひといる?
namazuより導入簡単だしカスタマイズも簡単だし。 >1 は、「全文検索」と「Index検索」を間違えてないか?
namazuは全文検索じゃないぞ。
スレタイ見たときに、「grepの話か?」と思ったんだが。 >>91は日経Linuxのアレな記事を鵜呑みにしているアフォ。
平河町の書き換えも困ったものだ。 >>93
で、全文検索の正確な定義って何?
俺は当時あの記事みて考え込んだYO 記事のことは知らんけど、
ファイル名や更新日などから特定のファイルを見つけ出すのと違って、
ファイルの内容からキーワードを拾ってファイルを探すのが全文検索。
全文検索にとってINDEX検索とは、検索の一手段ということになる。
って感じか。
>>96
その定義だと「全文」の言葉を使うのはおかしいんでねーの?
むしろ「ファイル検索」というのがふさわしいと思う
あくまでテキストすべて(全文)を検索するから「全文検索」じゃないの?
だったらやっぱりINDEX検索だけだと全文検索の要件を満たさないと思うなー
NamazuがINDEX検索だけなのかどうかは分かりませんが インデックスを作るにあたって記事の全文を対象にしてるわけだから、全文検索と言えるでしょ。
やたら狭義に解釈してもしょうがない。 >>99
INDEX作成はNamazuだと自立語だけしか対象にしないんじゃない?
それって全文対象と本当に言えるのかね
例えば「萌え語INDEX」を作って検索したとしても全文検索? >>100よくわからんが grep なら全文検索なのか?namazuは中身を区切ってindex作って検索するから全文検索ではないと? 語の境界を無視するような検索がしたいときに悲しいとか、そういう話かな…
Namazu は二語のフレイズ検索には対応してて、三語以上は誤認識が入るってことみたいだけど。 >>101
とりあえずgrepは全文検索だよね。指定したファイルについては
全文をだーっとナメてるわけだから
だけどそれだと検索時間がかかるから、いわゆる全文検索ソフトは色々工夫をしてる
そのひとつがINDEX作成なわけですよね
で、私が思ったのは、その工夫によって「全文をナメる」のと違う結果(検索洩れとか)
が出るようなのは「全文検索ソフト」とは言えないんではないかってことです
先に挙げた「萌え語INDEX」は極端な例に見えるかもしれないけど
俺としては「自立語INDEX」(かどうかは知らんですが)も「全文をナメるのとは違う」
って意味では同じだと思う
>>102
フレイズ検索云々を意識しなければならない点で変な気がします
もちろん実用的には問題ないと思っていますし、Namazuは良いソフトとも思いますが
grepで検索するときって、フレイズ検索とか意識しませんよね?
>フレイズ検索云々を意識しなければならない点で変な気がします
日本語で分かち書き処理しないでどうやって処理するの? >>104
分かち書きは全文検索に必須ではないですよ
N-gramとか他にも方法はあるかと
それを検索に使うと効率が悪いように思えるんだが、どうよ?
ttp://www.ya.sakura.ne.jp/~moro/resources/ngram/ N-gramって海外ではむしろ言語及び文字セットの判別の方で
よく使われているような気がする。mnoGoSearchのところの
mguesserとか。 >>106
N-gramだとノイズが増えるのは確かだよ。だけどそのリンク先にあるように検索洩れが少ない利点がある
どっちを使うかは用途次第で一慨に効率が良いとか悪いとかは言えないと思う
だけど今問題にしてるのはそういうことではなくて
検索洩れが生じるような検索方式は全文検索ではない、というのは結構的を射ている指摘じゃないかってことです
もちろん全文検索でなくても有用ならそれで言い訳だし、そもそも全文検索の定義が曖昧なら
どっちでも良いってことだろうけどね
>>109
特許検索とか、洩れが許されない用途での全文検索だとN-gramも結構あると思うよ
何にしても海外とはテキストの性質が全然違うので用語にしても同じ扱いをするのはマズいのかもね
>>94氏が指摘している対立点は、全文を対象としているかいないか、ではなく、
あらゆる検索パターンを検索できるかできないかだと思う。
「全文全パターン検索」ではないと言いたいんでしょ。 >>111
うーん。それよりも「なぜ全パターン検索できないの」→「全文を対象にした検索じゃないからでしょ」
という感じでしょうか。つまり検索対象がfull textならば、全パターン検索できて当然
できない理由はINDEXから情報が欠落しているから、つまりfull text searchではない、という考え方です
結局は「全文検索」って何よ?という定義の問題になるわけですが…
そんなに全文検索がいいなら おれが書いてやるよ。
#! /bin/sh
grep $1 / >>113
乙!
使ってみたYO!
$ ./search.sh gorua
grep: /: Is a directory 文書の編者が意識的に選んだキーワードを頼りにして検索する「キーワード検索」との対比で、
対象文書のテキスト全体を操作して抽出した語やフレーズを頼りに検索する手法を総称して
「全文検索」と呼んでいるのだと思われ。
とすると、必ずしも再現率が100%である必要はないんじゃない? 「全文検索」の「全文」は、grepが対象とするところの、いわゆるプレーンテキスト
の「全文」とは、抽象度が異なるものでしょう。 >>115
キーワード検索ってそういう意味なのかな
単に「キーワードを使った検索」じゃなくてですか?
初めて聞いたんで、そういう用例のWeb文書とか示してくれると嬉しい
>>116
説明が抽象的すぎて分からん
抽象度がどういう風に異なるのか説明してけれ まぁ、定義は馬場さんのページに書いてあるのが
わかりやすいんでないの?
おれは辞書を使わない,わかち書きしないタイプの
インデクス作成型検索エンジンを使ってるけど。 「全文検索」を細分化して概念化しておくことには意味はあるだろうね。
「完全全文検索」とかさ。 >>119
馬場さんのページってこれですよね
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/other-system.html
私の見落としかもしれませんが、ここには全文検索システムの定義は
無いように思います。定義部分を教えてくれませんか
ちなみに「全文検索とは」でぐぐったらこんなのがありました
「漏れなく」なんてあるから私の見方に近いかも
http://www.rosei.or.jp/ISearch/help/user/japanese/is-us02/is-us007.htm
>>115さんの言うキーワード検索の用例もありました
つーか一般的な用法みたいですね失礼しました
http://www.ftsanet.com/dbtokyo02/Db02.htm
http://magazine.fujitsu.com/vol48-3/3-2.html
http://panasonic.biz/it/patlics/faq_1.html
つまり全文検索=フリーワード検索ってことでFA?
ん?それってやっぱりINDEX検索単独じゃ全文検索じゃないってことか?
詳しい方、スパっと疑問を解決してくだされ 例えば「走る」について知りたい時は、「走った」とか「駆ける」といった単語を含む文書も
ヒットしてほしいわけです(そうではない場合もあるでしょうが)。
そのために、形態素解析、ステミング、シソーラス展開といった手法を応用している全文検索
システムも多くあります。
それらはもはやパターンの厳密な一致を探すのとは違う領域にある技術ですよね。
どっちが上とか下とか言うわけではないですが、、、 >>122
そういった要望がありそれを実現するための技術があるのは分かります
で、その技術で検索幅が広がるのはいいんです。ブレるのは検索パターンの方であって検索対象はfull textですから
ただ、ここで問題にしてるのは、そういった工夫によって検索漏れが生じるようなシステムが「全文検索」の名に値するかってこと
しかも検索漏れの原因が「INDEXに検索パターンがのってない」ってことにあるなら
「それって検索対象がfull textじゃないじゃん」つまり「全文検索ではない」と思う人がいてもおかしくない
まぁ、ここ数日で「全文検索」という用語がかなり曖昧に使われているのが分かって来たんで
厳密性を求めるのは野暮ってもんでしょう。そして日経Linuxが嘲笑されたのは、まさしくこの「野暮」が原因でしょうな
実は私もあの記事を読んで最初カチンと来た。馬鹿じゃねーのとも思った
だけど上で書いたように「全文検索」をgrepと同様、検索漏れのないシステムと考える人もいるとした場合、
野暮をおしてああ書くのは親切というか、良心的なんじゃないかと思い返したわけです でさ、>>122氏が言うように私の言う狭義の全文検索システムであろうがなかろうがどっちでもいいわけです
実用上は、ユーザーが特性を理解して、目的に合わせて使えば良いわけです。Namazuが有用ってことにも異義はないし
でもだったらさ「全文検索システム」と言わなくてもいいわけじゃん。「語句検索システム」とか誤解のない言い方はあると思う
(この用語はあくまで例で最適とも誤解がないとも言いませんが)
「全文検索」という用語には、そんなに魅力があるんすかねぇ 閑話提供
ttp://www.jepa.or.jp/ken/Ken_00.html
繰り返しになりますが、全文検索は、
「属性やキーワードを改めて付与するなどの手間をかけずに、機械的にテキスト全体をスキャンし、
ユーザが所望の文書を捜し出す技術」
の総称なわけです。
grepの文字列探索は、全文検索を実現するにあたって実装方法の一つであることは確かです。
もちろん、予め文字列から単語を切り出してインデックスを作成する手法も、実装方法の一つです。
インデックス型の弱点として、単語の切り出し方がユーザの想定するものと違う場合に期待通りに
検索できないということがありますが、それは速度と精度のトレードオフを考えて実装上の選択を
した結果に過ぎません。つまり、「全文検索」は目的であって、実装については言及していないという
わけです。
そもそも、全文検索という語に定着した意味や用法が、自分の想定したニュアンスと違うから
といって、「お前ら間違ってるよ」的な事を言っても仕方のないことです。 >>126
繰り返しとか言ってるけど、そういう定義をまとめてくれたのはこのスレでは初めて聞いたよ
定義してくれたのは感謝するけど、一応
つまりあなたの定義だと「萌え語辞書」を使った「萌え語INDEX」を使ったテキスト全体をスキャンする検索システムは
何の注釈もなく全文検索システムと言っていいわけですね。何か一般に想定する全文検索システムと違う気がするけど、いいんですか?
それともこういう仕組みは「属性を改めて付与」することになるので違うってこと?
だったら何で「自立語」という属性は付与していいの?
>>「お前ら間違ってるよ」的な事を言っても仕方のないことです。
何だかんだ言ってるけど、私も全文検索システムの解釈にブレがあるのは理解してるわけよ
だったらさ誤解がないように、より厳密な用語を使って行こうという気はないの?
結局、誤解して困るのはユーザーなんだし
ああ勘違いしてた。Namazuでは付属語を捨てたりはしてないのか
「自立語」というのは「形態素」におきかえてくだされ。それでも文意は変わらんと思う
> 何だかんだ言ってるけど、私も全文検索システムの解釈にブレがあるのは理解してるわけよ
> だったらさ誤解がないように、より厳密な用語を使って行こうという気はないの?
> 結局、誤解して困るのはユーザーなんだし
例えるなら「スポーツカー」に厳密な定義ができないように、「全文検索」にも厳密な定義は
できないと思います。乗る人がスポーティだと思ってくれるような車はスポーツカーでいいと
思います。同じように、ユーザが対象文書の全体をスキャンしているような気分で検索できる
システムは全文検索システムと呼んでいいと思います。
もちろん、あなたの感じ方と私の感じ方は違ってあたりまえですから、私があなたの定義を
否定したりはしませんが。 >>129
>同じように、ユーザが対象文書の全体をスキャンしているような気分で検索できる
>システムは全文検索システムと呼んでいいと思います。
やっぱそんなぐらいの曖昧な用語だってことですかね。「気分で」という表現いいなw
>>130さんの言うように俺定義の話を続けてもアレなんでこの辺で私は終了にしますわ
形態素解析方式の全文検索エンジンは実用にならないってのは一般的な見解ですか?
俺的には、シビアなユースケース(特許検索とか)でなければ十分使えるというか、
大抵のケースではn-gram方式より使いやすいと思うのですが。 #! /bin/sh
find / -print | xargs grep $1
>>133 なんで find なの? 普通は grep -r では? >>135
それはGNU grep 2.3以降の機能。
N-gram をつかったフリーの全文検索ソフトはありませんか?
検索対象のファイル数は数千ファイルです。 gonzui: ソースコード検索エンジン
http://gonzui.sourceforge.net/
Rast - N-gram based full-text search system
http://www.netlab.jp/rast/
Estraierの中の人の開発メモ。Hyper Estraierを作るらしい。
http://qdbm.sourceforge.net/mikio/rbbs.cgi 朱雀、v2 リリース
ttp://hoshizawa.no-ip.com/suzaku/ 全文じゃないのですが、イメージ検索できるエンジンってないでか?
相当ググったんですが・・・やはりないんですかね? 4 名前:仕様書無しさん[] 投稿者:2005/04/12(火) 00:17:42
blogWatcher
http://www.lr.pi.titech.ac.jp/blogwatcher/blog/
が検索エンジンを情報処理振興事業協会(IPA)が実施した
「独創的情報技術育成事業」の研究成果であるGETAから
オープンソースで開発されているLuceneに変更したのは
GETAが税金を無駄にしただけの糞で鈍間で役立たずの
ポンコツだと言うことですか?
Namazuだと、全然文字が引っ掛からない(INDEX作成にはkakashi, chasen,
どちらも使ってみました)のです…
INDEX自体はまともに作成されてるようなのですが、
そもそも、適切に分ち書きできてないみたいです。
何か設定を変更することで上手く行くようになりますでしょうか。 mknmz -L jaでインデックス作るとどうよ。
>>154 LANGUAGE とか LC_ALL の環境変数が ja になってないと
日本語keyword 正しく生成しないんだが、その話しか? >>159
> そうなの?今はどうなの?
…… (あきれている) >>154
あるねぇ、あれは酷い。
まぁ、FAQには書いてあったからいいけど。
さっさと捨てるべきだとおもったよ。 rast ML 発見
http://www.netlab.jp/rast/index.html.ja#label-12
rast 0.3.0 もリリースされてます
http://www.j96.org/w3ml/rast-ja/msg/2
あと matz 氏の morq もついに公開されたようですが…
debian sid な環境ですが動かすことはできず。orz luceneってむちゃくちゃよくね?
小規模なら、何も考えずに使えるし、
日本語もそのまま通る。
俺何か見逃してるかなぁ。 >>165
昔、日本語が使用できなかったとか、Javaベースだからとかじゃない?
使用することに限ればnamazuやHyper Estraierでもいいと思うけど。
>>165
小規模ならいいけど、大規模(10万件以上)だとめちゃくちゃ遅い >>166
LuceneはC#へのポーティングがあるな。 で、世の中 Google Desktop Search とか Spotlight が当たり前になってる今、
みなさん最近は何使ってんの? >>174
> が当たり前になってる今
なってねーよ。 ご存知の方おられたら教えてください。
Nutchは、AnalyzerにデフォルトでNutchAnalyzerを使っていて、
日本語はインデックス作成時に(クエリー処理時も)1文字ずつに
分解されてしまいます。そこで、bigramでインデックスを張れる
CJKAnalyzerを利用しようかと思ったのですが、nutchのソース修正が
必要でしょうか? pluginをいじるだけでできるかと調べたのですが、
なにぶんドキュメントが少なくて、よくわかりませんでした...。 ttp://wiki.apache.org/nutch/MultiLingualSupport
ttp://mail-archives.apache.org/mod_mbox/lucene-nutch-dev/200606.mbox/%3Cc822c4ce0606070158s6c16abc7yea846a546e735cf4@mail.gmail.com%3E Google や Yahoo! がやっているような、表記揺れの展開をやってみたいのですが、
全文検索ソフトと併用できるような便利な表記揺れ展開用の辞書かライブラリってあるのでしょうか。
それとも自分で辞書を作らなければならないのでしょうか。
代用漢字、異体字、カタカナ語、送り仮名、検索ワードの誤り、略称、関連語など、
考え出すときりがないとも言えるのですが…
企業向けの商用ソフト(の形態素解析ソフトのおまけ?)にはあるらしいことは一応わかってきました。
なにかアドバイスください。 >>179
どこかの国立の日本語研究所が表記揺らぎ辞書を公開してたよ。 国立国語研究所の「表記統合辞書」ですね。ありがとうございます。
kokken.go.jp がつながりにくいようですが…
必要に応じて電話で問い合わせしてみようかしら。 html内で、コメントを使わずにスタイルシートのhiddenを使ってコメントアウトしているページがあり
NAMAZUはもちろん対応していないのですが、対応できる検索エンジンってあります? >>184
そうですよね。googleでも引っかかってしまうし。 対応ってどういう意味だろう。
そこが検索でヒットされて欲しくないってこと?
そんなエンジンはないだろうな。 対応できるってどういう意味だろう。
「作ればあるもん」だと思うのだが。 rastって死亡? なんか実質1年くらい動きがなさそうなんだけど。
matzがいるような会社でも、IPAから金めぐんでもらってやってただけで
それがなくなったら後は野となれ山となれなのかね? もしそうだったら寂しいね。 >>188
長い目で見れば、死亡させた方が金になるんだよ。 Hyper Estarierは未踏で開発が加速して、今はまったりとしつつも
きちんと続いている。
SennaもMySQL連携が効いたのか、じわじわと利用が進んでいる。
Rastはなあ... 構造を複雑にしすぎて、金が切れてからのメンテナンスが
難しくなったんじゃないかという気がする。あとは外部からの開発者を
集められなかったことが敗因か。
>>190
> 難しくなったんじゃないかという気がする。あとは外部からの開発者を
> 集められなかったことが敗因か。
いや〜
金をもらって作られたブツの世話を引き継いで、タダで作業するのって、惨めだぞ〜
特に多大な金が投入されたことをみんなが知っていると、いろいろあって鬱病になりそうになる。
もう2度とやりたくない。 >>191
作者はじつにいい会社に転職したよね。今後も安泰かというと不安だけど...
>>192
気持ちはよくわかる。最低限、「自分が使うから」ぐらいのモチベーションが
ないとやっていけないよなあ。
>>181
これの固有名詞版ってないのかしらん?
USA、米国、アメリカ、U.S.→アメリカみたいな 人少ないみたいだからアゲますね。
ちょっとダサい質問なんですが、インデックスを作成するタイプの全文検索で
そのものがインストールされていないレンタル鯖で使えるものってありますか?
PerlもしくはRubyから検索したいと思って
Namazu、HyperEstraierを試したんですが、
前者はPerlモジュールのインストールを断られ、
後者はインデックスがQDBMの形式だからどの道無理かと思いました。
(方法があればHEの方は使ってみたいけど)
頻繁に更新されるような対象じゃないので、MySQLのFULLTEXTでも・・・
と思ってはいるんだけど、
なにか方法(ソフト)があればおしえてください。 http://rubyforge.org/projects/ferret/
pure rubyでこんなのがあるよ。日本語が使えるかどうかはわからないけど。
Luceneにinspreされたとかいてあるから、UTF-8なら使えそうな気もする。
>>196
少し触ってみたところ使いやすい感じで好感触でした!
完全かどうかはわかりませんが、日本語も大丈夫でした。
とりあえずレン鯖での動作も確認できました。
まだ不明な点もありますが、しばらく使ってみようと思います。
ありがとうございました! gonzuiみたいなのでVB6検索できるエンジンありませんかね?
VB6病発病したソースコードを手術しないといけないので
頼みます。 こんなん出てた。
全文検索エンジンLux
http://luxse.sourceforge.net/
ToDo のところに
# 削除・更新
# 全角半角かなの同一視
とか書いてあるあたり見ると、まだ全然未完成みたいだけど。 apacheのluceneがeclipseのヘルプ?で使われていたことを知った。
InfoCrawlerとOmniFindってどう?
今研究室の文書管理システムを作らなきゃいけないんだが,ユーザビリティを損なわず文書管理したい.
ファイルドラッグできるフリーなシステムは見つからない.
⇒Sambaフォルダに適当にぶち込んで後から見るときは検索でおk
と言う風に今は考えてるんだが、間違ってないよな?
doc,pdf,ppt辺りを読み込んでくれる素敵なエンジンはない物か… ど素人の質問で申し訳ないんですが、
ひらがな/カタカナのどちらでも検索可能にしたい場合、
「検索時に、両方のキーワードで検索する」案と、
「インデックス自体を、両方作っておく」案の、どちらが検索時間が短くすむのでしょうか?
(検証しろと言われれば、それまでなんですが)
私の事情的には、「大差はない」というのが理想ですが、
どうなんでしょうか?
ちなみに、使ってるのはLucene(2.3.2かな)で、すでに運用開始している状態です。
常にひらがな/カタカナのどちらでも検索していいなら、
インデックス作るときに、どっちかにまとめてしまうな。
あとは、検索時に指定されたのを同じルールで処理してから検索。
データが小さくなるし、analyzerでこの処理をさせれば、
本文はそのままだから、取り出し可能にもできるし。 あと、データ量と同時検索数次第な気がするけど、
両方のキーワードで検索した方が速いと思うよ。
インデックスを小さくしておいた方が速いと思う。
ひらがな/カタカナ混じりだったらどうするとか考えると、
統一しちゃう方が簡単だと思うんだよなー。
検索用フィールドをいくつか作るのはありかもね。
平仮名片仮名を無視する検索用はどちらかに統一して、
そうじゃない方はそのまま入れておく。 >>206
レスありがとうございます。
やはり「INDEXも検索も統一」というのが良さそうですね。
ただ、すでに運用してるシステムでして、
根本から作り直すことになると、コストやリソースの関係で、
お客様の希望する時期に出せそうになかったもので、
質問のような小手先の対応を考えていました。
dpkgとzeitgeistがXapianっていう全文検索ソフトを使っているけれどあれは何?
対応言語に日本語は入っていないみたい postgresql 使ってるのか。
Hyper Estraier でいいと思うけどなあ。ずっと楽だし >>209
NOT FOUNDだよ
半年も前かぁ・・・(´・ω・`) Fessというソフトなんですけど、
検索されたファイルの名前に、スペースが含まれている場合に、
一覧から開くことができません。
対策ってありますでしょうか。 >>212
FessのMLがあるからそっちで聞けば? 聞こう聞こうと思っているうちに、
どなたかがメーリングリストで質問してくださっていました。
今、その回答町です。 専用サーバソフトいらずで
単純なインタプリタcgiのみで動くやつないかね?
まあ要するにフリーのレンサバで動かしたい 自分はセナがいいよとか言われてた時代までしか知らん
ナマズは定番とかね 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
78TOY3CJA0 僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
MT3J0 Elasticsearchとかsolr/luceneとかじゃないの NASとかでも検索機能あったりするけど
目に見えてどれを使ってるって分かるのかな?
その中でのシェアとかあるの? チエオクレのハゲの悲惨なツイッター
https://twitter.com/aphonedollar
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
この自称「ハゲ」とかいうチエオクレのブログが酷すぎる
>「DesktopHE」 はWindows10に対応してないらしい
はぁ??? ★★★大嘘デタラメ★★★を垂れ流すな!!!
■「DesktopHE」 はWindows10でも、もちろん使えるわ!!!■
■「DesktopHE」 はWindows10でも、もちろん使えるわ!!!■
■「DesktopHE」 はWindows10でも、もちろん使えるわ!!!■
■「DesktopHE」 はWindows10でも、もちろん使えるわ!!!■
■「DesktopHE」 はWindows10でも、もちろん使えるわ!!!■
チエオクレのこのハゲが、Javaの設定を失敗してるだけじゃねえか!!!
嘘デタラメ垂れ流しやがって、このハゲがやっていることは立派な公害じゃねえか!
hatenaとかでまで、必死こいて大嘘をばらまいているんだが
https://twitter.com/5chan_nel (5ch newer account) 今時はLuceneですかね
Twitterでも使われてるらしいし