ブロックリスト/ブロックファイル は、今回 Proxomitron に追加された機能の中でも、非常に強力なものの一つです。実際のところ、「ブロックリスト」という呼び名はあまり適切ではありません。これを使えば、ブロック以上のことをすることができるからです。事実、これはまさに通常の検索表現の拡張になります。
多くの場合、これはフィルタの URL マッチ で使用されると思いますが、URL に限定されているわけではありません。リストにはあらゆるマッチングコマンドを含むことができますし、さらには他のリストを呼び出すこともできるのです！
つまるところブロックリストはただのテキストファイルで、検索するアイテムのリストが記述されています。リストのそれぞれの行は、マッチするまで１行ずつ検索され、マッチしなかった場合には false を返します。全てのブロックリストファイルは（設定ダイアログにおいて）名前を持ち、「$LST(listname)」の書式を用いることで、検索表現のどこででも使用することができます。
リストは最高 255 個まで持つことできます。お好きな用途にご使用ください。一般的な用途は、それぞれに URL のリストを記述しておいて、アクセスを殺したり、クッキーを受け入れたり、JavaScript を無効にしたり有効にしたりするために使用することでしょう。新しいファイルを作成する手順は、以下の通りです。
- まず、適当なテキストエディタ（メモ帳など）を使用してリストを作成します。それを somename.txt のように、ただのテキストファイルとして保存してください。
- 次に、Proxomitron の設定ダイアログの Blockfile タブでリストを追加します。「ADD」ボタンを押してファイルを選び、それに名前を付けます。Proxomitron 内で使用する名前は、ファイル名とは別のものをつけることができます。このおかげで、フィルタ自体を変更することなくブロックリストを入れ替えることができるようになっています。
- 最後に、フィルタ内のブロックリストのアイテムをチェックしたい場所で、$LST(BlockfileName) の書式を用いて使用してください。これは、その場所にリストを挿入するようなものだと考えてください。
たとえば、以下のような検索表現があったとします...
(Keitarou|Naru|Suu|Mitsune|Motoko|Shinobu|Mutsumi|Kame)
このためには、以下のようなリストを作成することができます...
# # Sample List LoveHina.txt # Keitarou Naru Suu Mitsune Motoko Shinobu Mutsumi Kame
それから、このリストに「LoveHina」といったように名前を付け、前の「(...|...|...)」形式の表現があった場所に「$LST(LoveHina)」を置くことで使用できます。もうおわかりのように、これは大量のアイテムを扱う場合に非常に便利です。リストのメンテナンスが楽になるだけではなく、同じリストを複数のフィルタで使い回すこともできるのです！
例外指定
また「~」を行の最初に置くことで、「例外」にするための行を作成することができます。これはリストがマッチするものを制限することができ、先にリストの通常の表現がマッチした場合にだけチェックされます。リストは「例外」の行がマッチしなかった場合にだけ true を返します。たとえば、以下のようなリストがあったとします。
# # Another sample list # an example of using `~` to exclude # *.gif ~*/gamera.gif
最初の行は「.gif」で終わる全てのものにマッチします。しかし、２行目でそれが「/gamera.gif」にもマッチしないかどうか調べています。これは、リストが絶対にガメラを捕まえないようにするものです（ウミガメ脱出装置のようなものだと考えてください）。（訳註：ウミガメ脱出装置）
さらに混乱は続く...
リストは置換テキストで呼ぶこともできます。ここではマッチするために使用されることはありませんが、そのかわりに、変数をある値にセットするために使用することができます。たとえば、$CON(#,#) コマンドと $SET(#=...) コマンドを使用することで、置換テキストの変数を、その接続番号で逐次セットしていくことができます（たとえば、複数の UserAgent、あるいはブラウザのバージョンをセットすることができます）。
# # A sample value rotation list (named "MyList") # $CON(1,3)$SET(0=Value One) $CON(2,3)$SET(0=Value Two) $CON(3,3)$SET(0=Value Three)
上の例では、このリストが呼ばれるたびに３つの値を順番に \0 に入れていきます。これを置換部で使用することができます。以下のように...
$LST(MyList) \0
まずリストを呼び出して \0 をセットし、それから置換テキストに置かれた \0 で、その内容を出力しています。
分解するのは簡単です
通常、それぞれの行は独立した検索表現として扱われます。しかし、長い表現は続きの行をインデント（字下げ）することで複数行に分けることができます。たとえば...
taste (this|that|these|those|the other thing)
という表現は、以下のように書くこともできます...
taste ( this| that| these| those| the other thing)
効果は全く同じですが、長い行は複数行に分けた方が見やすいかもしれません。それぞれの行の最初や最後にあるスペースは無視されます。（訳註：もちろん、半角のスペースだけです）
コメントに関するコメント
また、例で示したのでおわかりかと思いますが、リストには「#」で始めることでコメントを入れることができます。通常、コメントは無視されますが、リストの最初の数行は、リストの動作を決めるための「キーワード」を探すために調べられます。現在のところ、６つのキーワードが実装されています。「NoAddURL」「junkbuster」「NoHash」「NoUrlHash」「NoPreHash」それに「Logfile」です。
「NOADDURL」はリストを「Add to blockfile」メニューから隠します。これは URL マッチに使用しないリストで、メニューがごちゃごちゃになってしまうのを防ぐために使います。
「JunkBuster」が見つかった場合、Proxomitron はリストを JunkBuster スタイルのブロックリストとして読み、解釈しようとします。これは完璧ではありませんが、ほとんどの JunkBuster リストに対して有効に働いているようです。
方法論の違いのせいで、URL を見つけるたびに順次追加してしていく方が、リストを作成する作業としては効率的かもしれないということに注意してください。特に、JunkBuster はホストネームを逆から処理していきます（ルートが最初に、ということです）。Proxomitron は URL を他のランダムテキストと同様に扱いますので、最初にワイルドカードを持ってこない方がいいでしょう。たとえば、「(www.|)somehost.com」の方が「*somehost.com」よりは少しだけ速くなるでしょう。もし最初にワイルドカードを持ってくる必要があるときは、「[^/]++somehost.com」を試してみてください。これは最初の「/」が現れるところまでしかスキャンしませんので、「*」よりは少しだけいいでしょう。
「NoHash」「NoUrlHash」「NoPreHash」は、リストで使われている様々なハッシュのアルゴリズムを無効にするために使用されます。NoHash は全てのハッシュを無効にします。滅多に呼ばれないか、スピードが問題にならないようなリストで使用することで、メモリを節約します。「NoUrlHash」と「NoPreHash」はそれぞれのハッシュのタイプを無効にします（以下のハッシュに関する項をご覧ください）。たぶん、これらはあまり使うべきではないでしょう（仮に使うことがあるにしてもです）。
「Logfile」は特別なコマンドで、Proxomitron に対して、通常のブロックリストのようにファイルの内容を読み込んだり処理したりしないように指示するものです。その代わり、このコマンドは $ADDLST() コマンドを使って、ブロックリストでログを取る場合に便利です。
通常 Proxomitron は、ブロックファイルの内容をメモリに読み込んで、検索表現として処理します。しかしログファイルの場合には、メモリの無駄遣いになるだけでなく、そのファイルが検索表現ではないために、パース時のエラーの原因にもなります。
ログファイルを使うためには、まずファイルを作成し、以下のように「LOGFILE」を最初の数行の中に記述してください...
##
## Proxomitron log file (LOGFILE)
##
それから、他と同様にそのファイルをブロックリストとして追加します。メッセージをログに書き出すには、$ADDLST(Logname, text to add) コマンドを使用してください。
ログを見るためには、Proxomitron の "Edit blockfile" オプションを使ってください。こうすると、その時点で書き込まれていないデータをフラッシュしてファイルに書き込み、ファイルを閉じ、それからそのファイルの拡張子（.txt や .log など）に関連づけられているエディタで開きます。新しいデータを素早く追加するため、他のブロックリストとは違って、ログファイルの場合には Proxomitron は書き込みの合間にもファイルを開き続けています。
ブロックリストのインデックス化（ハッシュ）
OR を多用するのに比べた、リストのもう一つの利点はスピードです。Proxomitron は、適当なブロックリストの項目に対しては、インデックス化されたハッシュを利用することができるようになりました。全てのものをインデックス化できるわけではありませんが、インデックス化できる項目に対しては、巨大なリストでの検索がかなり速くなります。通常は、あなたはこれがどのように働くのか考える必要はありません。しかし、もしあなたがご自分のリストを可能な限り速くしたいと考えるならば、ここにちょっとしたコツがあります。
まず、Proxomitron はリストのそれぞれの項目が「ハッシュできる（インデックス化できる）」かどうか調べます。もしできるならば、その項目はハッシュ可能リストに加えられます。もしできないならば、それはハッシュ不可能のリストに加えられ、リストが呼ばれるたびにスキャンされることになります。もちろん、ハッシュできる方がいいわけです。
Proxomitron が扱うことのできるインデックスには２種類あります。固定プレフィクスと、URLスタイルのインデックスです。リストのそれぞれの項目はどちらの方法でインデックス化できるか調べられ、もし両方が使える場合には、より多くの文字がインデックス化される方を採用します。リスト全体では、両方のタイプが混在することになるでしょう。
「固定プレフィクス」は一番簡単です。これはワイルドカードを含まないで特定の長さの文字列を持った、全ての表現です。ワイルドカードより前の表現が長ければ長いほど、よりインデックス化できるでしょう。ユーザーが加えたURLは、殆どがこのカテゴリに分類されるでしょうし、URLベースではない多くのリストにも使われるでしょう。この方式に適切なサンプルをあげておきます...
www.somewhere.com 127.0.0. shonen(knife|) foo(bar|bat)*bear
「this*&*that」のような AND も使えます。ただし、「this|that」のような括弧の外にある OR はインデックス化されません。マッチが２つの別々の値として始められるからです。この場合では、それぞれを別々の行に記述した方がいいでしょう。
URL スタイルのハッシュ は名前が示すとおり、URL のリストに使えるようにデザインされました。これは最初にワイルドカードがきても使えるようになっています。というのも、ホストネームの一部分にマッチさせるためには、それが必要になることが多いからです。これはホストネームの最後を調べ、そこから遡ってインデックス化することで働きます（ホストネームの最後は「:」または「/」で区分けされます）。これが働くためには、ホストネームの最後と、最初にあるワイルドカードの間に他のワイルドカードがないということが条件になります。適切なワイルドカードには、「*」 「\w」 「[...]+」 「[...]++」 それに 「(...|)」 が含まれます。これらは、URL の最初に置いて役に立ちそうなものの殆どを含んでいるはずです。もう一度、実例です...
*somehost.com/(anything|after|here|is|fine)/\w.html \wsomehost.com/ [^.]+.somehost.com/ [^/]++somehost.com/ (www.|)somehost.com:[0-9]+/ ([^/]++.|)somehost.com/
残念ながら、以下のようなものはインデックス化されません...
([^/]++.|)somehost.*/ ([^/]++.|)somehost.(com|net)/
このようなケースでは、以下のように２つの項目に分けた方が速くなるでしょう...
([^/]++.|)somehost.com/ ([^/]++.|)somehost.net/
ブロックリストを作成している方には注意して欲しい変更があります。もし最初にワイルドカードを使用した場合は、ホストネームが「/」までを含む、ということが非常に重要になります。以前までは、これは必要ではありませんでした。たとえば、以前まではこのような項目は...
([^/]++.|)microsoft.
以下のように書いたのと同様、問題ありませんでした...
([^/]++.|)microsoft.com/
もし必要ならば、複数のエントリに分けて記述することになるかもしれません。これはまた、表現を以下のように書く必要もない、ということを意味しています。
www.(ad(server|engine|banner)|banner(site|click|)).(com|net)
その代わりに、実際のホストネームを羅列した方が速くなるでしょう ── メンテナンスが楽になることは言うまでもありませんね。
内部では...
ブロックリストに関して、「内部」でどうなっているか ―― たとえばどのようにハッシュされているか、それぞれのアイテムが何回チェックされたか、そしてそれぞれのアイテムが何回マッチしたか ―― を見るために、情報表示用の特別な URL を用意しました...
ここで、ロードされているすべてのリスト、そのファイル名、含まれているアイテム数、プレフィクスまたは URL ハッシュされたアイテムの数を見ることができます。リスト名をクリックすると、記載されたそれぞれの項目についての明細を見ることができます。リストをもっとも効率的にしようとすれば、これはとても役に立つでしょう。
制限について...
ブロックリストにはいくつか制限があり、そのせいで OR で分けられたアイテムのリストの場合と動作が多少異なります。主な点は、これが独自の有効範囲で動作しているという点にあります。たとえば、以下のようなマッチがあったとします...
www.$LST(hosts).comそしてリストが以下のようなものであったとすると...
# # Host list # adsite adsite-2これに "www.adsite-2.com" というホストが与えられるとマッチするように思えますが、実際はマッチしません。リストはまず "adsite" を見つけますが、独自の有効範囲があるので、マッチにはさらに ".com" が必要だというところまで見通せないためです。これを防ぐためには、マッチからあいまいさを排除することが重要です。たとえば、後ろの "." をリストに移動させると以下のようになります...
www.$LST(hosts)com
# # Host list # adsite. adsite-2.
同様に、リストアイテムの最後に "*" があると、可能な文字の最後までマッチしてしまうので注意してください。通常はこのようなことを望まないと思いますので、"*" は呼び出すマッチの方に置いてください...
www.$LST(hosts)*.com
終わりに...
これで、ブロックリストについて知っておくべきことは全部です。もしあなたがこれをマスターしたならば、私は公式に P.C.B.F.E.
Return to main index