Frequently Asked Questions / よくある（と思われる）質問と、その回答

基本的なことが分からない † Edit

Proxomitronで何が出来るのかは、「Proxomitronとは」を見てください。

※以下の知識が無いとProxomitronを使用するのは難しいかも知れません

  1. Windowsの基本的な操作方法
  2. ネットワークの知識少し（ブラウザ、サーバ、プロキシなどがどんな働きをしているのかというボンヤリした知識や、HTTPヘッダなど）
  3. HTMLの基本知識（場合によってJavascriptなどの知識も必要）
  4. Googleなどで検索する方法

全然わからない場合は、何も見なかったことにしてブラウザを閉じてください。無理して使う物ではないと思います。

問題なさそうな場合、先ずは「各バージョンの違い」を見て、好きなバージョンのProxomitronを導入してください（4.5June+7 推奨）。
後は、フィルタ、リスト公開 や 関連リンク などから好みのフィルタを入手して好きなように使用してください。
気が向いたら、日本語訳ヘルプ や マッチングルール、コマンド一覧、リストについて などを見て、新しいフィルタの作成や改造を試みてください。簡単でしょう？
TIPS や FAQ、RAQ、質問箱、2chのスレッド も役に立つと思います。
ナイスなフィルタが出来たら是非投稿してみてください。

↑

フィルタの追加方法がわからない / エラーが出てフィルタを追加出来ない † Edit

→ フィルタの追加方法

↑

Proxomitron自体に接続できない † Edit

http://slashdot.jp/article.pl?sid=09/03/11/0924257
WindowsDefenderがhostsファイルの「127.0.0.1 localhost」を削除してしまうらしい。
削除されている場合、hostsファイルに「127.0.0.1 localhost」と書いた行を追加するか、
localhostとして設定していた箇所を全て127.0.0.1に設定し直せば多分OK
最新のWindowsDefenderならOKらしい

↑

Proxyを一括で追加する方法がわからない † Edit

メインウインドウ → プロキシボタンを押す → 追加ボタンを押す → Proxyリストを貼り付ける → OKボタンを押す。
または、*.cfg ファイルを直接編集してください。

↑

外部プロキシを使いたい † Edit

CyberSyndrome, ProxyForest などを参照してください。

↑

日本語化したい † Edit

Proxomitron-J にある、日本語化パッチを使用してください。
※4.5June338、4.5June+6、4.5June+7 は最初から日本語化されています

↑

