日本語エンコーディングの種類と、エンコーディング宣言の割合
Masataka Yakura
- CJK圏で使われているエンコーディングの種類で多いのはどれか？
- エンコーディング宣言（<meta>やらHTTPヘッダやら）をしてる割合はどんなものか。
- UTF-8は年々増えてるけど、Shift_JISもけっこうあるので、全体だとまだShift_JISが多いのではないか
- EUC-JPもシステム系（？）が絡むようなところでは使われているように思う
- ISO-2022-JPはメール以外でほとんど見ない
Koji Ishii
こんばんは、石井です。データを持っているわけではないので申し訳ないですが…
一つは、i18n WGが作っているページでこういうのがあります。
http://www.w3.org/International/questions/qa-html-encoding-declarations
Mozillaの方ならご存知かもしれませんが、XML declarationなども見た方がいいかも知れません。
もう一つ、携帯サイトだと、古い機種の対応やバイト数を減らすため、Shift-JISがまだかなり多いのではないかと思います。このページ
http://www.mobimani.com/start_06.html
などではShift-JISで記述し、metaを消して、XML declarationを入れましょう、と推奨しているようです。XMLHttpRequestで携帯サイトの情報を取る必要があるか、というとそこには少し疑問が残りますが、ご参考まで。
あと思いつきですが、setRequestHeaderでcharsetを指定していたら、それを使ってくれると、最後の回避策になるかもしれません。POST時には指定せざるを得ないでしょうし。
--
このメールは Google グループのグループ「html5j.org」の登録者に送られています。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msg/html5-developers-jp/-/4LYU1j-aFXgJ にアクセスしてください。
このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。
NARUSE, Yui
ちょうどわたしも同じ問題に関心を持っていました。
2011年12月8日2:45 Masataka Yakura <myaku...@gmail.com>:
> ちょっとMozillaのエンジニアの方からこういう質問をうけました。
>
> CJK圏で使われているエンコーディングの種類で多いのはどれか？
> エンコーディング宣言（<meta>やらHTTPヘッダやら）をしてる割合はどんなものか。
>
> CJK圏とまとめられると答えにくいので、とりあえず日本語のページについては、ここ数年大きなサイトを見てる中での推測として
>
> UTF-8は年々増えてるけど、Shift_JISもけっこうあるので、全体だとまだShift_JISが多いのではないか
そうだと思います。
HTML5 を解説しているサイトが Shift_JIS で書かれていて、しかもエンコーディング宣言がないという、
とてもシュールな例も見つけています。
> EUC-JPもシステム系（？）が絡むようなところでは使われているように思う
あと Unix 文化圏の延長や、CGI/Perl 文化の影響下にあるところがそうですね。
具体的には Unix 系プログラムの解説やマニュアルの和訳。
大物でははてなダイアリーが EUC-JP ですし、ブログ文化輸入前の日記系はスクリプトは
だいたい EUC-JP じゃないかと思います。。
> ISO-2022-JPはメール以外でほとんど見ない
確かに数としては UTF-8, Shift_JIS, EUC-JP に比べるとだいぶ少なくなるのですが、
意識して見ていると意外とあります。
> また、エンコーディング宣言については、設定しないと文字化けすることがほとんどだから、してないサイトの方を見つけるほうが難しいという旨をとりあえず返しました。
設定していないサイトは結構あります。
HTML5 Parser （詳細は後述） を実装しているブラウザ、具体的には Chrome や Safari を使っていると、
IE や Firefox を使っている時よりも文字化けに遭遇しやすいと思うのですが、そういったときに化けるのは
宣言のないサイトです。で、そういうサイトも IE や Firefox だと化けなかったりします。
> いちおういろんな大手企業や大学のトップページを数十サイト見てみたのですが、UTF-8とShift_JISが同じくらい（少しだけShift_JISが多いかも）という中、ちょろちょろとEUC-JPという感じでした。
>
> で、事の詳細は、今XMLHttpRequestからHTMLをパースする仕組みがGeckoに実装されたことにあります。
> https://developer.mozilla.org/en/HTML_in_XMLHttpRequest
>
> ロードした文書のエンコーディングを検出するところで、その検出法でエンコーディングが気になっているようです。
>
>
> というのは、ブラウザはかなり複雑なエンコーディング検出処理を実装しているらしく、「前のページのエンコーディング情報」を元にしたり、「あたりをつけて間違ってたらリロード」とかそういう、泥臭い感じの実装も入っているようなのです。
中のコンテンツを見て、化けない文字コードにするという仕組みも入っています。
それを利用した「美乳」っていうバッドノウハウが使われた時代もありました。
http://www.shtml.jp/mojibake/binew.html
> ただ、XHRで読み込むページではそういった細かいルールはしたくないということで、「明示的に<meta>で指定されているか、HTTPヘッダで指定されている場合はそれを、どちらでも指定されていなければUTF-8に」というルールになっているようなのですが、これで問題は出ないだろうかというのが彼の質問でした。
HTTP におけるデフォルトの charset は ISO-8859-1 なので、どちらも指定されていなければ UTF-8 というのは
規格違反ではないでしょうか。
デフォルトを UTF-8 にしようという提案自体はあって、今 HTML5 の ML で議論にはなっていますが。
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033995.html
> エンコーディング宣言がされてないページは少なくとも日本のページでは少ないだろうから、上記のルールでも問題ないんじゃないかなあと返したのですが、いかがでしょうか。
> ちょっとちゃんとしたデータがあるとか、いま自分が書いた感覚が誤ってたらツッコミいただけたらと思います。
ダメだと思います。
具体的にはまだ5サイトしか集めていませんが以下の通り。
http://b.hatena.ne.jp/nurse/mojibake/
あまりに多いので一々登録していませんが、Unix 系のマニュアルを HTML として出力するツールが charset を吐いてくれないらしく、
それを用いたマニュアルを探すとエンコーディング宣言のないページはたくさん見つかります。
--
NARUSE, Yui <nar...@airemix.jp>
Shumpei Shiraishi
ブラウザで設定可能な、デフォルトエンコーディングの話って出ましたか？
Chromeだと、「高度な設定→フォントをカスタマイズ→エンコード」で設定可能なやつです。
XMLHttpRequestでそれを使うのも少し変な気もしますが、デフォルト値として一考に値するのではないかと。
2011年12月8日8:18 NARUSE, Yui <nar...@airemix.jp>:
> --
> このメールは Google グループのグループ「html5j.org」の登録者に送られています。
Tohru Ike
Yoshinori TAKESAKO
>> ISO-2022-JPはメール以外でほとんど見ない
>
> 確かに数としては UTF-8, Shift_JIS, EUC-JP に比べるとだいぶ少なくなるのですが、
> 意識して見ていると意外とあります。
JPNICのWebサイトが思いっきりISO-2022-JPですね。
http://www.nic.ad.jp/
あと、個人で有名なのはセキュリティmemoのページとか。
http://www.st.ryukoku.ac.jp/~kjm/security/memo/
ちょうど1年ぐらい前に、Windows Update で（セキュリティ上の問題で）
IE8 が ISO-2022-JP の自動検出を止めたときに少し話題になりました。
http://togetter.com/li/79594
id:TAKESAKO
Wataru Kanzaki
>ロードした文書のエンコーディングを検出するところで、その検出法でエンコーディングが気になっているようです。
Perlライブラリのjcode.plでは、特定の文字コードを正規表現で調べて、見つかればsjisやeucなどとしています。
Encode.pmはunicodeもサポートしていますが、
BOMがあれば、その種類からUTF-32、UTF-16、UTF-8は判断しているようですが、
それ以外の判定方法がよくわかりません。。。
たぶん、基本方法は同じだと思いますが。
http://mikeneko.creator.club.ne.jp/~lab/kcode/jcode.html
http://search.cpan.org/~dankogai/Encode/
>中のコンテンツを見て、化けない文字コードにするという仕組みも入っています。
>それを利用した「美乳」っていうバッドノウハウが使われた時代もありました。
>http://www.shtml.jp/mojibake/binew.html
Opera8.0.2でXHR受信するときは、その方法を使ってました。
「あ～可能能力」とか、そんな感じの文字列を含めてましたが、
当時はXHRもUnicodeも最新技術（最新仕様）でしたし、Safari1.2はLaten-1以外の文字コードが全滅でしたし。
（サーバーでescape()と同等の処理をしておき、Safariでunescape()することで表示できた。）
基本はjcode.plの判定方法も同じだと思います。
たった２文字で表現できるから、それがよく使われる方法だというだけで。
HTMLファイルなら<meta>で指定している所がほとんどだと思いますが、
それ以外のCSVファイルやプレーンテキストの文字コード指定があるところは、
どちらかというと少数ではないでしょうか？
http://www.tepco.co.jp/forecast/index-j.html
東電の電気予報のページ、右下からCSVファイルをダウンロードできますが、
content-typeヘッダにcharsetが入っていないShift_JISファイルです。
responseTypeが”document”限定の処理で、CSVファイルなどは関係ないんですかね？
-----
Wings-Winds
http://www.wi-wi.jp/
神崎渉瑠
NARUSE, Yui
2011年12月8日8:18 NARUSE, Yui <nar...@airemix.jp>:
> HTML5 Parser （詳細は後述） を実装しているブラウザ、具体的には Chrome や Safari を使っていると、
> IE や Firefox を使っている時よりも文字化けに遭遇しやすいと思うのですが、そういったときに化けるのは
> 宣言のないサイトです。で、そういうサイトも IE や Firefox だと化けなかったりします。
後述と書いておいて後述し忘れてたので改めて書きます。
HTML5 というと Canvas やオフラインキャッシュのような派手な新機能が目につきますが、
現在 Web に存在する HTML を表示するための、ブラウザベンダー向けベストプラクティス集
という側面も存在します。
で、HTML のエンコーディングをどう検出するのがよいかについても以下の通りまとまっています。
http://www.w3.org/TR/html5/parsing.html#determining-the-character-encoding
特徴的なのはたとえば Character Encoding Overrides という仕組みでしょうか。
Shift_JIS と書かれていたら CP932 とみなす、とか。
--
NARUSE, Yui <nar...@airemix.jp>
Takuya Oikawa
--
このメールは Google グループのグループ「html5j.org」の登録者に送られています。
このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。
Shogo Ohta
最終的に必要なのはXHRでdocumentを解釈する際のエンコーディングをどう決めるかという話だと思うので、
その点について回答すると、
(HTTPヘッダやmetaタグを考慮しつつ)XHRを送信する元のページの文字コードに従う
のが良いと思います。
通常XHRは同一ドメイン内に送信するので、一つのサイト内では同一エンコーディングが使われていることが多いですし、
万が一、送信元と送信先で文字コードが違っていたときに文字化けすることは開発者にとって十分に予想可能な現象です(クロスサイトXHRのときに文字化けするのも同様)。
また、AutoPagerize( http://autopagerize.net/
)というFirefox/Chrome/Safariで使える拡張機能がありまして、
これは様々なサイトで、XHRで取ってきたHTMLを今見ているページに挿入するという機能を持っています。
ここでもエンコーディングは問題となりえますが、
XHR#overrideMimeTypeで元のページの文字コードを強制して読み込むことで、うまく動作しています。
逆に言えば、overrideMimeTypeで開発者側がなんとかすることもできるので、エンコーディング検出は控えめのほうが良いと思っています。
開発者がXHRを使う実装をしたときにはたまたま文字化けが発生せず、リリースしてみたらたまに文字化けするみたいな現象が一番厄介だと思います。
--
太田昌吾 <os0...@gmail.com>
2011年12月8日9:10 Wataru Kanzaki <goo...@wi-wi.jp>: