2010年4月アーカイブ

Namazuをしばらく使ってみたが、どうも、調子が良くない。 キーワードが含まれているファイルが見つからなかったり、含まれていないファイルがリストアップされてしまったりする。 そこで、DesktopHEを試してみることにした。 DesktopHE -Hyper Estraierを使用したWindows用デスクトップ検索ツール- インデックス作成速度、検索速度も非常に速く、大量の大きなファイルも問題なく処理できる。 ただ唯一の問題は、複数のインデックスを使い分けることができないこと。 ソースが公開されているので、改造もできなくはないだろうが、Javaなので今一つ自信はない。 そこで、インデックスの作成は、コマンドラインで行い、使用するインデックスは、必要に応じて手で書き換える事にした。 コマンドラインはHyper Estraier本家のユーザガイドを参考に、インデックスの更新のための実行ファイルを作成した。 まあ、どちらにしろ、コマンドラインによる更新の方が使い勝手は良かったので、よしとしよう。 User's Guide of Hyper Estraier Version 1 (Japanese)

set ESTDIR="C:\Program Files\DesktopHE"
set ESTCMD="%ESTDIR%\estcmd.exe"

set INDEXDIR="C:\Documents and Settings\nor\Application Data\DesktopHE"

cd %ESTDIR%

%ESTCMD% gather -il ja -sd -cm -pc CP932 -lf 10 %INDEXDIR%\index c:\home
%ESTCMD% gather -fx .pdf,.rtf,.doc,.xls,.ppt,.docx,.xlsx,.pptx,.sxw,.sxc,.sxi,.sxd,.odt,.ods,.odp,.odg,.jtd,.jtt T@estxfilt -fz -ic CP932 -pc CP932 -sd -cm -lf 100 %INDEXDIR%\index c:\home

%ESTCMD% gather -il ja -sd -cm -pc CP932 -lf 10 %INDEXDIR%\indexn C:\prj\mail\news

%ESTCMD% gather -il ja -sd -cm -pc CP932 -lf 10 %INDEXDIR%\indexh C:\prj\mail\hatena

for %%f in (index indexn indexh) do %ESTCMD% purge -pc CP932 %INDEXDIR%\%%f
for %%f in (index indexn indexh) do %ESTCMD% extkeys -um %INDEXDIR%\%%f
for %%f in (index indexn indexh) do %ESTCMD% optimize %INDEXDIR%\%%f

local.cfで"report_safe 0"にしたのだが、いつのまにかオリジナルのメールが添付ファイルになるようになってしまった。 どこかで、ルールセットが上書きされているようだ。 調べてみると、sa-updateでアップデートされるルールセットで"report_safe 1"に設定されている。 sa-updateでアップデートされるルールセットは、local.cfより後に読み込まれるため、で上書きされてしまう。 そこで、これらのルールセットを一番最初に読み込むように以下の行を、local.cfの一番最初に記載する。

include /var/lib/spamassassin/3.002005/updates_spamassassin_org.cf

SapmAssassinが順調に機能しているようなので、POPFileを停止することにした。 いままでは、POPFileのバケツによる振り分けに頼っていたが、SpamAssassinではspamの切り分けしかできないので、しばらくの間はi-forwardの転送設定を鍛えないといけない。 もちろん、同時にThunderbirdの振り分け設定も、やり直すことにする。

ベイジアンフィルタを有効活用するためには、spamを学習させる必要がある。 指定のフォルダ(spam)に入っているものは、自動的にspamとして学習、削除するという方法が一般的だが、あえて登録専用に、sa_spam、sa_hamという二つのフォルダを作り、そこに入れたもののみ登録するという方法をとることにする。 # vi /etc/cron.daily/spam-learn

#!/bin/bash

PATH=/usr/sbin:/usr/bin:/bin

HAMS=sa_ham
SPAMS=sa_spam
MAILDIR=/home/nor/Maildir

sa-learn --ham ${MAILDIR}/.${HAMS}/cur/*
rm -f ${MAILDIR}/.${HAMS}/cur/*

sa-learn --spam ${MAILDIR}/.${SPAMS}/cur/
rm -f ${MAILDIR}/.${SPAMS}/cur/*

# chmod +x /etc/cron.daily/spam-learn

SpamAssassin自体のインストールが完了したので、次はPostfixへの組み込みになる。 もちろん、Postfixの機能だけでSpamAssassinでフィルタリングすることはできるのだが、ちょっと調べていたところ、さらに良さそうな方法を佐藤氏のBlogにて見つけた。 Postfixの設定でClamSMTPと、受信時だけSpamAssassinを利用する - モーグルとカバとパウダーの日記 spampd、SMTPを話すSMTPプロキシだ。 これであれば、常時spamdを立ち上げておく必要もない(代りにspampdを立ち上げておかなければならないが...) そして単純なフィルタに比べ、リソース問題にも強く、(きちんと設定すれば)パフォーマンスも高いようだ。 spampdからspampd-2.30.tar.gzをダウンロード。 完全なPerlプログラムで、makeなどの必要はない。 /usr/local/binにコピーして、付属のspampd-rh-rc-scriptをほぼそのまま/etc/init.d/にコピーする。 $ sudo cp spampd-rh-rc-script /etc/init.d/spampd いくつかのファイルを 佐藤氏のBlogを参考に修正する。

/etc/postfix/main.cf

smtpd_recipient_restrictions =
  ...
  reject_unauth_destination
  check_client_access    regexp:$config_directory/filter_spampd
  ...

content_filter = 
receive_override_options = no_address_mappings

/etc/postfix/filter_spampd

/./             FILTER scan:127.0.0.1:10025

/etc/postfix/master.cf

# SA scan filter (used by content_filter)
scan      unix  -       -       n       -       10      smtp
        -o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10026 inet  n -       n       -       10      smtpd
        -o content_filter=
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
        -o smtpd_helo_restrictions=
        -o smtpd_client_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks_style=host
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8

/etc/init.d/spampd

daemon spampd --port=10025 --relayhost=127.0.0.1:10026 --tagall --auto-whitelist

設定が完了したら、 # /etc/rc.d/init.d/spampd start # postfix reload 動作が確認できたら、 # chkconfig spampd on # chkconfig --list spampd

SpamAssassin日本語パッチ版のインストールも完了したので、まず、ルール設定。 ルール設定だが、サンプルとして、配布されているルールでとても参考になると思われるものは2つ。 一つは松田氏が公開しているuser_prefs。 もう一つは、日本語対応パッチに対応したルールセットのサンプル。 http://spamassassin.jp/download/rules/jp_rules-20060729.cf まずは、松田氏のuser_prefsを基本に、日本語ルールセットを追加していくことにした。 今回は、サーバに到着したすべてのメールをPostfix内から呼び出したSpamAssassinで処理することを考えているので、すべての設定は/etc/mail/spamassassinに集約する。

local.cf

最終行以下に追加。 sa-upateでルールを上書きされないように、アップデート用のファイルを最初に読み込むようにする(4/20追加)。

include /var/lib/spamassassin/3.002005/updates_spamassassin_org.cf

NFSを使っていないので、パフォーマンスを上げるために追加。

lock_method flock

出力において、本文を加工せず、SPAMかどうかに限らず、SpamAssassinのへッダをつけるために以下を指定。

report_safe 0
add_header spam Flag _YESNOCAPS_

日本語化を有効にするために、(すでに)追加。

normalize_charset 1

ベイズデータは、全ユーザ共通のものとするために以下を指定。

bayes_path /var/spool/spamassassin/bayes
bayes_file_mode 0700

ただし、実際に読むのはユーザmail(もしくはroot)だけなので、ファイルモードは600でよい。 ここで気をつけるのは、bayes_pathにはパスだけでなく、ファイル名のベースになる部分を書くと言うこと。 この結果/var/spool/spamassassinの下にbayes_with_toksとbayes_seenが作成される。 まず、事前に、 # mkdir /var/spool/spamassassin # chown mail:mail /var/spool/spamassassin 作成されたら、 # chown mail:mail /var/spool/spamassassin/bays* # chmod 600 /var/spool/spamassassin/bays* 松田氏作のuser_prefsを読み込むために。

include user_prefs

v310.pre

松田氏によると、Auto White Listは、結局From、Toの詐称が多いSpamの現状から、無意味。 同感するので、Auto White Listは切る。

# AWL - do auto-whitelist checks
#
#loadplugin Mail::SpamAssassin::Plugin::AWL

user_prefsのok_languages ja enを有効にするために、以下の行のコメントアウトを解除。

# TextCat - language guesser
#
loadplugin Mail::SpamAssassin::Plugin::TextCat

さらに、松田氏のuser_prefs向けドキュメントにあるように、以下のコメントアウトも解除。

# MIMEHeader - apply regexp rules against MIME headers in the message
#
loadplugin Mail::SpamAssassin::Plugin::MIMEHeader

# ReplaceTags
#
loadplugin Mail::SpamAssassin::Plugin::ReplaceTags

user_prefs

松田氏のuser_prefをそのまま使う。 $ wget http://tlec.linux.or.jp/docs/user_prefs ただし、更新をチェックして、最新版を常に使うようにする。 wgetを利用した自動更新も考えたが、手動でルールを入れ替えて動作を確認しての方が良いので、別途大元の更新チェックのみ行うことにする。

private_prefs

user_prefsから呼ばれるprivate_prefsを作成。 MYMTAは不要になったと最新のuser_prefに記載がある。 ドキュメントには、trusted_networksに127.0.0.1/8があるが、これを書いてしまうと、lintで以下のような警告が出るので外す。 [6096] warn: netset: cannot include 127.0.0.1/8 as it has already been included

trusted_networks 192.168.0.1/16 10.0.0.1/8 172.16.0.1/12 219.117.204.128
internal_networks 192.168.0.1/16 10.0.0.1/8 172.16.0.1/12 219.117.204.128

# replace_tag   MYMTA (mail\.rally\.or\.jp|rally\.jp)

とりあえず以上の設定が完了したら、"spamassassin --lint"で設定を確認。 本来なら、sa-updateでルールセットの更新を行うべきなのであろうが、本家のsa-qupdateで提供されるルールセットではspamの閾値が5、松田氏のuser_prefでは閾値が13に設定されているので、同時に使うことはあまり意味がない。 そこで、sa-updateはあえて無視することにする。 また、今後の使用の中で、日本語版用ルールセットの内容は、private_prefに徐々に追加していくことにする。

考えた末に、結局日本語パッチもあてることにする。 フィルタによる選別結果を転送の基準付けに使用しているので、やはり精度が高いことが望ましいからだ。 まず、すでに(なぜか)インストールされている、3.3.1をアンインストールする。 # yum remove spamassassin

perl-Encode-Detect

すでにperl-Encode-Detect-1.01-1.el5.rf.i386がインストールされている。

MeCab 0.93

MeCab関連のインストールはちょっとてこずった。 MeCab: Yet Another Part-of-Speech and Morphological Analyzerより、mecab-0.98.tar.gzをダウンロード、 "--with-charset=utf-8"をつけて、configureなのだが... src/mecab.h内の以下を修正しておく必要がある(数字に付いている括弧を外す)。

#define MECAB_NOR_NODE  0
#define MECAB_UNK_NODE  1
#define MECAB_BOS_NODE  2
#define MECAB_EOS_NODE  3
#define MECAB_EON_NODE  4

#define MECAB_USR_DIC   1
#define MECAB_SYS_DIC   0
#define MECAB_UNK_DIC   2

これを直しておかないと、Text::MeCabのmake testでエラーになってしまう。 $ tar zxvf mecab-0.98.tar.gz $ cd mecab-0.98 $ ./configure --with-charset=utf-8 $ make $ sudo make install (/usr/local/libが、/etc/ld.so.confに書いてあるのを確認して) $sudo /sbin/ldconfig

MeCab IPA 辞書

やはり、MeCab: Yet Another Part-of-Speech and Morphological Analyzerからmecab-ipadic-2.7.0-20070801.tar.gzをダウンロード。 char.defのASCIIの部分をを以下のように編集。

# ASCII
#0x0021..0x002F SYMBOL
#0x0030..0x0039 NUMERIC
#0x003A..0x0040 SYMBOL
#0x0041..0x005A ALPHA
#0x005B..0x0060 SYMBOL
#0x0061..0x007A ALPHA
#0x007B..0x007E SYMBOL
0x0021..0x007E ALPHA

$ ./configure --with-charset=utf-8 $ make $ sudo make install 文字コードは当然utf-8。

Text::MeCab

cpanでインストール可能。 文字コードは当然utf-8。 # cpan Text::MeCab なお、前述のmecab.hの修正を行わないと、make testでエラーが発生するため、cpanはもちろん、http://search.cpan.org/~dmaki/Text-MeCab/からダウンロードしたtarballからもインストールできない。 最初、ぐぐってみた結果いくつか見つかったMakefile.PLのパスの修正をしたのだが、ダメだったので試行錯誤。

日本語パッチ版SpamAssassin

SpamAssassinから、Mail-SpamAssassin-3.2.5.tar.gzをダウンロード、さらに日本SpamAssassinユーザ会から、spamassassin-3.2.5-ja-test1.patchをダウンロード、展開して日本語パッチをあてて、インストール。 $ cd Mail-SpamAssassin-3.2.5 $ patch -p1 < spamassassin-3.2.5-ja-test1.patch $ perl Makefile.PL $ make $ make test $ sudo make install このままだと、ログにwarningがでるので、/usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/Plugin/Tokenizer/MeCab.pmのsub tokenizeを以下のように修正。 参考: http://xoops.fens.net/modules/wiki/?Linux/cfg/Mail-SpamAssassin-3.2.5

    for (my $node = $mecab->parse($text); $node; $node = $node->next) {
#      push(@buf, $node->surface);
      if ( defined $node->surface) {
       push(@buf, $node->surface);
      }
    }

/etc/mail/spamassassin/lcoal.cfに次の行を追加。

normalize_charset 1

tokenizer.preを/etc/mail/spamassassin/にコピーして、以下の行をコメントアウトして、

loadplugin Mail::SpamAssassin::Plugin::Tokenizer::SimpleJA

以下の行のコメントを解除してMeCabを有効化。

loadplugin Mail::SpamAssassin::Plugin::Tokenizer::MeCab

これで、SpamAssassin 3.2.5 + 日本語パッチ自体のインストール自体は完了。

現状、POPFileの精度、そして、複数のバケツを使ったIMAPフォルダ上での自動振り分けには十分満足しているのだが、いずれは自前のメール(IMAP)サーバは無くして、プロバイダに預けて運用するという最終的な方針を考えると、POPFileの使用をそろそろやめることを検討しなくてはいけない。 POPFileによる自動振り分けは非常に便利なのだが、POPFileのIMAP対応がINBOXをスキャンし振り分けるというサーバ側での動作なので、自前のメールサーバを持たない限りは使いにくい。 どこかで妥協しなくてはならないので、プロバイダのメールサーバを使うことを優先とし、POPFileの使用をあきらめることにする。 rally.or.jp、rally.jpのアドレスは残すが、IMAPをサポートしているプロバイダを使用するのであれば、外部にメール委託をしても大きな問題はない。 また、外部からのメールの参照も、GMailへの転送が可能な限り、大きな問題にはならないだろう。 さらに言えば、どのクライアントからも保存したメールを読むことができるというIMAP自体は非常に便利ではあるのだが、実際にサーバに大量のメールをため込んでしまうと、通信によるオーバーへッドが大きい。 Thunderbirdで実装された全文検索機能などでは大きな弱点になる。 また、サーバが遠い場所にある場合のフォルダスキャンなどの待ち時間も長くなってしまう。 大規模組織かつ通信速度が高速である場合は、本来のIMAPが生き、ストレージをまとめることができるというメリットも大きくなるのだろうが... ということで、一定期間が経過したメール、単に記録として取っているレベルのメールは、IMAPフォルダからクライアントに移してしまい、IMAPフォルダは可能な限り軽量にしておくという運用を考えよう。 こうなると、POPFileの自動振り分けよりも、IMAPフォルダからローカルに振り分けることが可能なThunderbirdの振り分けの方が都合がよい。 前置きが非常に長くなったが、要するにPOPFileはやめて、新規のスパムフィルタを導入したいと言うことだ。 SpamAssassin、Bogofilterb、bsfilterの3つが有名どころ。 bsfilterは日本人が開発していると言うこともあり、日本語対応については一番安心感がある。そういえば、以前は使っていて、不満もなかった。Rubyで動く。 Bogofilterは、そのままではどうやら、日本語の扱いがあまりうまくないらしい。ただ、Cで作られているゆえに、動作は軽いだろう。 bogofilter を正しく使おうという、日本語をうまく扱う方法も見つかったが、ちょっと面倒だ。 そして、SpamAssassinは、Perl製と言うことで、若干重いと思われるが、多機能で拡張性も高く、ベイジアンフィルタ以外によるSpam発見機能が豊富。 ただ、若干日本語の対応には難があり、日本語パッチをあてる必要がありそうだ。 日本語対応パッチをあてるというのは、yumによりSpamqAssassinをインストールして使おうと考えている僕には、向かない手段だ。 さらに、日本語パッチは、3.2.5のものまでしか出ておらず、yumでインストールすることもできない。 ウノウラボ Unoh Labs: ベンチャー流のスパムメール対策術（後編） この実験では、どうやら日本語対応パッチをあてていないSpamAssassinとbsfilterでは速度がほぼ変わらない。 そこで、結局のところ、これを参考にSpamAssassinnをまず試してみることにした。

ActivePerlがインストールされていることが前提。 WebサーバからPPMファイルをインストールする必要があるので、インストール時にはインターネットに接続されている必要がある。 全文検索システム Namazu for Windowsから、nmz2.0.20.001-win32.zipをダウンロード。 展開したら、基本的にはreadme.txtどおりにインストール。 環境変数HOMEをc:\namazuにするように書いてあるのだが、HOMEはc:\homeにしてあるので、とりあえずC:\homeのままにしておく。 NamazuのHOMEを設定する必然性は無いような気がするのだが、mknmz.batなどでNAMAZURCが定義されていない場合、~namazu\.namazurcなどを読むようにしているからだろうか。 拡張タイプは必要無い気もするのだが一応ext-inst.batも実行する。 namazu\etc\namazuの下に-sample.win32を参考にnamazurc、mknmzrcを作っておく。 mknmzrcの変更点(コメントアウト含む)

$HTML_SUFFIX = "html?|[ps]html|html\\.[a-z]{2}";
$ALLOW_FILE =	".*\\.(?:$HTML_SUFFIX)|.*\\.txt" . # HTML, plain text
...
$DENY_FILE = ".*\\.(gif|png|jpg|jpeg)|.*\\.tar\\.gz|core|.*\\.bak|.*~|\\..*|\x23.*";
$NON_SEPARATION_ELEMENTS = 'A|TT|CODE|SAMP|KBD|VAR|B|STRONG|I|EM|CITE|FONT|U|'.
                        'STRIKE|BIG|SMALL|DFN|ABBR|ACRONYM|Q|SUB|SUP|SPAN|BDO';
$HTML_ATTRIBUTES = 'ALT|SUMMARY|TITLE';
$ON_MEMORY_MAX   = 150000000;
$FILE_SIZE_MAX   = 120000000;
$TEXT_SIZE_MAX   =  6000000;
$WORD_LENG_MAX   = 128;

%Weight =
    (
     'html' => {
...
);

$INVALID_LENG = 128;
$MAX_FIELD_LENGTH = 200;
$NKF = "module_nkf";
$KAKASI = "module_kakasi -ieuc -oeuc -w";
$WAKATI  = $KAKASI;
$LIBDIR = 'C:/namazu/share/namazu/pl';
$FILTERDIR = 'C:/namazu/share/namazu/filter';
$TEMPLATEDIR = 'C:/namazu/share/namazu/template';

この時点でmknmz -Cで確認。 namazurcの変更点(コメントアウト含む)。 実際にはコマンドラインでnamazuを使うことはほぼ無いだろうから、必要ないかもしれない。

Index         C:\namazu\var\namazu\index
Template      C:\namazu\var\namazu\index
Lang          ja_JP.SJIS

"C:\namazu\pltests> perl alltests.pl"によるテストが完了したら、とりあえずIndex作成と検索のテスト。 テストなので対象ディレクトリはあまり大きくない方がよいだろう。 mknmz -O c:\namazu\var\namazu\index c:\home\tmp

XPDF 3.02pl4

PDFの検索を行うために、XPDF(pdftotext)をインストールする。 Xpdfから、xpdf-3.02pl4-win32.zip(Xpdf 3.02pl4)、xpdf-japanese.tar.gz(Japanese Language Support Packages)をダウンロードする。 xpdfのexeファイルをすべて\usr\binに、sample-xpdfrcをxpdfrcにリネームして\usr\binにコピーする。 次に、Japanese Language Support Packagesを展開したxpdf-japaneseを\usr\libにコピーして、中のadd-to-xpdfrcをパスをWindows形式に書き換えて\usr\bin\xpdfrcにコピーする。 search-s for Namazu Excelの古いバージョンなどを読もうとしたときに、「このマクロは無効化できません」という、エラーメッセージが出て、Indexの作成がいったん止ってしまう。無人でインデックスを作成しようとしたときには、これはけっこう問題だ。xdoc2txtで解決できるかもしれない。 最後に、巨大なディレクトリにたいして一気にインデックスを作ると、エラーになる確率が非常に高い。 そこで、 allmknmz.bat という、ディレクトリを分割してインデックスを作るバッチファイルを作成する。

search-s for Namazu 0.9.2

せっかくのWindowsなのでGUIで検索するためにsearch-s for Namazu 0.9.2もインストール。 search-s for Namazuより、srchs092.exeをダウンロードしてインストールした後に、srchs093beta-0421.lzhをダウンロードして、C:\Program Files\search-s\searchs.exeを上書き。 c:\namazuにインストールしていれば、とりあえずは設定不要。 インデックスは、ディスクのフラグメントにかなりの悪影響を与えるので、namazurcとmknmzの実行バッチファイルを変更して普段使わないディスクに作成するようにする。

やはり、所有する文書の全文検索は欲しい。 対象文書は、最低限テキスト、Word、Excel、PDF。Thunderbirdのメールデータも検索できればうれしいが、Thunderbird自体の検索機能を使えばよいので、必須ではない。 フリーソフトなどでもいくつかあるが、メインテナンスの安心感から最終候補として上がったのは以下の3つ。これらは、いずれもプラグインで検索対象を追加できる。

Windows デスクトップ サーチ(WDS)

長所

• OS開発元のものなので、若干の安心感。
• アイドルタイムにインデックス作成を行う。
• IFilterで様々なファイル形式に対応できる(Windows Searchで様々なファイルを検索する - memo.xight.org、IFilter dot org)。
• XMPメタデータを使った検索もできる(SeaGate Blog: WindowsデスクトップサーチでXMPメタデータの検索)。
• インクリメンタルサーチが可能。

短所

• Adobe PDF IFilter 6.0では、PDF検索がうまくいかないらしい(Acrobat 8付属のIFilter 8を使うとうまく行くかも?)。
• Foxit PDF IFilterを使えばうまくいくようだ(Windows Vista 64bit 版 での PDF 全文検索)。

Googleデスクトップ(GDS)

長所

• GoogleのWeb検索との統合。
• Thunderbirdのメールデータも検索できる。
• 様々なファイル形式に対応したプラグインが開発されている。
• Google Desktop Gadgets

短所

• 大きなファイルは、先頭の英単語レベルで75,000文字まで、日本語レべルで4000語程度しかインデックスされない(ファイル : アイテムを検索できない - Windows 用デスクトップ ヘルプ)。
• 標準のPDF検索では、透明テキストやスキャンされた画像が含まれているPDFは検索できない(GoogleXdocや、Xpdfテキスト付属のPDFtoTextを使えば可能)。

Namazu

長所

• オープンソース故の、開発の継続性および発展性。
• search-s for Namazuを使えば、GUIでも使える。

短所

• インデックス作成のタイミングは、自分で指定する必要がある。

結論

とりあえず、GDSは完全な全文検索ではないので、選択から外れる。 機能的な面から考えれば、CPUの空き時間に常に最新のインデックスを作ってくれるWDS の方が、安易に使用することはできる。特に、OSと密接に開発されているWDSなら、新規ファイルが作成されたことをトリガにして、インデックス作成を指示するくらいのことはしているのかもしれない。 反面Namazuでは、インデックスの作成は、明示的に指示する必要がある。 が、現実問題として、ある程度定期的(週に1回程度)インデックスの作成を行っておけば、検索のお世話になることは無いのではないだろうか。どこに保存したかを忘れてしまった場合は別として... さらに言えば、意図しない時にインデックスの作成が行われてしまい、コンピュータの負荷が上がってしまうという状況を避けることもできる。 検索の対象となるファイルの種類については、WDSの方が、Jpegなどのメタタグまで対応しており、広範囲と言えるだろう。だが、現状テキスト、HTML、Word、Excel、PDFが検索できればそれで十分だろう。 WDSであれば、WDS APIに対応した他のアプリケーションからの利用も可能というのは、メリットではあるが、現状はまずニーズはなさそうだ。 いずれWindows 7、Oddice 2007あたりに移行すれば、WDSを使いそうな気がするが、とりあえずは、Namazuを使ってみよう。 実際に、Namazuをインストールしてみた。 大量のファイルを一気に追加したときには、さすがにある程度時間はかかるが、 検索対象が300G程度の僕の環境では、日々普通に増えていくファイルのインデックスを追加するくらいであれば、数分以内に完了するのでそれほど気にならない。 その他にちょっと気になったツール。 DesktopHE -Hyper Estraierを使用したWindows用デスクトップ検索ツール- やはりインデックスを作成して、それから検索するツール。Javaで動作する。 Everything Search Engine ファイル名を高速に検索するツール。

GetHTMLWをインストールして使いはじめたが、やはり若干不安定なところがあり、特に特定のページでよく落ちることがある。 しかし、GetHTMLWは使い続けたい。 そこで、Proxyを簡単に切り替えることができるアドオンを使うことにした。 アドオンの検索 :: Add-ons for Firefoxで、Proxyを検索。 いくつかあったが、簡単にレビューなどを読んで選択。 ツールバーのメニュー項目を増やさず、しかもURLパターンでProxyを切り替えることができるということでFoxyProxyを使ってみることにした。 FoxyProxy Standard :: Add-ons for Firefoxから、「Firefoxへ追加」で、追加。 既定値はGetHTMLWの生成するPacファイルを読み込むことにしておく。 そして、頻繁にエラーが発生するURLを直接接続として設定する。URLは、ワイルドカードや正規表現を使うことができるので、かなり細かい指定が可能。 普段は「定義済みのパターンと優先度を基にプロキシを利用する」で使用する。 もしエラーが発生した場合には、アイコンを右クリックして「FoxyProxyを完全に無効化する」を選ぶとProxyを使わないようにできる。 実際の用途としては複数のProxyを選択するわけではなく、特定のURLでProxyを使わずに直接接続するだけだが、非常に使いやすく有用なアドオン。 若干動作が重くなるようだが、今のところはそれほど気にはならない。

ずっと以前に使っていた、Webページ保存ツールGetHTMLWをまた使いはじめることにした。 個別のページを保存しておきたいときのためには、その為のソフトをWgetを利用したその為のソフトを作ったが、すべてを保存しておくわけにはいかない。 このGetHTMLWは、Proxyとして動作し、訪れたページをすべて保存しておくことができるツール。 使用をやめた理由は、「訪れたページをすべて保存しておいたら、ディスクがいくらあっても足りない」、「速度的なボトルネックが発生する」そして「たまに落ちることがあり、そのときにはProxyを見失ったブラウザでは閲覧できなくなってしまう」という3点だったと思う。 が、「現在、ディスク容量はそれほど気にする必要はない」、「速度のボトルネックはCPUやディスクのスピードアップにより無視できそう」そして「落ちたら再度立ち上げればよい」という考えにより、保存を重視して再度使いはじめることにした。 もちろん、これで保存できないページも存在するが、それは「ディスク容量の節約にもなる」と、自分を納得させることにした。 GetHTMLWの詳細情報より、gethtmlw-8.1.1.exeをダウンロードしてインストール。 [設定]-[環境設定]で以前のデータフォルダを指定する。