Q&A
(解決したので依頼を削除)
「文字エンコーディング宣言は、HTML 文書の先頭から 1024 バイト以内に記述する必要がある」と学びましたが、それについて 4 点疑問があります。
- 「文字コード宣言」全体を 1024 バイト以内に書かねばならないのか？
- DOCTYPE宣言は 1024 バイトに含まれるか？
- コメントは 1024 バイトに含まれるか？
- その文字コードでエンコーディングした文字列( 2 進数の列)の 1024 バイト以内という理解で正しいか？
細かいことですが、どうかよろしくお願いいたします。
回答3件
0
本題からは外れますが、ローカルファイルやサーバ設定が固定でヘッダが送れない、という場合以外は文書内の<meta charset>を使うより、HTTPヘッダのContent-typeにcharset指定するほうがいいかなと思いました。
投稿2016/05/19 09:17
総合スコア145183
ベストアンサー
ええと、html文書を送信する際、例えばエディタでShift_JISで記述していれば、Shift_JISでエンコードされてブラウザに送信されますよね？違いますでしょうか？
そうすると、文字コードが分からねばデコードできませんので、「エンコードされた状態」の先頭から1024バイト以内と理解したのですが、違いますでしょうか？
文字コード宣言に使われている半角英数字や基本的な半角記号は、どの文字コード体系でも同じコードになるでしょうから(大小文字の違いを除けば)、デコードしなくても文字コード宣言は探索できるでしょうし。。
ほとんど問題にならないのは承知の上なのですが、細かいことが気になるたちでして、よろしくお願いいたします。
これはブラウザの仕様を確認したわけではありませんが、先頭の1024バイトを取得してmetaタグのcharsetを判別する場合は半角英数の文字コード(Aなら41)は共通なのでデコードする必要はないのではないでしょうか。
4番目の質問に関しては質問の内容がきちんと把握できていないようでした。
「文字コードは関係ない」と表現したのは、metaタグでShift-JISと指定されていた場合
ファイルがShift-JISでエンコードされている場合
ファイルがUTF-8でエンコードされている場合
どちらでもデータの先頭1024バイトを取得するため(全角の有無で取得できる内容が変わってしまいますが)metaタグの指定は関係ないという意味でした。
追記です。そもそも、ある文字列が「何バイト」かは、コード化(エンコード)してはじめて計算できるものですから、エンコードして送られた情報のことだと考えました。
たしかにほとんど問題にはならないのですが、たとえばルート要素の前にコメントを350文字ほど長々と書けば(只のアホですが・・)UTF-8なら日本語は一文字3バイト以上ですから文字コード宣言は 1024 バイト以降になりアウトですよね。
自分のグーグルクロムはデフォルトでShift_JISでデコードしているようですので(文字コードを宣言せずに漢字仮名交じりの短文のhtml文書を、UTF-8,EUC-JP,Shift_JIS,ISO-2022-JPでそれぞれ記述したところ、Shift_JIS以外はすべて文字化けしてしまいました;)、上記のようなことをすれば文字化け或いはデコードのし直しをすることになりそうです。
まずありえない状況でしょうが。。
ただ、正確に理解したいもので、ご質問しております。
すみません、ご回答いただいているのに気付かず、上の追記を書いてしまいました。
なるほどそういう意味でしたか！確かに、もし全角文字を文字コード宣言の前に書くとすれば、コメント位しかないでしょうから、先にコメントさえ書かねば、どのコード体系でも文字コード宣言までのバイト数は同じになりますね；
「文字コードは関係ない」というのはそういう意味だったのですね。
自分の理解と同じようですので安心しました。1～4全てスッキリしました。どうも有難うございました！
皆さま色々教えて下さり有難うございます。sharowさんやhideさんが上で追加回答下さっていたのも今気付いて読みました；
自分のコメントを少し分かりやすくなるよう修正しました。
0
- 「文字コード宣言」全体を 1024 バイト以内に書かねばならないのか？
metaタグの終わりの>をもって宣言となります。
エンコーディングの指定を見つけた瞬間に、ブラウザはそのエンコーディングでドキュメントを再度パースする必要があります。もしエンコーディングの指定がドキュメントの最後にあった場合、ドキュメントの最後まで読み込んだ後でないと正しいコンテンツを表示するのは無理です。最初の方にあったほうが都合がいいのです。これはJPEGやPNGで最初の方(ヘッダ部)に画像サイズやフォーマット情報があることによる利点と同じです。
投稿2016/05/19 08:17
編集2016/05/19 08:30
総合スコア1149
確かにそうですよね。hideさんの示して下さったリンク先の記述からもハッキリいたしました。有難うございました。
※1024 バイト以内に書かなかった場合は無視されるのでなく、そのブラウザのデフォルトの文字コードでデコード・パースしていって、文字コード指定を見つけた時点で、最初からパースをやり直すということですね。それは手間と時間の無駄になるので、最初の1024バイトをブラウザは最初に確認する・そこに記述する、という方法をとっているのですね。よく分かりました。一度実験して確認してみます。
「そのブラウザのデフォルト文字コード」はISO-8859-1(いわゆるlatin-1)です。
https://www.w3.org/International/articles/http-charset/index
ところでContent-Typeヘッダや<meta>で指定されなかった場合、JoelOnSoftwareのUNICODEに関する記事で、昔のIEの挙動に関する面白い話があります(今のIEは違うかも?)。いわく、統計的傾向に基づきコンテンツのエンコーディングを推測するのだそうです。よくある「特定のブラウザで見ると文字化けする」という場合に、エンコーディングの指定自体が間違っている場合を除くと、この推測の精度や、そもそも推測するように実装されているのかなどの点で文字化けするか否かを分けているようです。
https://www.supinf.co.jp/tech/2014/12/03/joel-unicode/
ちょっと雑談でした。
そういえば昔、EUCの時代に最初の文字で判別されるから<!--京-->入れるってのもありましたね。
<!--京-->初めて知りました、なるほどｗ 物は使い様ですね。
コメントのコメント以外での利用は<!--天安門事件-->くらいだと思ってました。
>ISO-8859-1(いわゆるlatin-1)
それもW3Cの仕様で決められていたのですね！英語がそれほど得意でないこともあり、なかなかそこまで調べられませんでした。有難うございます！
ブラウザ側でエンコーディングを推測すればいいのでないか・または実際に推測しているのでないかという疑問は自分も持っていたのですが、少なくとも昔のIEはそうしていたのですね。非常に興味深いです。
自分はまだまだかなり初心者マークですので、詳しくなれるよう頑張ります。
あなたの回答
tips
プレビュー
