>>450 Image Checker と、 Image Checker After は別物です。
>>444に
Image Checkerを一番先頭に持ってきて
次に上記フィルタを入れてみて下さい。
と書いてありますよ。
^*.(jpg|jpeg|gif|png|bmp)"
の方はまだやってないのでわかりません。
>>451 >>444を読み間違えていた。てっきりImage Checkerの改良版と思って
た(^^;)。
補足&訂正
後、私が試した環境は ^*.(jpg|jpeg|gif|png|bmp) が全て入ってます。
んで、どのフィルターが原因で化けるのか私はつきとめてないので不要かそうでないかの確認はしないです。
>>453 私も^*.(jpg|jpeg|gif|png|bmp) が全部入ってます。^*.(jpg|jpeg|
gif|png|bmp)追加してない人で、Image Checker&Image Checker After入れ
て画像化けない人、報告希望。
455 :
名無し~3.EXE:2001/08/04(土) 20:18
こないだまで全く画像の破損は起こってなかったんですが、
いろいろいじったら(何したか覚えてない)起こるようになっちまいました。
Image Checkerをフィルタの先頭に持ってきても直らず。
あ〜、全部に「^*.(jpg|jpeg|gif|png|bmp)」付け足すのめんどくせーなーと
思ってたところへ
>>444のフィルタの登場。
>>444のフィルタをImage Checkerのすぐ後に追加したら直りました。
もちろん、「^*.(jpg|jpeg|gif|png|bmp)」は入れずにすんでます。多謝!
>>455 おー、じゃー、もう完璧に解決みたいですね。
画像化けには
URL: Filter image extension(ノーマル)と、Image Checker(強化版)と、Image Checker After ということで。
>>455 報告感謝。^*.(jpg|jpeg|gif|png|bmp)追加するの確かに面倒だった。
これでもう面倒な事しなくていいって事だね。
Protocol src killer や Trinity's Protocol Killer より
完成度の高いフィルタが出るかなって思って簡単なブラクラ (
>>375)
を作ったんですけど、誰も対応できるフィルタを作ろうと
しないんですね。ちょっと寂しい。(笑
自分で作れって?
作りましたけど、やっぱりお二人には足元にも及ばないって
ことが分かったので途中で止めちゃいました。難しかったです。
第一、どんなに完璧なフィルタを作ったとしても Byte Limitで
バイト数を制限している限り、全ては防げませんしね。
>>449 ありがとうございます。
今から見に行きます!
あと、なんでImage Checker Afterを使うとOKなのかって事ですよね?
>>288 に書いた通り、ImageCheckerで<htmlとかをチェックした後は
フィルターかける必要がないので、マルチをOffにして
コンテンツタイプが画像のものをスルーしただけです。
かちゅ〜しゃでomitron使おうと試行錯誤したり、ここを読んで
コンテンツタイプがhtmlじゃない場合はヘッダ/フッタが付かないと
分かったのでじゃあいけるんじゃないかと。
ただ、内部で一行とみなす符号が来るたびにフィルター通るので
画像の表示スピードは落ちる予感がします。
# 本当は\kみたいなオプションで「以降をバイパスする」という
# オプションなりコマンドがあれば言う事ないんですが
# 次善案と言う事で。
>>455 自分も試してみた。^*.(jpg|jpeg|gif|png|bmp)を入れたDefault.cfgを
コピー&リネームして、^*.(jpg|jpeg|gif|png|bmp)を削除したDefault.cfg用
意して、画像が半分しか表示されないページを見に行ってみたら、問題無く表示
出来るようになってた。
^*.(jpg|jpeg|gif|png|bmp)を追加する手間これで省ける(^^)。
>>444さん、ありがとう。
>>449 何も考えずにNeo Allow for frame resizingを
頂いて使ってみたのですが結果は同じでした。
ブラウザの解釈の差のようなので時間を見て
チェックします。
家のブラウザはIE5のSP2(?)で
会社のはIE5.5のSP1だからAllow〜で
改変された部分を見てNOFRAMEに飛ばす処理が
バージョンによって異なっているようです。
こうなるとomitronの話ではないので...
# 5.00.3315.1000(SP2)これってIE5?
>>462 なるほど。ありがとうございました。
やっぱり会社の方がバージョン上です。
# しかしちょっと記述を変えたくらいで
# NOFRAMEに飛ばさないで欲しい>IE5.01
>>459 解説有難う御座いました、理解できました。
画像の表示速度は特に変わらないような感じです。
>>461 そうでしたか。
でも私も5.01SP2ですが正常に表示されますよ。
>>464 462について
CLASSICPentium133とかいうマシンだと
もしかしたらイライラするかもしれないです...(推測)
一応無駄を省くと言う意味では
>>437 を入れて一定サイズを超える物は
バイパスさせる方がCPUに優しいかもしれませんね。
461について
え!
実を言うと
>>446のZAKZAKもダメダメな画面になるので
IE5.5以降を入れるまでAllow系はあきらめようかと
思ってたのですがやっぱりもうちょっと調査してみる気になりました。
>>465 負担を軽くする為に URL: Filter image extension [P] [08.04.2001]
をってのは私も考えたんですけど、あのバージョンでは範囲外の画像もフィルタリングしてしまったんですよ。
で、
>>456ではノーマルって書いたんです。
んで、修正したのを創りました。
In = TRUE
Out = FALSE
Key = "URL: Filter image extension [P] [08.04.R2.2001]"
URL = "*.(jpg|jpeg|gif|png|bmp)"
Match = "$IHDR(Content-Length: [#0-51200]$FILTER(true))"
初期設定では50kb以下のしかフィルタリングしません。
其れを超えるのを創ってこられる可能性もあるのでそこらへんは臨機応変に変えて下さい。
創ってこられる->創られてしまう
なんか変だったので訂正・・・。(^^;;
フィルタに著作権ってないの?
テキストファイルに著作権表示ぐらいさせといてもいいのに。
なんかこんなに研究熱心なのって外国でもそうなの?とか思ってしまって。
すごいフィルタいっぱいあるし。
default.cfgファイルが37KB程度で書き込めなくなってしまいます。
仕様なんでしょうか?
>>469 うちは100KBくらいあるけど?
壊れてるか、読み取り専用にでもなってんじゃないの?
>>470 メモ帳で開いてたのが原因でした。。。
ワードパッドで開いたら解決しました。申し訳ない。
>>468 フィルタにも著作権はあります。著作権留保の表示を書かなくても、です。
とは言え誰も主張はしないでしょうね…著作権が明言されたフィルタは基本的には
ちょっとした変更も不可能ですから。超不便。
473 :
名無し~3.EXE:2001/08/05(日) 07:38
オムトロン、有効にならん・・・
help読んでproxyの設定しろって。
475 :
名無し~3.EXE:2001/08/05(日) 11:42
>>471 default.cfgファイルは概して大きくなりがちだから、扱えるファイルの容量の上限が小さいメモ帳は避けた方がいい。
>>475-476
ひとつずつ関係ありそうなフィルタを切っていけば?
うちの環境では起こっていません。
>>479 ありがとうございます。 原因が分かりました。
Relative Path Converterです。
効果はリンクが相対パスになっている場合に、絶対パスに変換すること。
よく分からず使っていたので、こんな副作用があるとは思いませんでした。
481 :
名無し~3.EXE:2001/08/05(日) 19:44
あげとこう
板違い反対!板違い反対!板
違い反対______!板違
い反対!__糸冬__板違い
反対!板___了___違い反
対!板違______い反対
!板違い反対!板違い反対!
>>480 ベースリンクが設定されている場合には、不正なリンクになってしまう可能性がありますね。
設定しているところはあまり多くはないと思いますが。
で、設定されている場合用のフィルタも創ってみたのですがsubback.htmlだとリンクが多いので
HTML Swap Buffer Overflow, using direct replace
が出ちゃって途中までしか変換してくれませんでした。(w
後、Relative Path Converter は、サーバーによってはリンクが正常に機能しない場合があります。
そうでなくても Relative Path Converter は通常は使う必要の無いものですので切っておいた方が良いです。
Image Checker After について又疑問。
1:
URL: Filter image extension と、Image Checker だけで壊れる(途切れる)画像があるんですよ。
で、デバッグしてみると Image Checker に引っかかってるんですよね。
でも Image Checker After を使うと引っかかってないんですよ。
で、壊れない(途切れない)んです。
何故でしょう?
URL: Filter image extension と、Image Checker の他にフィルターがあって其れによって壊れるって言うなら、
Image Checker After を使うと壊れないって言うのはわかるんですよ。
でもこの場合二つだけしかなくて Image Checker によって壊れるのに、
何で Image Checker After を使うと引っかからなくなって壊れなくなるのかがわからないです。
2:
で、其の画像をローカルに保存して試すとやっぱり同じように壊れる(途切れる)んですよ。
そして、Image Checker After を使ってみると1の様に壊れない筈なのに壊れる(途中から色がおかしくなる)んですよ。
其れに Image Checker によって壊れているなら\kが入ってるから其処で途切れる筈なのに色が変わるけれど全部表示されるんです。
何ででしょ?
>>484 一応投げた本人としてコメントしますが
全く問題解決になってないのでsageます...
1:
その画像はImage Checkerを外した場合は
正常に表示されるんでしょうか?
要するにURL: Filter〜だけ有効という状態です。
かちゅ〜しゃ対応の為に色々実験してる過程で
フィルタ全offとBYPASSでは挙動が異なる事が
判っています。
ただ、その条件でImage Checker Afterを使うと
壊れない理由は不明ですね。
また、^*.(jpg|jpeg|gif|png|bmp)をImage Checker
以外に付ける対策も理屈では上記の画像には
効かないはずなのですが、実際はどうなのでしょう?
2.
JFIFに詳しい方なら理由がスグ判るかも
しれないですね。
# 手元にモノがないので想像でしか話せないの
# ですが、Image CheckerのBoundsである50bytesで
# 処理を一旦切る時に変な渡し方になってしまって
# RGBのうち一部の情報が切れてるとか...
ちょっとだけファイルフォーマットについて
調べてみましたが果てました。
〜ひとりごと〜
実はImage Checker Afterについて自分のところで
画像化けが再現するまで発表せず、
自分のところで再現してもイマイチ自信がないのが
>>299で教えて頂いたBBSの343にて「処理が重くなることで、
どこかで処理落ちが発生しているのではないかと推測
しています。」という部分がある事です。
要はパフォーマンスの影響だとすれば
Image Checker Afterが効かない環境が
存在するのではないかと。
Image Checker Afterは単なる力技で、やってる事が
単純なので謎が出てくると余計に謎が深まります。
>>485 私もさげとこ。
&長くなって怒られたので分割。
1:
Image Checker を外した場合は正常に表示されます。
^*.(jpg|jpeg|gif|png|bmp) を付けたとしても壊れますね。
Image Checker によって壊されてます。
でもやっぱり Image Checker After を使うと壊れません。
ローカルでは
>>484の2と同じでした。
2:
Bounds を変えてやってみました。
数値を変更すると変化が見られたので実験してみました。
ちなみに其の画像のファイルサイズは251709 bytes です。
A:
ローカルで Image Checker After の値をデフォルトのままにして Image Checker の値を
0〜32767(Boundsの設定可能最大値)の中で変更していってみると、
小さくするとフィルタに引っかからなくなって当然正常表示。
引っかかる〜1000位までは境界線毎に段階的に赤くなり、其れ以降〜最大値手前位までは壊れたTVの様にカラフルな細い縞模様になり、
最大値辺りでXが出て全く表示されなくなります。
サーバー上でも同じでした。
只、表示のされ方が若干違いました。
小さい値はバイパスした時と同じように少しずつ表示されていきますが、
大きい値の時は処理され終わる毎になので、ある程度の量ずつボンボンと表示されていきました。
B:
で、ローカルで逆にImage Checker をデフォルトで固定してImage Checker After の値を変更していくと、
35以下は正常に表示されます。
只、色の変化が非常に小さく、目に見えて判り辛いだけかもしれませんが。
で、其れ以降〜最大値手前までは前述の縞模様。
最大値少し手前だと今度は青が段階的に薄くなっていき、
最大値付近だと何故か正常に表示されます。
サーバー上でも同じでした。
表示のされ方はAと同じです。
何でこうなるのかサッパリわかりません。(w
しかもローカルで変化が見られる値でもサーバー上のものでは変化が見られなかったりと不思議です。
少しの破損は補正されるんでしょうかね。
ともかく実験した結果、 Image Checker After はBoundsの値を小さく設定しておく方がいいのかなと思いました。
処理も小さくした方が軽い様に感じました。
見掛けだけの判断ですが・・・。
結局、何故 Image Checker After を使うと壊れないのかは分からなかったです・・・。
489 :
名無し~3.EXE:2001/08/06(月) 22:42
>ともかく実験した結果、 Image Checker After はBoundsの値を小さく設定しておく方がいいのかなと思いました。
>処理も小さくした方が軽い様に感じました。
初心者にもわかるようにおねげーします。。。
具体的に下のをどうすればちょっとは軽くなったりするんでしょうか。
結果のおいしいとこ取りだけですみません。
あと、2chのスレッドを表示する時に
IEの方で「表示ごとに確認」としてるのにキャッシュが表示されるのですが、
URLに飛んだら常に最新のものが見れるようにするのは
どのフィルタをオンにすべきなのでしょうか。お願いします。
Name = "Image Checker After"
Active = TRUE
Limit = 50
Match = "$IHDR(Content-Type: image/(jpeg|gif|png|bmp))&(*)\0"
Replace = "\0"
>>486 ファイル比較ツール使って、バイナリを直接比べてみれば、
壊れるところの法則性とか分かるかも。
あら、ずいぶん懐かしい。
>>489 Limitをできるだけ小さく(=0?)です。
私が変な用語を使ったせいで混乱させて
すみません。
# しかしどこで覚え間違ったのだろうか。
あと、常に最新のものを見るには
何かをoffだと思います。
htp://www.pluto.dti.ne.jp/~tengu/proxomitron/11headerfilters.html
ここを見れば見当がつくのでは?
494 :
名無し~3.EXE:2001/08/07(火) 00:38
493を間違って下げたのでこっちを上げてみます。
# あと、BoundsはBytes Limitでオッケーですか?>Proxmineさん
>>486 AとBの検証を見てそういうアプローチがあったのかと
感動しました。
Image Checkerで壊れるとしたらjpegファイルの
コメント部分に「<link」とかがある可能性もありますね。
前からPhotoshopのヘッダ部分やコメントブロックに
そういう文字列を入れた場合の挙動を見てみたかったのですが
なかなか時間がとれなくてやってませんでした。
あと画像にファイルを埋め込んである場合とか。
# 作業自体は10分とかからず出来るんですが。
しかしその場合でもImage Checker Afterを使うと壊れない
理由は判らないままですが...
>>493 今やっと気づきました。BoundsのByte Limitだったとは。
しかしBounds本体がなくてもByte Limitの値が有効なのも
不思議な話ですが。
あと、
>>492見て興味もったので
>>491を見たのですが
こういうのに対応するのは面倒臭そうですね。
\nと半角SPACEは盲点でした。
>>495 \nとSPACE対策しようかと思ってたら
デフォルトで無視してくれるんですね。高性能。
>>489 Expires: allways cache (in)がonだと常にキャッシュを
見てしまうかもしれません。フィルタの名前からして。
少なくともこれはoffに。
#
>>493のページってフィルタの説明だと思ってたけど
# 違いましたね。ごめんなさい。
# ちなみにウチではこれがonでもキャッシュを見ないので
# 他にも要因はあると思います。
# また気づいた時に解決してなければカキコしますね。
>>494 あ・・・、其れでOKっす・・・。
>>485で>>Image CheckerのBoundsである50bytesで
って書かれてたんでなんの疑いも無くそのまま使っちまいやした・・・。
>>495のBoundsのByte Limitって意味だったんすね・・・。
で、
>>440さんの言うように比較してみると、
<〜〜〜iMG〜〜
と言う部分があり、其処が Image Checker に引っかかってました。
でも Image Checker After を使うとオリジナルとの相違点は無し。
何でだ。
此れだと場合によってはブラクラ素通りになってしまう可能性もあるかもしれませんよね。
で、 Image Checker After のByte Limitですが、
其の画像ではローカルの場合、3-35の間は正常に表示され其れから1でも変更すると壊れました。
サーバー上では4-1058まではOKで其れから1でも変更すると壊れました。
一体この差はなんでしょう。
3とか4ってのは img < の分なのかななんて安易に考えてみたり。
其れがあってれば7でOKかな、なんて。
後、実験はノーマルのURL: Filter image extension と、強化版のImage Checker とで試しました。
Image Checker の置換値を変えると又結果が変わりました。
って言うかみんな名無し~3.EXEなので誰が誰だかサッパリ分からなかったり・・・。
>>489 Limit を7位で良いと思います、多分。
で、常に最新は
If-Modified-Since: Always reload pages (Out)
If-None-Match: Always reload pages (Out) *
If-Match: Always reload pages (Out) *
If-Range: Always reload pages (Out) *
If-Unmodified-Since: Always reload pages (Out) *
Last-Modified: (In)
Pragma: Force reload (out)
の7つをONにしておけば良いと思います。
そうしておけばキャッシュ関係のはどうでも構いません。
*のは If-Modified-Since: Always reload pages (Out)
をベースに、名前だけ変更したのを新しく作ってください。
ヘッダの説明はこちら。
http://www.atmarkit.co.jp/fnetwork/rensai/netpro01/header-fields.html