パスワードを忘れた? アカウント作成
283522 story
インターネット

12月15日付けWindowsUpdate後、IEで文字化け多発中な模様 96

ストーリー by kazekiri
一斉チェック 部門より

Anonymous Coward 曰く、

12月15日付けのWindowsUpdateの後、様々なサイトで文字化けが起こる現象が発生している模様です。私が調べた限りでは、ページエンコードとして、ISO_2022_JPが指定されているページが文字化けします。これは、今回の更新でJISエンコーディングの自動検出を無効にする修正が行われた為です。また、charsetが無指定なサイトも文字化けを起こしています。

Togetterにもまとめられているので参考まで。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ISO_2022_JP ではなくて、ISO-2022-JP なんだが、メールやウェブではそれでも通っているのかなぁ?

    ややこしいことに Shift-JIS ではなく Shift_JIS だったりするが。

    参考サイト [iana.org]

  • KB2467659 (スコア:3, 参考になる)

    by Anonymous Coward on 2010年12月19日 11時15分 (#1876311)

    KB2467659を適用しても、純正のIEでは文字化けしたままです。これはあくまで

    一部のソフトウェアでは、Internet Explorer のコンポーネントを使用して、HTML 形式の日本語の電子メール メッセージを解釈します。そのため、JIS エンコーディングは自動検出されず、電子メール メッセージのコンテンツは読み取ることのできないコードで表示されます。

    という問題(IEコンポを使用している他アプリの文字化け)を回避するためのレジストリ設定を行う修正プログラムだからです。
    手動設定の手順のうち「iexplore.exe」という名前で値「1」を作るところを「0」にすれば文字化けは回避できますが、当然セキュリティホールも復活するのでおすすめはできません。

  • マイクロソフト セキュリティ情報 MS10-090 - 緊急
    http://www.microsoft.com/japan/technet/security/bulletin/ms10-090.mspx [microsoft.com]

    定番ですが、脆弱性の詳細についておよび修正プログラムの情報があります。

    MS10-090 導入後の不具合につきまして
    http://blogs.msdn.com/b/ie_jp/archive/2010/12/17/ms10-090.aspx [msdn.com]

    マイクロソフト IE チームのブログ情報です。

    MS10-090 導入後の不具合
    http://snow-white.cocolog-nifty.com/first/2010/12/ms10-090-cad5.html [cocolog-nifty.com]

    実際に症状が確認できる ISO-2022-JP エンコードの Web ページです。
    修正適用済み IE8 で表示すると "シフト JIS" として認識する様が確認できます。
    Chrome では ISO-2022-JP として認識し、文字化けしませんね。

    IE修正パッチによる文字化け回避にF5を押すのは非常に危険
    http://blog.livedoor.jp/blackwingcat/archives/1310605.html [livedoor.jp]

    リロードは脆弱性を顕在化させるとのこと。
    一般ユーザーへリロードを推奨するのはやめた方がよさそうです。

  • by vn (10720) on 2010年12月19日 11時18分 (#1876313) 日記
    Sukoya 氏の日記 [srad.jp]に取り上げられていたので、ちょっとコメントした。ご参考までに。
  • by Anonymous Coward on 2010年12月19日 15時35分 (#1876419)
    IEでそれ以外のサイトを見に行くことはないしw

    という人が俺以外に3人ぐらいいそうな気がする。
    • by gonzo (38147) on 2010年12月20日 9時39分 (#1876790)

      たしかに、Windows(Microsoft) Update以外ではほとんどIEを使わない。

      ただ、仕事ではwebベースの社内システムもIEを使っている。
      Google ChromeやFire Fox, Operaでも動くらしいが微妙にバランスが崩れて使いにくいのでIE。
      ショートカットはIE+URLに変更して使っている。

      親コメント
  • by reininn (35924) on 2010年12月19日 16時28分 (#1876439)
    Charset なんて、全く何処にも書いていない。 [namazu.org]
    これだけ徹底すると芸術だ!
    Charset を書き忘れたなんだって言うやつ「ちゃっちいぜ」
  • Safariなんか (スコア:1, 参考になる)

    by Anonymous Coward on 2010年12月19日 11時01分 (#1876307)
    Safariなんかは昔からしばしば文字化けが起きるサイトがあって、
    手動でメニューから文字コード切り替えないといけなかったりすることがあるけど、
    POSTのリロードになって、ちゃんと動かなくなるサイトとか、稀にあるね。
    • Re:Safariなんか (スコア:2, 参考になる)

      by OrganLounge (35399) on 2010年12月20日 1時47分 (#1876714) 日記

      以下をターミナルから実行すると文字化けが起きないかもしれません
      defaults write com.apple.Safari WebKitUsesEncodingDetector -bool yes

      親コメント
  • by urandom (26447) on 2010年12月19日 12時13分 (#1876330)
    ISO_2022_JP は論外だが、基本的にコンテンツに合ったHTTP応答ヘッダーのContent-Typeフィールドのcharsetを指定していないのがいけない。HTTP 1.1辺りではcharsetパラメータはtext/htmlとかに必須でなかったかな?

    * 今までいい加減に済ませていたHTTP応答ヘッダーのツケが出てきた。
    * 今まで勝手に中身を判断する悪しき挙動に身を染めていたIEがまっとうになろうとして失敗した。

    と、いうあたりだろうな。
    • 要するに、Apacheの場合
      こんなのを適当な場所に書いとけば良いのですね。
      親コメント
    • by urandom (26447) on 2010年12月19日 12時16分 (#1876331)
      自己フォロー。

      もっとも、jpnicやjprsのサイトでさえ、きっちりとしたHTTP応答ヘッダーにcharset付けてないので絶望的とも言えるな。
      親コメント
    • by T.Sawamoto (4142) on 2010年12月20日 16時16分 (#1877000)

      ちょっと調べてみたんですが、今回のトラブルはXHTMLでXML宣言にencodingを明示していても文字化けが起きますね。

      W3CのXHTML 1.0(Second Edition) / C.9. Character Encoding [w3.org]だと、

      In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers. If this is not possible, a document that wants to set its character encoding explicitly must include both the XML declaration an encoding declaration and a meta http-equiv statement.

      とありますから、HTTPヘッダでcharsetが明示されないとき、XML宣言とmeta http-equivの両方でISO-2022-JPを指定してあっても文字化けするのは、IEの不具合じゃないかな、と。

      親コメント
  • <META HTTP-EQUIV=Content-Type CONTENT="text/html; charset=ISO-2022-JP"> と記述したhtmlファイルを D&D あるいは ファイルメニューから選択しても文字化けします。

    # ファイル数考えると頭が痛いです……
    --
    notice : I ignore an anonymous contribution.
  • by Anonymous Coward on 2010年12月19日 11時25分 (#1876316)
    これだけGeckoやWebKitが普及していても平気でテキストエンコーディングの指定を間違えているサイトが多くて困ります。
    少なく見積もっても4分の1くらいはIE以外のブラウザだと思うんですけどねえ。

    はっ!もしやIEを使わせる為の罠なのか!
    • Re:確認不足 (スコア:1, 興味深い)

      by Anonymous Coward on 2010年12月19日 11時39分 (#1876319)

      真に悲惨なのはiOSのSafariです。PCのブラウザだと自分でテキストエンコーディングを指定し直せば読めますが、iOSは他に類を見ないような頭の悪い自動認識しかありません。読めないページはPCから見るかGWTを通すくらいしか方法がありません。

      親コメント
      • Re:確認不足 (スコア:3, すばらしい洞察)

        by Anonymous Coward on 2010年12月19日 11時55分 (#1876323)
        サイトの問題を指摘しているのにブラウザが悪いって話にすり替えるのやめて。
        親コメント
        • Re:確認不足 (スコア:2, すばらしい洞察)

          by Anonymous Coward on 2010年12月19日 12時33分 (#1876339)
          違う違う。
          エンコーディング指定を間違っているのはサイトが「悪い」。
          それを表示できないブラウザはそういう設計方針なんだから悪くはない。けど「嫌い」。
          親コメント
        • by sumeshi0206 (12305) on 2010年12月20日 18時15分 (#1877041) 日記

          ブラウザが悪い。
          IEが出来の悪いサイトも勝手に判断してそれなりに表示してしまうおかげで
          サイトを作ったほうはそれでOKだと思ってクソなサイトが増えてしまったんだと思う。

          MSはおせっかい機能が多いね。
          例えば.NETも必ずDisposeすると書いてる割に、
          Disposeしなくてもしばらーく問題出ないからリリース後におかしな挙動するようになって
          初めて慌てふためくってことがあった。
          勿論きちんとDiposeする人も居るし後から入った自分はUsing使って書こうと言い出したけど、全て対応でたわけではなかった。
          Javaだとcloseしてないとエラーになるからわかるんだよね。Stringの「+=」も同じ。

          親コメント
    • by Anonymous Coward

      いや、Webkitは細かいところはスピードのために犠牲にされてるんだろ。
      というか、そもそもJISのサイトって誰特なん?

      • by sakamoto (8009) on 2010年12月19日 18時14分 (#1876507) 日記
        1997年以前は、国際的に利用可能な漢字コードがISO-2022系しか無くて、HTML2.Xとか使うんでもそれしかなかったんだけど。 XHTMLができた今では、もうデフォルトはUTF-8だから用済みだね。
        --
        -- 哀れな日本人専用(sorry Japanese only) --
        親コメント
      • by Anonymous Coward
        JTのWebサイトがJISで、IEだとしっかり文字化けしました。しかもIEってJISを明示的に指定できない謎仕様でテキストが見られず難儀です…
        ' 当分はFirefoxで見るからいいですけれど
  • by Anonymous Coward on 2010年12月19日 12時08分 (#1876328)

    "美乳" とか知らん Web 屋がいたのにはびっくり。
    って、ジェネレーションギャップなのかしらん。

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...