12月15日付けWindowsUpdate後、IEで文字化け多発中な模様 96
ストーリー by kazekiri
一斉チェック 部門より
一斉チェック 部門より
Anonymous Coward 曰く、
12月15日付けのWindowsUpdateの後、様々なサイトで文字化けが起こる現象が発生している模様です。私が調べた限りでは、ページエンコードとして、ISO_2022_JPが指定されているページが文字化けします。これは、今回の更新でJISエンコーディングの自動検出を無効にする修正が行われた為です。また、charsetが無指定なサイトも文字化けを起こしています。
Togetterにもまとめられているので参考まで。
アンダスコアでなくハイフン（オフトピ） (スコア:5, 参考になる)
ISO_2022_JP ではなくて、ISO-2022-JP なんだが、メールやウェブではそれでも通っているのかなぁ？
ややこしいことに Shift-JIS ではなく Shift_JIS だったりするが。
参考サイト [iana.org]
KB2467659 (スコア:3, 参考になる)
KB2467659を適用しても、純正のIEでは文字化けしたままです。これはあくまで
という問題(IEコンポを使用している他アプリの文字化け)を回避するためのレジストリ設定を行う修正プログラムだからです。
手動設定の手順のうち「iexplore.exe」という名前で値「1」を作るところを「0」にすれば文字化けは回避できますが、当然セキュリティホールも復活するのでおすすめはできません。
情報ソースへのリンクがなかったように見えたので、ここにまとめておきますね。 (スコア:3, 参考になる)
マイクロソフト セキュリティ情報 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]
リロードは脆弱性を顕在化させるとのこと。
一般ユーザーへリロードを推奨するのはやめた方がよさそうです。
Re:情報ソースへのリンクがなかったように見えたので、ここにまとめておきますね。 (スコア:1)
肝心の不具合修正モジュールを書くのを忘れていました。
Internet Explorer 用の更新プログラムについて (2010 年 12 月 14 日)
http://support.microsoft.com/?kbid=2467659 [microsoft.com]
Re: ゲイツブラウザの悪夢 (スコア:2, 興味深い)
Re: ゲイツブラウザの悪夢 (スコア:1)
非常に参考になりました
……なったのはいいんでありますが、こんな年末年始に一体どうすればよいのか判らないと言うorz
WindowsUpdateのサイトが文字化けしなきゃ問題なし (スコア:2, すばらしい洞察)
という人が俺以外に３人ぐらいいそうな気がする。
まずひとり (スコア:2)
たしかに、Windows(Microsoft) Update以外ではほとんどIEを使わない。
ただ、仕事ではwebベースの社内システムもIEを使っている。
Google ChromeやFire Fox, Operaでも動くらしいが微妙にバランスが崩れて使いにくいのでIE。
ショートカットはIE+URLに変更して使っている。
www.namazu.orgは、凄い！ (スコア:2)
これだけ徹底すると芸術だ！
Charset を書き忘れたなんだって言うやつ「ちゃっちいぜ」
Safariなんか (スコア:1, 参考になる)
手動でメニューから文字コード切り替えないといけなかったりすることがあるけど、
POSTのリロードになって、ちゃんと動かなくなるサイトとか、稀にあるね。
Re:Safariなんか (スコア:2, 参考になる)
以下をターミナルから実行すると文字化けが起きないかもしれません
defaults write com.apple.Safari WebKitUsesEncodingDetector -bool yes
Re:Safariなんか (スコア:2, 参考になる)
IEにもないよ。自動選択でたいていは選ばれる(選ばれてた)ってだけ。
そのIEも自動選択を廃止した以上サイト管理者に文句を言うしかないね。今までIEの甘い判定に甘えてただけなんだし。
Re:Safariなんか (スコア:1)
>Safariのテキストエンコーディングの選択肢から「日本語 (ISO-2022-JP)」が無くなっている件について。
ありますよ。
Safari 5.0.3 for Macで確認。
Re:Safariなんか (スコア:1, 参考になる)
Windows版にはないんですよ。
でもWindows版ではmlangのサポートしているテキストエンコーディングをそのまま使っているだけなので、IEが対応していないというブーメラン的な何か。
HTTP応答ヘッダー (スコア:1)
* 今までいい加減に済ませていたHTTP応答ヘッダーのツケが出てきた。
* 今まで勝手に中身を判断する悪しき挙動に身を染めていたIEがまっとうになろうとして失敗した。
と、いうあたりだろうな。
AddType "text/html; charset=iso-2022-jp" .html (スコア:2)
こんなのを適当な場所に書いとけば良いのですね。
Re:HTTP応答ヘッダー (スコア:1)
もっとも、jpnicやjprsのサイトでさえ、きっちりとしたHTTP応答ヘッダーにcharset付けてないので絶望的とも言えるな。
Re:HTTP応答ヘッダー (スコア:1)
もちろん、わざわざ文字エンコーディングと一致してないcharsetを<meta>で指定するのはよろしうない。
Re:HTTP応答ヘッダー (スコア:1)
html自体をどう読むかを示すcharset指定を、htmlの中で行うってのもおかしな話だよね。
幸いにして、大体の文字コードはASCII互換、非互換のものでもASCIIで読んだら間違ったmetaタグに解釈されるってことは現実的にはないので、それでうまくいってるようだけど。
1を聞いて0を知れ!
IEでUTF-8が表示できない例 (スコア:1)
最近、自サイトでの出来事。
↑charset指定より上に日本語があると、真っ白なページになってしまう。IE限定。
↓の様に修正すると解決。
昨日まで知らなかった。これは有名（というか当然）な現象なのでしょうか？
IEだけが表示できなくて、それ以外のブラウザでは問題なしで、いままでIEがバカなんだとばかり思っていました。
Re:IEでUTF-8が表示できない例 (スコア:1)
エンコーディングを指定する部分を該当エンコーディングに依存する (非 ASCII となる) 部分より先に書いたら符号方式が未確定であるため自動判定となり、本来の目的である http-equiv (HTTP 応答ヘッダーの補完) の意味を為していないこととなります、記述順序的にはメタ情報として http-equiv を記述する場合は head 要素の先頭に配置し、そこまでの部分では ASCII の範囲内で記述する、というのが基本です。
今まではたまたま判定に成功していた、というだけでしょう。
余談ながら、head 要素の profile 属性に URI を指定することができますが、こうした場合に IDN をそのまま記述すると残念な事となるため、ASCII の範囲で記述しようとすると punycode で記述する事となります。
このため、ローカルシステム上で確認する場合ではしょうがないですが、できれば Web サーバー側から適切な応答を出させた方が記述上も楽でしょうね。
profile が指定されている head 要素なんてまず存在しないというのはありますが、先日 Google が提唱していた引用元明示のためのメタ情報拡張 [google.com]などは、HTML の仕様上はこれを指定するものだったりします。
Re:HTTP応答ヘッダー (スコア:1)
ちょっと調べてみたんですが、今回のトラブルはXHTMLでXML宣言にencodingを明示していても文字化けが起きますね。
W3CのXHTML 1.0(Second Edition) / C.9. Character Encoding [w3.org]だと、
とありますから、HTTPヘッダでcharsetが明示されないとき、XML宣言とmeta http-equivの両方でISO-2022-JPを指定してあっても文字化けするのは、IEの不具合じゃないかな、と。
Re:HTTP応答ヘッダー (スコア:2)
しかし一方でHTML4.01のSpecifying the character encoding [w3.org]ではこう書かれています。
つまり、charsetが省略されていた場合は、ユーザエージェントはデフォルト値を仮定してはならない(MUST NOT。HTML 4.01ではMUST NOT等は小文字で表記すると規定されている)としています。
ローカルでD&Dしても化けます。 (スコア:1)
# ファイル数考えると頭が痛いです……
notice : I ignore an anonymous contribution.
Re:ローカルでD&Dしても化けます。 (スコア:1)
Re:ローカルでD&Dしても化けます。 (スコア:1)
もしかして，そのmetaタグの前にtitleタグが入っていないでしょうか？
IEのみその状態の時にmetaタグ無視して自動判定して文字化けするということがよくあります．
Re:ローカルでD&Dしても化けます。 (スコア:1)
先頭部分は以下の通り。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML LANG=ja>
<HEAD>
<meta http-equiv="Content-Script-Type" content="text/javascript">
<meta http-equiv="content-style-type" content="text/css">
<META HTTP-EQUIV=Content-Type CONTENT="text/html; charset=ISO-2022-JP">
適当なISO-2022-JPのhtmlファイルを皆様の手元のIEに喰わせた方が早いと思います。（2台のXP機で発生する事を確認しています）
ローカルファイルのcharsetを無視するのは非常に迷惑です……
notice : I ignore an anonymous contribution.
Re:ローカルでD&Dしても化けます。 (スコア:2)
> w3cは内のタグ内の定義はhttp serverが解釈して適切なresponse headerを送出すると定義してる。
HTML 4.01 では、
となっています。(→ http://www.w3.org/TR/html4/struct/global.html#edef-META [w3.org])
"may" なので、サーバが HTTP レスポンスを作るときに使ってもよいとは書かれていますが、解釈しなくてはならないとは書いてないようです。
Re:ローカルでD&Dしても化けます。 (スコア:2)
Conformance: requirements and recommendations [w3.org]
確認不足 (スコア:0)
少なく見積もっても4分の1くらいはIE以外のブラウザだと思うんですけどねえ。
はっ！もしやIEを使わせる為の罠なのか！
Re:確認不足 (スコア:1, 興味深い)
真に悲惨なのはiOSのSafariです。PCのブラウザだと自分でテキストエンコーディングを指定し直せば読めますが、iOSは他に類を見ないような頭の悪い自動認識しかありません。読めないページはPCから見るかGWTを通すくらいしか方法がありません。
Re:確認不足 (スコア:3, すばらしい洞察)
Re:確認不足 (スコア:2, すばらしい洞察)
エンコーディング指定を間違っているのはサイトが「悪い」。
それを表示できないブラウザはそういう設計方針なんだから悪くはない。けど「嫌い」。
Re:確認不足 (スコア:2)
ブラウザが悪い。
IEが出来の悪いサイトも勝手に判断してそれなりに表示してしまうおかげで
サイトを作ったほうはそれでOKだと思ってクソなサイトが増えてしまったんだと思う。
MSはおせっかい機能が多いね。
例えば.NETも必ずDisposeすると書いてる割に、
Disposeしなくてもしばらーく問題出ないからリリース後におかしな挙動するようになって
初めて慌てふためくってことがあった。
勿論きちんとDiposeする人も居るし後から入った自分はUsing使って書こうと言い出したけど、全て対応でたわけではなかった。
Javaだとcloseしてないとエラーになるからわかるんだよね。Stringの「+=」も同じ。
Re:確認不足 (スコア:1, すばらしい洞察)
文字エンコーディングの指定が間違っていても正しく表示するとか、
タグが閉じられてなくても意図を見抜いて適切に表示するとか。
Re:確認不足 (スコア:1)
見られないサイトは切り捨てられるんでありますよ……
Re:確認不足 (スコア:1)
まあ百も承知で釈迦に説法だとは思いますが、モノによるんじゃないですかね？
どうしても見たいサイトだとしたら「表示できないブラウザが悪い」。一方ではわざわざ見に来てやったのに表示できない「サイトが悪い」。
「他のブラウザでは表示できるのになんで？」と思うか「他のサイトなら表示できるのになんで？」と思うかの違いですよね。
#私は困ってませんが、この件では、サイトでうまく対応できない状況もあるだろうから、ブラウザさん、本業でもないし仕様でもないですけど、お怒りを鎮めてなにとぞ自動判別を賜っていただければ恐悦至極に存じますといったスタンス。
LIVE-GON(リベゴン)
Re:確認不足 (スコア:1)
ただ、自動認識とかでセキュリティの問題って稀によくあるので、兼ね合いが大変そうですよね...
今回の修正自体もそれに関係するのかもですし
KB2416400 - MS10-090
https://www.microsoft.com/technet/security/bulletin/MS10-090.mspx [microsoft.com]
http://support.microsoft.com/?kbid=2416400 [microsoft.com]
かな...うーん詳細がわからない(主に頭の悪さから)
# べつにブラウザは怒ってないと思う、標準規格に沿う方向に舵を切ってるから、変にフォローアップする機能を落すのには躊躇はなくなるとは思うが...
M-FalconSky (暑いか寒い)
Re:確認不足 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:確認不足（オフトピ） (スコア:1)
というサイト側の押し付けで別ウィンドウで開かれるのがウザくて、ユーザー側がリンクを開くときにいつも新しいタブで開くようになるのですよね。
特に指定されていなければ、ユーザーはただのリンクを新しいウィンドウで開くのか、新しいタブで開くのか、それともそのまま遷移するのかを選択できますが、リンクターゲットが指定されている場合、ユーザーがそのまま遷移するという選択肢が消されます。
この手の「余計なお世話」に関しては、スクリーンリーダー系などを用意して説明したりすると上司も納得するかもしれません。
Re:確認不足（オフトピ） (スコア:1)
選択肢が消されるかどうかはブラウザ次第ですよね。Operaでは左クリックでは target 属性に従いますが、右クリックのメニューでは「開く」ならそのまま遷移、「新しいタブで開く」ならもちろんその通りで、target 属性を無視してユーザの意思で選択できます。
LIVE-GON(リベゴン)
Re: (スコア:0)
いや、Webkitは細かいところはスピードのために犠牲にされてるんだろ。
というか、そもそもJISのサイトって誰特なん?
Re:確認不足 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re: (スコア:0)
' 当分はFirefoxで見るからいいですけれど
Re:確認不足 (スコア:1, 参考になる)
IEは、意図した仕様なのかもしれません。
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4868 [mozilla.gr.jp]
この手のネタで (スコア:0)
"美乳" とか知らん Web 屋がいたのにはびっくり。
って、ジェネレーションギャップなのかしらん。
Re:TBSのサイトが化ける (スコア:2)
# 駄目ダメ。
だから、それが原因じゃないってば！ (スコア:3, 参考になる)
AddType "text/html; charset=iso-2022-jp" .html .htm
みたいな設定を Apache にしてないからです。
Re:マイクロソフトのパッチはちゃんと検証されてない (スコア:1)
SUNのパッチもHPのパッチもIBMのパッチやMacのアップデートも、
たまにwithdrawやobsoletedや枝版ですぐに刷新とか結構あるわけですが...
>動作が完全に検証されていない
製品じたい、動作が完全に検証されているなら、パッチなんかいらないのでは？
もっとましな製品になっているよね。
あるパッチが完全に検証できるというのも、無理な話だろ？
Re:互換表示 (スコア:1)
UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意 - スラッシュドット・ジャパン [srad.jp]
この問題はUTF-7固有の問題ではない。たとえばISO-2022-JPでも同様のことが起こり得る。ユーザが意図してメニューから文字エンコーディングを変更すると、それによってXSS攻撃が発動することがある。訪れたサイトで文字化けが起きているからといって、不用意にエンコーディングを変更してはいけない。「文字エンコーディングを変更してください」などと要求するページに騙されないよう注意が必要だ。"
なんか、既視感が|･ω･)