【本スレ】不具合報告・改善要望スレ

■掲示板に戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

レス数が1000を超えています。残念ながら全部は表示しません。

590 ：名無しさん：2006/09/07(木) 15:31:18: 無理難題を承知で要望。
rep2-expackのImageCache2みたいに、過去に表示した画像をデータベース化＆保存できる機能が欲しいです。
こまごまとしたボタンみたいなのまで保存されても困るから大きさで閾値をつけて。
591 ：587です：2006/09/07(木) 16:07:58: 知り合いのEZで試したら問題はなかった。と記憶。
（たしか日立のやつだったと思った）
すべての機種に当てはまるかは　不明です。
592 ：管理人さん ★：2006/09/07(木) 17:40:12: >>591
多分、内蔵ブラウザの仕様ではなくゲートウェイの仕様だと思われ。
「クエリーのキーにsidは使えねえ」みたいなJ-PHONE時代の遺物。
そして一度作っちゃったら、いくらウンコでもとにかく変えない変わらない。
それがJ-PHONEクオリティ。
593 ：管理人さん ★：2006/09/07(木) 18:26:47: >>590
ブラウザのキャッシュ機構のように、一度変換した画像は保存しておいて
同じ画像がリクエストされたら保存してあるものを表示する機能なのか
それとも単に保存した画像の一覧表示などができればいいのか、どっち？

ImageCache2はもちろん後者なので、後者だと思うけどそっちは割りと簡単。

前者は、多分余談なんだけど、以前から何度か作ろうと思ったことはある。
しかし変換サイズもまちまちなわけで、同じ画像でも様々なファイルが作られ
単純にそれだけでディスク容量を喰うので定期的に掃除もしなきゃいけない。
そうなると保存や掃除に要する負荷を考えると
逐次変換していても効率は変わらないと思ったので却下してきた。
594 ：管理人さん ★：2006/09/07(木) 18:27:07: ファイルに保存するには
imageGIF|imageJPEG|imagePNGで画像データを（メモリに）出力している箇所に
同じ要領でデータをファイルに出力する処理を追加すればいい。
各関数は第2パラメータにファイル名があればデータをファイルに出力する。
なので、例えば以下のJPEG出力のところを

imageJPEG($_new_resource, null, $_quality);

以下のように変更する。

imageJPEG($_new_resource, 'ファイル名', $_quality);
imageJPEG($_new_resource, null, $_quality);

最初のimageJPEGはファイルに出力していて
2番目のはメモリに出力している。

ファイル名は一意になるよう、例えばURLのMD5値にする。
（必要ならサイズとか品質も加える）

global $remote_url;
$filename = './hoge/'.md5($remote_url).'.jpg';
imageJPEG($_new_resource, $filename, $_quality);
imageJPEG($_new_resource, null, $_quality);

ディレクトリ内の画像を一覧表示するCGIはそのへんに転がってるので
適当なのを拾ってきてちょ。

サイズのしきいは変換の有無のしきいのまま。
ただしこれはあくまでIMGタグの指定で、指定のない画像は変換されちゃう。
なので、一覧表示の際などにgetImageSize()で実際のサイズを確認し
掃除を行うのが効率的だと思われ。

DBの場合も考え方は基本的に同じだけど
この場合はob_get_contents()の出力をDBに突っ込む処理を加える。
当然DBなので、URLなどの付帯情報も格納しておく。
595 ：管理人さん ★：2006/09/07(木) 18:37:21: ということで、あとはがんばってね（はーと
という主旨は伝わりましたでしょうか？ｗ
改造こそオープンソースの醍醐味だっ！
596 ：名無しさん：2006/09/07(木) 18:42:15: auは未エンコードの?が2回出現すると、二回目の?以降を切り捨てて読むはずだったような

だから確か友が機能しなくてエンコードする仕様になったんでしたよね。
さすがにエンコードしても駄目ということはないです。
597 ：管理人さん ★：2006/09/07(木) 19:41:57: >>596
ああそんなこともあったっけ。。。
auのは極めて正しい仕様。
エンコしててもダメだと言われた日にゃ
つまりあらゆるGETなフォームに「?」は一切入力できないわけですよ。
598 ：590っす：2006/09/07(木) 23:54:53: キャッシュで再表示か、画像一覧か、といえば、「両方」のつもりでした。
画像一覧を作るなら、同一性の確認が必要→ならキャッシュも、という感じで。
それで速度が速くなるなら、二度美味しいかな、という感じです。

あと、もう一つのイメージとして、
「携帯で見た後、家のPCで原寸大で見る」というのがありました。

ヒント、ありがとうございました。
なんとなく、出来そうな気がします。
時間が出来たときにでもやってみようと思います。
599 ：◆BFqOh.DRZU ：2006/09/08(金) 14:29:40: webページのあぼん設定とかできたら面白いかも
このページのこの広告はウザイのではなから表示させたくないとか
pc2mでページをみるときに必要ない部分を表示させないとか

可能ですか？
600 ：管理人さん ★：2006/09/08(金) 15:43:30: >>599
可能だけど。。。具体的な仕様を考えると
対象のURLと、除去したい箇所の正規表現を登録しておくことになる。
もちろん、汎用的に使える正規表現はないと思うので
URL単位でそれぞれ考えることになるのだけど
そうなると登録項目が随分増えるだろうからウザいことになるのと
そもそも一般的に正規表現を考えること自体がウザい希ガス。

今の仕様のままなら文字の変換表（$replace_chars）に
左辺に正規表現を書いて右辺を空文字にしとけば合致する箇所は除去される。
（ハッシュのキーに正規表現てあり得ねえだろ、というツッコミはスルーで）
ただしこれは、URLのマッチングはやらないので
意図しないページの意図しない箇所が消えてしまう可能性もある。
それと、この正規表現はこの処理が行われる時点のHTMLにマッチする必要があり
決してオリジナルのHTMLではない点に注意。

あと、今どきの一般的な広告はIFRAMEか、SCRIPTとNOSCRIPTを使っていて
IFRAMEとSCRIPTはデフォで除去してるので（IFRAMEを除去してる理由はそもそもこれ）
NOSCRIPTも除去するようにしてしまえばかなり減るとは思う。
（人柱版なら、FormatRuleのNOSCRIPTの箇所を削除すればいいので簡単）
601 ：管理人さん ★：2006/09/08(金) 16:10:07: >>598
原寸大（オリジナル）を確認するなら
やっぱしDB使って元のURLを格納しといたほうがいいわなあ。
（ディスクに余裕があればオリジナル画像も保存しとけばいいけど）

主旨とズレるんだけど
携帯で見た後、家のPCでということで
復元用に保存してあるセッションデータのバックアップを読んで
携帯でのアクセス履歴をPCで確認できるといいかもと思いますた。

キャッシュ機構は、ある程度大規模な利用があるなら
もちろんそのほうが効率いいわけだけど
原則個人利用なら>>593の通り。
データ取得の際も、いったんキャッシュのタイムスタンプを確認して
If-Modified-Sinceヘッダを付けて、レスが304なら・・・
という感じで結構ややこしくなるですよ。

246KB

掲示板に戻る全部前100 次100 最新50

0ch BBS 2007-01-24