アカウント名:
パスワード:
＜meta＞で入ってればだいたいOKですね。たまにヘッダの記載と現物が違ってるとかいう行儀悪いサイトもありますけどそれは論外。
こんな文字化けは今まで他ブラウザでも散見されてきたものです。IEの自動判別は比較的優秀な方だったというのもあります。とにもかくにもサイト側がしっかりしてくれないことには始まらないですよね。MSもよく化けるぞコンチキショーの文句はサイト側に言ってくださいと宣言しちゃえばいいんですが。
最近、自サイトでの出来事。
<head><title>日本語タイトル</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
↑charset指定より上に日本語があると、真っ白なページになってしまう。IE限定。
↓の様に修正すると解決。
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>日本語タイトル</title>
昨日まで知らなかった。これは有名（というか当然）な現象なのでしょうか？IEだけが表示できなくて、それ以外のブラウザでは問題なしで、いままでIEがバカなんだとばかり思っていました。
エンコーディングを指定する部分を該当エンコーディングに依存する (非 ASCII となる) 部分より先に書いたら符号方式が未確定であるため自動判定となり、本来の目的である http-equiv (HTTP 応答ヘッダーの補完) の意味を為していないこととなります、記述順序的にはメタ情報として http-equiv を記述する場合は head 要素の先頭に配置し、そこまでの部分では ASCII の範囲内で記述する、というのが基本です。 今まではたまたま判定に成功していた、というだけでしょう。
余談ながら、head 要素の profile 属性に URI を指定することができますが、こうした場合に IDN をそのまま記述すると残念な事となるため、ASCII の範囲で記述しようとすると punycode で記述する事となります。 このため、ローカルシステム上で確認する場合ではしょうがないですが、できれば Web サーバー側から適切な応答を出させた方が記述上も楽でしょうね。
profile が指定されている head 要素なんてまず存在しないというのはありますが、先日 Google が提唱していた引用元明示のためのメタ情報拡張 [google.com]などは、HTML の仕様上はこれを指定するものだったりします。
判別に失敗するのはともかく、真っ白になるのは「ル」の3バイト目と「<」をシフトJISの1文字とみなして、HTMLの末尾まで終了タグが見つからないと解釈してしまうから。これはうまく使うとXSSになるはずだけど、欧米人にはあまり関係ないせいか(判別を誤ってもデフォルトが1バイトエンコーディングなら真っ白にはならない)ずーっと放置されてる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
HTTP応答ヘッダー (スコア:1)
* 今までいい加減に済ませていたHTTP応答ヘッダーのツケが出てきた。
* 今まで勝手に中身を判断する悪しき挙動に身を染めていたIEがまっとうになろうとして失敗した。
と、いうあたりだろうな。
Re: (スコア:1)
もっとも、jpnicやjprsのサイトでさえ、きっちりとしたHTTP応答ヘッダーにcharset付けてないので絶望的とも言えるな。
Re: (スコア:0)
＜meta＞で入ってればだいたいOKですね。
たまにヘッダの記載と現物が違ってるとかいう行儀悪いサイトもありますけどそれは論外。
こんな文字化けは今まで他ブラウザでも散見されてきたものです。IEの自動判別は比較的優秀な方だったというのもあります。
とにもかくにもサイト側がしっかりしてくれないことには始まらないですよね。MSもよく化けるぞコンチキショーの文句はサイト側に言ってくださいと宣言しちゃえばいいんですが。
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: (スコア:0)
判別に失敗するのはともかく、真っ白になるのは「ル」の3バイト目と「<」をシフトJISの1文字とみなして、HTMLの末尾まで終了タグが見つからないと解釈してしまうから。
これはうまく使うとXSSになるはずだけど、欧米人にはあまり関係ないせいか(判別を誤ってもデフォルトが1バイトエンコーディングなら真っ白にはならない)ずーっと放置されてる。
Re: (スコア:0)
最近のブラウザが優秀だったのでしょうね。