none
キャッシュに非ascii文字のファイル名のゴミが残る RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    Vista+IE9で、

    http://ja.wikipedia.org/wiki/%E4%BC%8A%E8%97%A4%E5%8D%9A%E6%96%87

    を開くと、キャッシュに

    http://upload.wikimedia.org/wikipedia/commons/thumb/3/3e/It%C3%B4_Hirobumi.jpg/250px-It%C3%B4_Hirobumi.jpg

    に対して

    250px-Itô_Hirobumi[1].jpg

    のようなファイルができる。

    このため、名前を付けて画像を保存しようとすると、

    250PX-~1.JPG

    のような名前になる。これはこれでよいのかも。

    また、キャッシュを削除すると、ファイルとフォルダが削除されずに残る。これが問題。

    したがって、ここでの疑問は、なぜ、IEは非ascii文字のキャッシュファイル名を作るのか？

    iso-8859-1はurl decodeする癖があるのか？です。これが原因かと疑っているのですが、これはこれでよくて、原因は別かも。

    実際には、キャッシュの残存ゴミを見ると、40px-Itô_Hirobumi[1].jpgのようなwikipediaの画像ファイルばかりだったので、上記のように逆類推してます。

    index.datを覗いてみると、

    http://upload.wikimedia.org/wikipedia/commons/thumb/3/3e/It%C3%B4_Hirobumi.jpg/250px-It%C3%B4_Hirobumi.jpg

    250PX-~1.JPG

    URLはUTF-8のURL encodeで、ファイル名は短い名前。

    ファイル名が非ascii文字の場合は短い名前で入るみたい。

    これがゴミ残しと関係する？

    2012年3月13日 12:29
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票
    お疲れ様です。
    すばらしいですね。
     
    ご確認された発生条件について確認させて下さい。
     
    キャッシュの実ファイルは、
    250px-Itô_Hirobumi[1].jpg
    で保存されているにもかかわらず、
    index.datには(key部ではなくvalue部の方)
    250PX-~1.JPG
    となっているのですね。
     
    で、分かりませんが、ファイル名に
    ô  (U+00F4)
    が含まれていることが原因で発生していそう(している)ということですね。
     
    URLはUTF-8のURL encodeで、ファイル名は短い名前。
    ファイル名が非ascii文字の場合は短い名前で入るみたい。

    そういえば、ファイル保存ダイアログに表示されるファイル名も
    URLエンコードして書けば、短いファイル名になりましたね(IE8以降)。
    実際、ファイルを保存すると、短いファイル名になりました。
     
     
    これが、どの環境でも再現するなら、
    次のサイトにある要因に、文字種周りのことも触れられているとよいかもですね。
     
    Internet Explorer 一時ファイルが肥大化する
    http://blogs.technet.com/b/jpieblog/archive/2011/09/09/3452071.aspx

    インデックス情報の破損の要因は様々に考えられ、残念ながら破損した状態の後からその理由を遡って確認する事ができません。
    （略)
    例えば、要因として考えられるものとしては「実ファイルのみを直接削除してしまった」、「（ユーザー操作なども含め）キャッシュの削除を行おうとしたが、実ファイルが他のプロセスにロックされていて削除できなかった」などです。

    2012年3月24日 2:19
    |
  • Question
    サインインして投票
    0
    サインインして投票

    キャッシュの残存ゴミが、40px-Itô_Hirobumi[1].jpgなので、どのページなのか探したところ、

    http://ja.wikipedia.org/wiki/%E8%A5%BF%E9%83%B7%E5%BE%93%E9%81%93

    こういうページの

    http://upload.wikimedia.org/wikipedia/commons/thumb/3/3e/It%C3%B4_Hirobumi.jpg/40px-It%C3%B4_Hirobumi.jpg

    のほうみたいです。

    2012年3月24日 16:42
    |
  • Question
    サインインして投票
    0
    サインインして投票


    キャッシュの実ファイルは、
    250px-Itô_Hirobumi[1].jpg
    で保存されているにもかかわらず、
    index.datには(key部ではなくvalue部の方)
    250PX-~1.JPG
    となっているのですね。

    で、分かりませんが、ファイル名に
    ô  (U+00F4)
    が含まれていることが原因で発生していそう(している)ということですね。

    それだけでは、十分条件ではなく、他の要因がありそうです。残っているのはそういう条件ですが、そういう条件のものは他にもあるのに残っていないので。

    また、面白いのは、

    http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:%E5%AE%87%E9%83%BD%E5%AE%AE%E9%A4%83%E5%AD%90%E5%83%8F.jpg

    のような非asciiでも日本語は、index.dat内のファイル名が

    宇都宮~1.JPG

    になっていることです。別に短い名前にする必要はないのに。なんででしょうね。

    似たシチュエーションなのに日本語ファイル名のゴミは見かけません。 

    やはり、非shift-jis文字というかiso-8859-1文字が問題なのかなぁ。

    2012年3月24日 16:56
    |
  • Question
    サインインして投票
    0
    サインインして投票

    英語圏で日本語ファイル名の短い名前はどうなるんでしょう？宇都宮~1.JPG なんでしょうか？

    iso-8859-1文字(128～255)の場合は日本語と違って短い名前に規則性がありません。似たアルファベットになったり、似た日本語文字になったり、抜けたりします。これは英語圏でも同じなんでしょうか？英語圏では、宇都宮~1.JPG みたいに単純なのでは？

    その辺の違いが絡んでいるような気がします。

    2012年3月25日 10:30
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ちょっと脱線しますが、これって、短いファイル名の割り当てをしないとき、どうなるんでしょう？

    2012年3月26日 12:11
    |
  • Question
    サインインして投票
    0
    サインインして投票

    話題として以下に3つほど、書かせていただいています。
     
    ①

    それだけでは、十分条件ではなく、他の要因がありそうです。残っているのはそういう条件ですが、そういう条件のものは他にもあるのに残っていないので。

    ご指摘ありがとうございます。
    色々難しいのですね。
     
    なお、手元の環境では、ファイルが残る事象は、IE9では再現しましたが、IE10CPでは再現しませんでした。
    IE10でもキャッシュの実ファイルは「250px-Itô_Hirobumi[1].jpg」で保存されましたが、インターネットオプションから削除すると削除されました。
    IE10でwininetがサービス化されたり？色々変わっているのかもです。
    (ProcessExporerで見ると、index.datがcontainer.dat(0kbですが)になった？？)
    IE9では、削除＆閲覧を繰り返すとどんどん増えていきました。
     
    ※ファイル保存ダイアログの表示に関してはIE10CPでもIE9と同じでした。
    ※正直、IE9までのwininetの文字コード周りの動作は意味不明？な感じ。(IE10も分かりませんが）

     
     

    ②点目として、確認なのですが、
    ゴミかどうかの判断するための”簡単かつ確実な方法”のいい感じな方法の意識合わせをしたいのですが、
    ウィンドウズスクリプトプログラマさんがanswersで書かれていた
    インターネットオプションで削除した際に、残ったフォルダのうち、フォルダの濃ゆさで判断しています。
    （実際は、さらにindex.datをテキストエディタで開いて、削除する前と後で何が変わったかの比較も行っています）
    よりよい方法がありましたら、ご指摘お願いします。

     
    ③

    英語圏で日本語ファイル名の短い名前はどうなるんでしょう？宇都宮~1.JPG なんでしょうか？

    参考までに手元のWin8CP&IE10環境の英語版の環境があったため、確認すると、
    伊藤博文(250px-It%C3%B4_Hirobumi.jpg)画像を右クリックでファイルを保存(Save picture as...)をすると
    短いファイル名「250PX-~1.JPG」になりました。
    キャッシュ上はどのように管理されているのか分からなかったため(index.datが見つからない！)調査していません。

    2012年3月27日 17:07
    |
  • Question
    サインインして投票
    0
    サインインして投票

    (2)

    同様です。正規の使用中のフォルダにはdesktop.iniがあるようです。正しくは親のindex.datの中にサブフォルダ名の配列があるようですが、そこを見るまでもなくわかるので。

    (1)

    現在、ゴミのフォルダが１２個ありますが、すべてに、非jisファイル名の[1]が１個だけあります。
    この条件の一致は不思議です。この、遠慮の塊、関東のひとつ残し、みたいなのはなんなんでしょう？

    (3)

    これはieの話でなく、osの疑問です。
    短いファイル名が英大文字~1とは限らず、日本語圏で宇都宮~1やｱｲｳｴｵｶ~1になるのなら、英語圏では、Itô_HirobumiはITO_HI~1でなく、ITô_HI~1になるのかな？という疑問です。もし、それがITO_HI~1になるのなら、ôのUpperCaseがOってこと？？？みたいな。短い名前は日本語圏、英語圏に関係ない規則なんでしょうか？

    2012年3月28日 18:49
    |
  • Question
    サインインして投票
    0
    サインインして投票

    すみません。ようやく理解しました。
    以下の部分の話をされていたのだと思いました。
     
    Windows で長いファイル名から 8.3 ファイル名が生成される方法
    http://support.microsoft.com/kb/142982/ja

    ファイル名と拡張子のすべての文字が大文字に変換されます

    該当しそうなのは、以下でしょうか。
    GetShortPathName
    http://msdn.microsoft.com/ja-jp/library/cc429345.aspx

    そして、以下を見ると、旧来のファイルシステムとUnicodeが影響しそうで、
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#short_vs._long_names
     

    さらに、両方に関連しそうなファイルシステムドライバAPIとして、以下あたりがそれっぽいような？気がしています。
    （特にRemarksに書かれている、変換→逆変換→大文字にするという下りあたり。外してたらすみませんが。）
     
    RtlUpcaseUnicodeStringToCountedOemString
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff553277(v=vs.85).aspx

    だとすると、おっしゃるように上記リンク先に書かれてある「current system OEM code page」によりそうですね。
    （DOSっぽいCP850とCP932との差とか影響したりして？）
    ※ôがindex.datとリンク切れになるかは、フランス語版を入れて確かめるとよさそうですかね！？
     
    index.datの話もありますが、
    何より右クリックの「名前を付けて画像を保存」に影響する処理であるため、私も気になっています。。。
     

    ちょっと脱線しますが、これって、短いファイル名の割り当てをしないとき、どうなるんでしょう？

    そもそも短いファイル名を割り当てている理由の方が気になっています。
    （分かりませんが、互換性、セキュリティ、汎用性等を重視した結果、通常用途が犠牲になってたりするような？）
    それはともかく、話題にされているのは、
    長いファイル名時の日本語OSでの日本語以外の文字列のIEのキャッシュファイル名の話でしょうか?
     
    以上、よろしくお願いいたします。

    2012年3月29日 15:12
    |
  • Question
    サインインして投票
    0
    サインインして投票

    さらに、両方に関連しそうなファイルシステムドライバAPIとして、以下あたりがそれっぽいような？気がしています。
    （特にRemarksに書かれている、変換→逆変換→大文字にするという下りあたり。外してたらすみませんが。）

    RtlUpcaseUnicodeStringToCountedOemString
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff553277(v=vs.85).aspx

    だとすると、おっしゃるように上記リンク先に書かれてある「current system OEM code page」によりそうですね。
    （DOSっぽいCP850とCP932との差とか影響したりして？）
    ※ôがindex.datとリンク切れになるかは、フランス語版を入れて確かめるとよさそうですかね！？

    それですね、きっと。つまり、英語圏では、宇都宮~1やｱｲｳｴｵｶ~1にならず、たぶんITô_HI~1になるのでしょう。

    何より右クリックの「名前を付けて画像を保存」に影響する処理であるため、私も気になっています。。。
    そもそも短いファイル名を割り当てている理由の方が気になっています。
    （分かりませんが、互換性、セキュリティ、汎用性等を重視した結果、通常用途が犠牲になってたりするような？）

    右クリックの「名前を付けて画像を保存」のファイル名はキャッシュのファイル名から取ってくるのだと思います。ただし、[1]は外して。それはまたindex.dat内のファイル名から来ているので、それが短い名前だとそうなる。

    index.datのファイル名が短い名前になるのは、非JIS文字だと、～～A()で返せないからだと思います。なので、Itôが短い名前になるのは分かりますが、宇都宮餃子[1]が短い名前になるのは分かりません。

    で、結局、非JIS文字のファイル名のものだけ、それもひとつだけが削除されないで残るのかは謎です。

    2012年3月29日 21:01
    |
  • Question
    サインインして投票
    0
    サインインして投票
    そうなのですね。参考になります！
     
    再掲になりますが、imgタグのsrc属性の書き方が、
    ・URLエンコードすると短いファイル名（無題.pngになる場合もあり）
    ・エンコードせず直書きすれば無題.png
    となるようでした（IE9で再確認しても同じでした）。
    日本語ファイルへのリンクの書き方次第のイメージでした。
     
    なんとなくURLエンコードされている方が範囲が広そうからかなーと思っていました。
    （デコードしてチェックすれば同じかもしれませんが）
    こういったの制限要素（何を制限とするかですが･･)もありそうだと思っています。
     
    これも再掲ですが、Content-Disposition: inline; filename="宇都宮餃子像"を付ければ、
    日本語になります(ダイアログに投入される文字列が、宇都宮餃子像.jpgになる)。
    エンコード系の指定も出来たはず。キャッシュ上はどうなってるのでしょうね。
     
    逆に言うと、Webサーバ側でこの指定がない場合は、
    ブラウザ側でどこまで頑張って救うかという考え方もあると思っています。
    (指定がされているケースは少ない認識ですが･･･）
    2012年3月30日 12:43
    |
  • Question
    サインインして投票
    0
    サインインして投票
    再掲になりますが、imgタグのsrc属性の書き方が、
    ・URLエンコードすると短いファイル名（無題.pngになる場合もあり）
    ・エンコードせず直書きすれば無題.png
    となるようでした（IE9で再確認しても同じでした）。
    日本語ファイルへのリンクの書き方次第のイメージでした。
     
    なんとなくURLエンコードされている方が範囲が広そうからかなーと思っていました。
    （デコードしてチェックすれば同じかもしれませんが）
    こういったの制限要素（何を制限とするかですが･･)もありそうだと思っています。
    　

    それは、ファイル名というよりURLの話ですね。

    例えば、

    http://www.microsoft.com/japan/windows/Framework/images/favicon.ico?%E3%81%82%E3%81%84%E3%81%86%E3%81%88%E3%81%8A

    http://www.microsoft.com/japan/windows/Framework/images/favicon.ico?あいうえお

    の違いです。index.datに前者はそのまま、後者はutf-8で入り、後者は～～A()で通らない。なので前者はキャッシュファイル名から、後者は無題.png

    これがごみ残しに関係するとすれば、他にもっと残ってそうなので、関係なさそう。

    これも再掲ですが、Content-Disposition: inline; filename="宇都宮餃子像"を付ければ、
    日本語になります(ダイアログに投入される文字列が、宇都宮餃子像.jpgになる)。
    エンコード系の指定も出来たはず。キャッシュ上はどうなってるのでしょうね。

    そういうurlありません？

    2012年3月30日 17:27
    |
  • Question
    サインインして投票
    0
    サインインして投票

    そうそう、

    index.datに前者はそのまま、後者はutf-8で入り、後者は～～A()で通らない。

    この件、結論出てましたっけ？utf-8で入れるほうが悪い、と思います。url encodeして正規化して入れるべきじゃないかと。履歴の場合は、そうしているようです。なので、キャッシュの方がおかしい。

    2012年3月30日 17:45
    |
  • Question
    サインインして投票
    0
    サインインして投票
    これも再掲ですが、Content-Disposition: inline; filename="宇都宮餃子像"を付ければ、
    日本語になります(ダイアログに投入される文字列が、宇都宮餃子像.jpgになる)。
     

    この件ですが、すみません、間違えていました。
    IE9で短い名前になりました。(間違って対象をファイルに保存をした模様。）
     
    filenameの部分をエンコードすると変化がないかの確認も行いましたが、
    IE9,IE10共に短いファイル名「宇都宮~1」になりました。
     
    ※確認方法は、imgタグの応答に以下を付与したレスポンスを行いました(値はF12開発者ツールより)
    Content-Disposition: inline; filename*=utf-8''%E5%AE%87%E9%83%BD%E5%AE%AE%E9%A4%83%E5%AD%90%E5%83%8F.jpg
     
     

    index.datに前者はそのまま、後者はutf-8で入り、後者は～～A()で通らない。
    この件、結論出てましたっけ？utf-8で入れるほうが悪い、と思います。url encodeして正規化して入れるべきじゃないかと。履歴の場合は、そうしているようです。なので、キャッシュの方がおかしい。

    IE10CPですと、imgのsrc属性に、日本語のままで記載しても、
    「宇都宮~1」になりました(※IE9は必ず無題.pngでした)。
    ですので、ユーザ見えは前者と同じ動作になっていました。

    ・・・ちょっと脱線してしまいました。

    2012年3月31日 6:56
    |
  • Question
    サインインして投票
    0
    サインインして投票

    IE10CPですと、imgのsrc属性に、日本語のままで記載しても、
    「宇都宮~1」になりました(※IE9は必ず無題.pngでした)。
    ですので、ユーザ見えは前者と同じ動作になっていました。

    無題.pngは直ったってことですね。宇都宮~1の方は「仕様」ですね。これは仕方ないでしょう。～～A()を通すには、短い名前にするのが確実だし、保存するときもoemcpのファイル名のほうが好ましい面もありますから。RtlUnicodeStringToOemString()みたいなので長いファイル名を作って、それを使ったほうがよいと思いますが、そうはしなかったんでしょう。


    2012年3月31日 9:35
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ｷﾀ━━━( pﾟ∀ﾟ)q━━━━!!
    fsutilで8dot3nameを禁止すると、長いファイル名で表示されるようになりました！
    Win7&IE9で確認です。（Content-Dispositionと、URLエンコードされた形式の２つ。日本語バイナリ形式はIE9なので変化せず）
     
    8.3形式の短いファイル名を生成しないようにする
    http://www.atmarkit.co.jp/fwin2k/win2ktips/1200disable83/disable83.html
     

    C:\Windows\system32>fsutil 8dot3name query e:
Disable8dot3 のボリュームの状態は 1 です (8dot3 名の作成は無効です)。
     
    ▼IMGのsrcにURLエンコードした状態の画像を「右クリックでファイルに保存」したとき。


    2012年4月1日 11:22
    |
  • Question
    サインインして投票
    0
    サインインして投票

    すごい！Itô_Hirobumiのほうはどうでしょう？

    実際に短いファイル名をやめてるひとっているんでしょうか？。カタログスペックでバグだらけで使えないってことはないんでしょうか？

    2012年4月1日 19:34
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ■「名前を付けて画像を保存」時の動作をまとめてみました。
    サンプルは例によって、「宇都宮餃子像」です。
     

    記述＼Ver IE6 IE7 IE8 IE9 IE10CP
    imgのsrcを日本語直書き untitled.bmp untitled.bmp untitled.bmp untitled.png 短い名前.jpg
    imgのsrcをURLエンコード URLエンコード.jpg URLエンコード.jpg 短い名前.jpg 短い名前.jpg 短い名前.jpg
    Content-Dis inline 長い名前.jpg 長い名前.jpg 短い名前.jpg 短い名前.jpg 短い名前.jpg

     

    IE6の環境はXP SP2です。IE7はXP SP3です。IE8はXP SP3とWin7の２環境確認です。
    いずれの環境もNTFSフォーマットかつ8.3形式は有効(disable8dot3 = 0)です。
     
    特に書いてはいませんが、no-cache指定やレアなタイミングによっては、いずれの操作も無題.bmp(png)になる可能性があるという認識です。
     
    これを見ると、IE7→IE8時の長い名前→短い名前の変化の理由が気になりました。
    IEのバージョンとは無関係である可能性もあります。(同じXPかつSPかつNTFS Ver3.1ですが）
    理由をご存知な方がいらっしゃいましたら、ご教授お願いいたします。

     
    Itô_Hirobumiのほうはどうでしょう？
    前回投稿の環境で確認した所、Itô_Hirobumiは、Ito_Hirobumiになりました（ôがU+00F4→U+006Fに変化)。
    確認時のContent-Dispositionヘッダには次のように指定しました。
    inline; filename*=utf-8''It%C3%B4_Hirobumi.jpg
     
    どうも色々なところで文字の正規化処理が走っているように思えました。
    unicode.orgにある、bestFitの表は影響していませんかね？readmeに色々書いてありました。
    http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/
     
    OEM側のbestFit処理？は、WDKのfastfatサンプルのFatConstructNamesInFcb関数のコメントもそれに近いと思っています。
    （RtlUpcaseUnicodeStringToCountedOemStringをどう使っているかの参考例としても私には分からなかったため何か分かりましたらよろしくです。）
    2012年4月2日 15:59
    |
  • Question
    サインインして投票
    0
    サインインして投票

    IE7→IE8では、URLエンコード.jpgをデコード.jpgに変えようとしたんでしょうね。index.datのあればcontent-dispositionのfilenameなければurlを見ていたのを手っ取り早くindex.datのファイル名を見るように変えたんでしょう。それが短いファイル名になるとは知らずに。たぶん、content-dispositionのfilenameの仕様も知らず、仕様を変更したという認識もないのでしょう。ie10cpでバグレポしては？


    2012年4月3日 17:52
    |
  • Question
    サインインして投票
    0
    サインインして投票

    Content-Disposition: inline; filename=はどうやって確認してます？
    やっと見つけた、Content-Disposition: attachment; filename=の

    http://oku.edu.mie-u.ac.jp/~okumura/php/fakefile.php/日本語ファイル名.txt

    を見ると、index.datのファイル名は短い名前になってますね。キャッシュのファイル名は日本語ファイル名[1].txt

    2012年4月4日 14:12
    |
  • Question
    サインインして投票
    0
    サインインして投票

    レポっておきました。短い名前の仕様を見てもおかしいかなと。英語圏以外で盛り上げないと。みなさまもぜひ！
     

    Content-Disposition: inline; filename=はどうやって確認してます？
    picasaのウェブアルバムがそうですね。
    マイフォトからアルバムを選択したときの画像の一覧時の応答や、対象画像を選択した際の応答でも使われています。
    次のように返却されることを確認しました。
    Content-Disposition: inline;filename="%E5%AE%87%E9%83%BD%E5%AE%AE%E9%A4%83%E5%AD%90%E5%83%8F.jpg" 

    picasaに限らず”認証付の画像アルバムサービス”が最もありえそうだと思っています。
    （逆にそれ以外は難しいかもです。通常、ヘッダを付与するには作りこむ必要があるためです。）
    どのサイトがContent-Disposition: inline指定を返却しうるかを探す際ものとして、fiddlerの検索機能が使いやすいと思いました。
    ※skydriveは、右クリックメニューはブラウザ標準ではなく、最適化された独自メニューが表示されるため、問題ありません(!)。

    2012年4月4日 16:22
    |
  • Question
    サインインして投票
    0
    サインインして投票
    Content-Disposition: inline; filename=はあまり使われてないようですね。ieはそれをサポートするのをやめたってことではないですかね。めんどくさいから。
    2012年4月8日 9:03
    |
  • Question
    サインインして投票
    0
    サインインして投票

    工数みあいの部分はあるでしょうね。一応RFC 6266にはあるようです。
    以下がかなりまとまっているようです(inlineにフォーカスを当てているわけではないですが）。

    Test Cases for HTTP Content-Disposition header field (RFC 6266) and the Encodings defined in RFCs 2047, 2231 and 5987
    http://greenbytes.de/tech/tc2231/
    EricLaw's IEInternals - Downloads and International Filenames
    http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

    どのブラウザも商業レベルでは使いにくいので使わなかったという負のスパイラル説も？
    inline指定も、やれば出来る子（？）だと思っております。(MetroモードやdataURIの話もありそうですが)


    キャッシュが残る問題に話を戻しますと、
    リンク切れのフォルダが71個出来ていることを確認しました。(一番古いフォルダは、2011/06/27)
    されていなければ、レポートされてみては？(IE10は再現しないようですが）
    以下の画像はWin7SP1&IE9です。

    また、インターネット一時キャッシュを覗くと、以下のサイト内のlowpoer.gifが残っていました。何度やっても残るようです。
    文字コードは、あまり関係しないかもです。
    リンク切れのファイル名の規則は確かに良く分かりませんね。（・・・リンク先の内容に見覚えもないのですが）
    http://jp.fujitsu.com/microelectronics/technical/lowpower/

    2012年4月8日 14:52
    |