SSL(https://〜) でも使用したい † Edit

ssleay32.dll
libeay32.dll
の2つのファイルが必要になります。

Proxomitron-J で入手可能です。

URLマッチでドメインを記述する際には、「secure.example.com:443/」のように、ポート番号も書かなければならない事があります。

↑

FTPにアクセス出来なくなる † Edit

Proxomitronは、http://、https:// 以外には対応していません。
その為、FTP通信等HTTP通信以外のProxyに設定すると、こういう事が起こります。
設定を見直してください。

ちなみに、Proxomitronはプロトコル部分（スキーム部分）が ftp:// であろうが a: であろうが、Proxomitronを通った以上、全てhttp:// にアクセスします。（https:の場合のみhttps）

また、タブブラウザ等の一発Proxy切り替えでProxomitronを使用している場合、 全ての接続を同じProxyに変更してしまい、こういう事になっている可能性も無くは無いかも知れません。

↑

Proxomitronの表示サイズが壊れてしまった † Edit

画面から上、左にはみ出すと（x座標、y座標がマイナスになると）こういう事が起こるようです。
使用している設定ファイル(*.cfg)を開いて、[WinSizes] から空行までを削除して上書き保存し、再度読み込みか、再起動させると直ります。

↑

file//、load//が使えない † Edit

  1. Prefix（URLコマンドの前に必要な接頭語）に「.」を入れる。

    但し、もし \x をJavaScriptの変数名に使用しているフィルタがあった場合、そのスクリプトは正常に動作しなくなるので、
    JavaScriptの変数などにユニークな文字列を使用する場合は、グローバル変数（$SET(変数=値)）を使用した方が良いです。
  2. IE, Opera の場合、URLの「file//C%7C」「file//C|」などの、ドライブレターの後の「%7C」「|」を「:」に変えると動作します。
    リダイレクトするリストに「[^/]++file//([a-z])\0(%7C|\|) \1 & $JUMP(http://\xfile//\0:\1)」を追加するか、以下のフィルタを導入してください。 
    [HTTP headers]
In = TRUE
Out = TRUE
Key = "URL: file//C| -> file//C:"
URL = "[^/]++file//([a-z])\0(%7C|\|) \1 & $JUMP(http://\xfile//\0:\1)"
↑

Proxomitronがエラーを出す † Edit

Read Over=-1
ByteLimit（バイト制限(Limit)）が8192のフィルタが、一回の検索で7168Byte以上消費すると、Read Over=-1というエラーを発生させるので、Limitを8192以外にするか、4.4以外のバージョンを使ってください。（4.4以外のバージョンでは発生しません）（検証用ファイル：file7167.htm file7168.htm）
Application Error
Content-Type: ヘッダ(in)そのものが無い通信で$FILTER(true)を使うと、 
ProxomiTron Application Error
Exception [C0000005] raised in...
ConnectRemote::(HF)
なるエラーが発生します。
何でも良いので適当な Content-Type: ヘッダ(in)を出力するか、4.5May以外のバージョンを使ってください。（4.5May以外のバージョンでは発生しません）
↑

動作が遅い/重い † Edit

以下の原因が考えられます。

↑

設定に問題がある † Edit

Internet Explorer (IE) / IEコンポーネントブラウザを使用する場合、「インターネットオプション → 詳細設定 → HTTP1.1設定 → プロキシ接続でHTTP1.1を使用する」にチェックを入れると速くなります。

↑

ログウインドウを開いている † Edit

ログウインドウを開いている場合、閉じるか、一時停止するか、フォアグラウンドからバックグラウンドに変更する（ブラウザなどの他のウインドウを最前面にするか、ログウインドウを最小化する）と速くなります。

↑

RWINが32768に固定されている（バグ） † Edit

※WindowsXP SP2/SP3を使用している場合限定のバグ（仕様？）です。

ツールやレジストリでMTU，RWINの値を変えても、オミトロンを通すとRWINが32768に固定され、高速回線の場合遅くなるようです。（MTU，RWINの確認(要script)）　※オミトロンをバイパス状態にしてもオミトロンを通している限り同じ

解決方法
バージョンによって解決方法が違います。

4.5June
バイナリエディタで、アドレス 0000D581 の 04 を 00 にする
4.5May
バイナリエディタで、アドレス 0000D521 の 04 を 00 にする
4.4
バイナリエディタで、アドレス 0000C101 の 04 を 00 にする

Windowsで使用出来るバイナリエディタには、BZ、Stirlingなどがあります。（メモ帳はバイナリエディタではありません）

※4.5June+7 や、4.5June+6、4.5June338 などは既に修正されています

↑

おかしなフィルタや、ややこしいフィルタが暴走している † Edit

フィルタが暴走＝フィルタが永遠にマッチしている

暴走すると、

  1. CPUがずっと高負荷になる
  2. 終了してもプロセスが残る（4.4限定）

Abort（中止）ボタンを押すか、タスクマネージャーなどからProxomitronのプロセスを殺せば停止する。（4.4ではAbortが効かない為、プロセスを殺すことになる）


ひとつひとつフィルタを無効にしていって、どのフィルタが悪さをしているのか絞り込んでみてください。
※暴走しているフィルタは、ログウインドウを見れば直ぐに判る筈です

悪さをしている（暴走している）フィルタを見つけたら、そのフィルタを修正してください。
修正出来ない場合は、第三者に修正を依頼するか、諦めてそのフィルタの使用を止めてください。

↑

修正のポイント † Edit

空にマッチするウェブページフィルタ
空にもマッチするフィルタは、空にはマッチしないようにするか、\kや、$STOP()を使い、暴走しないように変更してください。
複数回数マッチした場合のみ、\kや、$STOP()を使用したい場合は、4.5以降のグローバル変数（$SET(変数=値)）と$TST()の組み合わせが使えます。

暴走例　※testでは再現しない 
[Patterns]
Name = "infinite loop TEST 1"
Limit = 256
Match = "*"
Replace = "-"
4.3有限　4.3はLimitまでの消費を繰り返しておしまい（4.3は対象を消費しない場合マッチしない）
4.4無限　Limitまでの消費を繰り返した後、空にマッチを繰り返し無限ループ
Abortが効かない上、終了してもプロセスが残る　残ったプロセスは高負荷のまま　プロセスを殺す必要がある
4.5m、4.5j、4.5j338無限　Limitまでの消費を繰り返した後、空にマッチを繰り返し無限ループ
$JUMP()を使用しているHTTPヘッダフィルタ
サイトAにジャンプ → サイトAにジャンプ → サイトAにジャンプ → （エンドレス）
となり、暴走することがあります。　サイトAにジャンプさせる場合、URLがサイトAならジャンプさせないといった表現を追加して、暴走しないようにしてください。

暴走例　※testでは再現しない 
[HTTP headers]
Key = "URL: infinite loop TEST 2"
Match = "http(s|)://"
Replace = "$JUMP(\u)"
Multiにチェックが入っているウェブページフィルタ
ウェブページフィルタの、「複数のルールのマッチを許可する（Allow for multiple matches）」にチェックを入れると、 出力した物（置換するテキスト(Replace)）が、自身を含む全ウェブページフィルタの検索対象になる。
その置換され、出力された物にまた何かのフィルターがマッチし、
更に出力した物がまた何かのフィルターにマッチし、
更に出力した物がまた何かのフィルターにマッチし、　…　以下無限ループ　となる事があります。

必要ない場合は「複数のルールのマッチを許可する（Allow for multiple matches）」のチェックを外してください。

暴走例　※testでは再現しない 
[Patterns]
Name = "infinite loop TEST 3"
Multi = TRUE
Limit = 256
Match = "<html*>"
Replace = " <html>"
↑

使用しているフィルタのどれかが無駄な処理をしている † Edit

ひとつひとつフィルタを無効にしていって、どのフィルタが悪さをしているのか絞り込んでみてください。

悪さをしている（無駄な処理をしている）フィルタを見つけたら、そのフィルタを修正してください。
修正出来ない場合は、第三者に修正を依頼するか、諦めてそのフィルタの使用を止めてください。

↑

修正のポイント † Edit

<end>を使用しているフィルタの場合
<end>は、接続が切断された時に処理されるようなので、何時まで経っても接続が切断されない場合、何時までも<end>が処理されない事になります。
最悪の場合、ユーザーキャンセルしてしまったり、タイムアウトしてしまい、<end>を使用しているフィルタが処理されない事もあります。

対策としては、<end>ではなく、</body>や、</html>にするなどが考えられます。
しかし、HTML以外では使用出来ず、HTMLでも見つからない可能性があります。　諦めるのが一番かも知れません。
バイト制限(Limit)が大きすぎる
小さくしてみてください。　小さくするとマッチしないという場合は、諦めてください。
$URL()などを変な所で使用している
マッチさせる語句(Match)や、範囲のマッチ(Bounds)の頭で使用すると、一文字検索する度に$URL()などが処理されることになり、大変遅くなります。 
例
[Patterns]
Name = "TEST 1/2"
Active = FALSE
Limit = 256
Match = "$URL(http://\w)a"
Replace = "-"

Name = "TEST 2/2"
Active = FALSE
Limit = 256
Match = "a$URL(http://\w)"
Replace = "-"

テストに使用するテキストは、「ab」を300個並べたもの。
結果
TEST 1/2  平均時間 : 0.300000 (ミリ秒)
TEST 2/2  平均時間 : 0.150000 (ミリ秒)

「TEST 2/2」の方が、無駄な処理をしていない分だけ速くなる
特定のサイト限定のフィルタも動作してしまっている
URLのマッチ(URL)で絞り込んだ方が速くなります。
一度処理したらもう必要ないフィルタが処理を続けている
$STOP()か、\kを使用すると速くなります。
場合によっては<start>、<end>も使えます。
↑

高速化したい † Edit

先ず、速度が遅い/重いを参照してください。

※この項目の 〜% というのは、あくまで参考値です。　検索対象によって変わる可能性があります。　また、大幅に速くなるように見えても、実際の速度的には誤差の範囲内という可能性もあります。

※速度に拘りすぎない方がいいと思います
元々Proxomitronは速いソフトなので、あまり拘らないことを勧めます。
また、下手な拘りは誤爆を生みますし、
下手に速度を追求すると、フィルタが見辛くなる事もあると思われます。
機能に拘りすぎない
例えば、Unicodeのページでもマッチさせようとしたり、EUC-JPの場合もShift_JISの場合も…と拘ると遅い物になります。
また、下手な拘りは誤爆を生みます。
厳密なマッチに拘りすぎない
例えば、「$NEST(<td,\s[^>]++width=$AV(640)*,</td>)」は、「<td a style="padding:4px" awidth="640" width="200"></td>」等という物にもマッチしてしまうので、
正確にマッチさせるには「$NEST(<td,\s([^>]++\s|)width=$AV(640)*,</td>)」のようにする必要があります。
しかし、後者の方が 70〜100% 程低速になります。　どっちにしろ誤差の範囲内の筈ですが、例のように誤爆の可能性が低いのであれば、考慮しない方が速くなります。
※後者でも「<td a hoge=">" width="640"></td>」のようにされた場合マッチしません。
※更に、要素名と属性名などの区切りには「<a/href=x>a</a>」のように / も使えます（IE, Firefoxのみ）。 　厳密なマッチに拘ると、どんどんややこしい事になるのは間違い有りません。
意味のない所で++、+{n,m}、++{n,m}を使用しない
++は後ろを見る分だけ+より低速です。
+{n,m}は回数を数える分だけ、+より低速です。
++{n,m}は回数を数える分だけ、++より低速です。
但し、よく分からずに+に置き換えると誤爆が発生するので注意が必要です。
必要ない繰り返し表現は使わない
http:/+w と http://w の場合、後者の方が 37% 程高速です。場合にもよると思いますが、繰り返し表現は結構遅いようです。
出現率が高い物は、グループ内の前の方に置く
例えば、.(cc|fr|tv|com|net|jp)/　の場合で、jp,com,netの順で出現率が高いのであれば、　.(jp|com|net|cc|fr|tv)/　の様に並び替えた方が若干高速になると思われます。
グループを文字クラスに置き換える
gr(a|e)y と gr[ae]y の場合、後者の方が 30〜50% 程高速です。前者の方が遅いのは、\0-9# に保存できるようにとか、&/&& が使用出来るように、何かメモリ周り？の処理が行われている為ではないかと思われます。（Perl5の正規表現で言う (?:) は存在しません）
無意味なグループ化をやめる
(*)\0 と \0 の場合（両方同じ物にマッチします）、後者の方が 24% 程高速です。前者の方が遅いのはやはり何かメモリ周り？の処理が行われているためではないかと思われます。
グループを繰り返しに置き換える
http(s|): と https+: の場合、後者の方が 5% 程高速です。前者の方が遅いのはやはり何かメモリ周り？の処理が行われているためではないかと思われます。
但し、https+: は httpsssss: 等にもマッチするので厳密なマッチを必要とする場合注意が必要です。
リストの改行コードを LF にする
CRLF より読み込むデータ量が減るので、その分高速化出来ます。
殆どハッシュ化されていない場合や、HDDが遅い場合結構差が出るかも知れません。　※CRにすると正常に動作しなくなるようです（1行と認識してしまう？）
↑

Proxomitronを使うと文字化けが発生する / 何も表示されない事がある † Edit

以下の原因が考えられます。

↑

置換、挿入した文字がIEのエンコード自動判別を誤認させている † Edit

Internet Explorer (IE) のエンコード自動判別は、ページの頭から256?Byteを見て、判断している。
（ローカルキャッシュの場合は、丸ごと見て確実に判断しているようが、ネット上では受信が途中でも表示しなければならない為、頭の一部で判断しているものと思われる）

そこで、<start>等で頭に文字が入ると、問題が起こる。
頭にShift_JIS、EUC-JPなど、特定コードにしか無い文字が挿入されると実際はそのエンコードでなくても、そのエンコードと誤認して処理してしまう。
また、誤認しない文字(ASCII)でも、頭に何か挿入すると、256?Byte - 挿入したByte になり、自動判別し辛くなる。
その為、IEを使用する場合、ページの頭にはあまり物を入れない方が良い。

『IEのエンコード自動選択ミス増加』対策

↑

Proxomitronが置換、挿入した文字自体がおかしい為、その部分が化けて表示されている † Edit

例えば、

ページの文字コードに合わせた物を出力しないと駄目です。出来るだけ半角英数字以外は使わない方が良いです。
Shift_JIS/EUC-JP/JIS/UTF-8 どの文字コードのページでもマルチバイト文字を挿入したい場合は文字列 → 数値文字参照を使用してください。　※IEの場合こっち推奨
他に、Proxomitronとサーバーの間に、文字コードを変換するProxyを挟むと一応解決する　筈　（Proxomitron補助串＞Unicode等をShift_JISに変換）

↑

コメントタグとして処理されてしまっている † Edit

コメントタグ（<!-- コメント -->）が閉じられていないが、ブラウザの解釈により正常に表示されていた場合、コメント内で最初に出た何かのタグの閉じ部分でコメントが終了したと解釈される。
が、これより後ろにコメントタグを挿入すると、そのコメントタグの終了部分（-->）が最初のコメントタグの閉じであると解釈され、間が全てコメントになり非表示になってしまいます。
コメントを挿入するのは控えめにした方が良いです。
IEの場合、<comment> タグに置き換えるといいかも知れません。

他にはScript、タグ、CSS、背景画像等、何かを破壊してしまっている為、正常に処理されていない。 または背景色と同化している等が考えられます。

↑

4.5限定のリクエスト拒否バグ（切断バグ）で何も表示されない † Edit

Proxomitronがブラウザからサーバへのリクエストを受け取っても、サーバにリクエストを送信しないことがある。（バイパス時でも発生）
ログウインドウを見ると、+++GET 1+++ の直後に +++CLOSE 1+++ があり、+++RESP 1+++ が無いためサーバからのレスポンスを受け取っていないことが解る。
リンクやボタンをクリックしても反応が無い場合はこのバグの可能性も疑う必要がある。

今の所、解決方法は4.5を使用しない以外にないようです。

735 ：名無し~3.EXE ：sage ：2007/07/03(火) 12:01:38 ID:PTHvBvVQ
オミトロンでサーバーが見つかりませんになるやつ
IEの詳細でスクリプトエラーとデバッグを無効にすると出なくなったよ

検証求む

現在この現象が、どういった条件で発生するのか多分よく分かっていません。　このバグと思われる現象の発生を確認した場合、掲示板の方へ発生した時の状態などをご連絡いただければ幸いです。（もしかすると何か解決方法が見えてくるかも知れません）

↑

フィルタ作成に関して † Edit

添付ファイル: file7168.htm 96件 [詳細] file7167.htm 113件 [詳細]
  複製 名前変更
QRコード（トップページのアドレス）