【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

GreppingInWiki - Wiki上からWikiの各ページのデータを grep できると非常に便利です。

目次

Wiki上からWikiの各ページのデータを grep できると非常に便利です。

(←Perlより派生)

検索ページから検索するのではなく、ページ内に検索式を書いておいて、ページを表示するときに実行されて結果が埋め込まれるようにできないでしょうか。

Proposal

Perl について書いてあるページを一覧するためにはページの片隅に

 % grep -il perl *

と書いておくとか、Wiki中に書かれた URL を全部取り出すために

 % fgrep 'http://' *

と AllWebLinks? なんていうページに書いておくとか。全文検索が重いという場合は最後の * を特定のページ名にマッチするようなパターンにして絞り込みます。

応用技

逆に、各ページに抽出されることを前提にしたメモを一行書いておくという応用もできます。

当ページに例えば

 category: Wikiの使いこなし
なんて書いておいて、CategoryIndex? のようなページに

 % grep ^category: *

とすると、ページ名+カテゴリという形式でインデックスを自動作成できます。

こうなってくるともうちょっと欲が出てきて

 % grep ^category: * | sed s/\([^:]*\):category: \(.*\)/\2 (\1)/ | sort

みたいなことがやりたくなってしまうのですが。:-)

コメント

確か正規表現って

同じ目的で構築しても、書き方次第で妙に負荷が高くなったりしますよね。 しかも、それをCGI呼び出し時に毎回実行すると負荷高くなりすぎな予感がします。 でもアイデアは良さそうなので使ってみたい気もします。Wikiの検索機能の弱さを補ってくれそうですし。

たとえば折衷案として、ページ群全体の最終保存時刻をもとにgrepの実行を抑制してキャッシングするという案はいかがでしょうか。 読まれることのほうが多いWikiなら、十分に効果がありそうです。 処理結果のキャッシングは、高機能化を辿るWikiにとって、いずれは通ることになる道だと思います。 ぜひ。


負荷を考えると

ページに Google などの検索エンジンで

  <キーワード> site:<Wiki設置URL>

な検索をしてくれるリンクを埋め込むほうが現実的でしょう。


例えば逆リンク表示機能

を実装しているPukiWikiその他が問題なく稼動しているところを見ると、 ページを表示する際に全ページを全文検索する処理はそれほどの負荷ではなさそうです。 %grep と書いてあるからといって grep コマンドを起動する必要はないですし。 (PukiWikiあたりは逆リンクのデータをキャッシュしてるかもしれませんが。)


推測ですが。

実は負荷低い?


単純部分文字一致検索なら

実装して使っています。

正規表現を使うことの問題としては、Wikiは誰でも書き込めてしまうので、 バックトラックしまくりの非常に重い正規表現を書き込まれると、 そのページの表示ができなくなってしまう(プチDoS?)可能性があるってことですかね。 (通常使うような正規表現は遅くはないですが、遅い正規表現を書くことも「可能である」というのが ポイントです。)

利用者の視点で見ると、、、

Perlの正規表現の全てを必要とする利用者・状況は少ないと思います。だとすれば、 制限つきの導入でも、正規表現マスター以外はとても幸せになれそうに思います。 すぐに思いつくのは、括弧の数に上限を設けるとか、$1等による逆参照の制限とか。 負荷に関する問題を含んだまま実装、運用するよりは、 正規表現の一部機能をばっさり捨てたほうが合理的かと思います。 --Coffee


検索に対する対応ならば、学習型インデックス方式でよい気がします。

1.過去に検索された文字列を記憶しておく 2.ページの内容を更新するタイミングで、それぞれの単語を含んでいるか記録する。 3.新しい検索時に、インデックスを参照する。 4.インデックスに含まれていない場合には全文検索を実施し、これを元にインデックスも更新する。

本来は茶筅とか使うのが楽なんですが、辞書が大きいので安価版。 でも、よく検索される言葉もわかるし、一石二鳥かと。 できる限り、書き込みの段階で下準備するのがよいと思います。