Adblock から Polipo へのフィルタ変換に正規表現だけでは足りない理由

変換ツールは、ルールの文字を置き換えるだけでなく、その意味を保たなければなりません。ブラウザのフィルタリストは、ページがどのリソースを読み込むか、リソースの種類、例外ルールに依存することがあります。URL だけに基づくブロックリストが持つ情報はより少なくなります。

既存の Polipo 環境では、マニュアルが forbiddenFile のエントリをドメイン名または POSIX 拡張正規表現として定義しています。したがって Python のエンジン向けに作られた regex が、そのファイルで自動的に有効とは限りません。

宣言した部分集合から始める

• 無条件の URL ブロックパターンは、アンカーと区切り文字の挙動を定義したうえで初めて変換します。
• @@ で始まる例外ルールは保持します。そのパターンを拒否ファイルに追記すると意味が反転します。
• script やドメインの制限といった文脈オプションを持つルールは、変換先がその条件を表現できない限り、URL だけの変換から外します。
• 要素を隠すルールは除外します。ページの DOM 要素を選ぶには別の仕組みが必要です。

未対応のオプションを削除すると、条件付きのルールが無条件のブロックに広がる可能性があります。完全な変換を黙って主張するのではなく、飛ばしたルールを報告してください。

歴史的な adblockparser パッケージは、Adblock Plus のルールの一部を解析して評価できます。その README は、無視される要素非表示ルール、オプションに依存する照合、その他の制限を記録しています。リポジトリは 2026 年 6 月 24 日にアーカイブされました。その出力は、変換先エンジンと照合して評価する材料として扱い、リスト全体の忠実な変換を約束するものとは考えないでください。

プロキシから見える範囲を考慮する

通常の HTTPS トンネル では、Polipo のトンネルフィルタはホスト名とポートを見るだけで、暗号化された URL パスは見えません。forbiddenTunnelsFile は別個のポリシー面です。完璧に翻訳したパス表現でも、プロキシが決して見ない内容には一致できません。

保持した部分集合を文書化し、変換を評価するときは意図したブロックと意図した例外の両方を確認してください。ファイルが読み込まれたことは構文の受理を示すだけで、等価なフィルタリングを示すものではありません。