標準に準拠するには、HTML ファイルに-element<meta charset="utf-8">
内の要素を含める必要があることを読みました。head
ファイル自体でファイルのエンコーディングを指定することに意味があるのはなぜですか? - 要素を読み取るにはmeta
、エンコーディングを既に知っている必要があります。そのため、エンコーディングを再度指定するのは冗長/無用のようです。
標準に準拠するには、HTML ファイルに-element<meta charset="utf-8">
内の要素を含める必要があることを読みました。head
ファイル自体でファイルのエンコーディングを指定することに意味があるのはなぜですか? - 要素を読み取るにはmeta
、エンコーディングを既に知っている必要があります。そのため、エンコーディングを再度指定するのは冗長/無用のようです。
この要素が読み取られるまで、ドキュメントはユーザー エージェントのデフォルトのエンコーディングで解釈されます。(多くの場合、これは ISO-8859-1 です。) エンコーディングがデフォルトと異なる場合、ドキュメントは meta 要素に従って再解釈されます。そのため、本文のできるだけ早い段階で配置するか、できれば HTTP ヘッダーを使用する必要があります (以下を参照)。
要素の希望<meta>
は、先行するすべての文字が ASCII 文字セットにあり、ほぼすべての文字セットで正しく解釈されることです。
ただし、一般的に、可能であれば、この情報は HTTP 応答ヘッダーで送信する必要があります。
Content-Type: text/html; charset=utf-8
これにより、ドキュメントが最初から正しく解釈されます。
ドキュメントがそのエンコーディングをドキュメント内で宣言するのは逆説的であることは事実です。そして、それは実際には二次的なフォールバックにすぎません。設定されている場合、 HTTPContent-Type
ヘッダーが常に優先されます。常に設定する必要があります。
HTML の meta 要素で文字セットを宣言することは、ドキュメントが非 HTTP コンテキストで扱われる場合に意味があります。これは、HTTP 経由で提供されていないため、HTTP ヘッダーでエンコーディングを宣言できない場合を意味します。これは、後でオフラインで使用するためにドキュメントをダウンロードして保存する場合に当てはまります。この場合、たまたまほとんどのエンコーディングが ASCII 互換であり、ブラウザは通常、Latin-1 や UTF-8 (ブラウザの設定による) などの ASCII 互換のデフォルト エンコーディングでドキュメントを読み込もうとします。メタタグ。ドキュメントが Shift-JIS や GB18030 などの非 ASCII 互換エンコーディングで保存されている場合、デフォルト設定と、ブラウザが処理しているエンコーディングをどれだけインテリジェントに把握できるかによって、これが機能する場合と機能しない場合があります。それ'
このようにして、ページのエンコーディングに関するメタデータ情報を設定しています。この設定がない場合、ページはブラウザで設定されたデフォルトのエンコーディングで読み込まれます。ページに非 ASCII 文字が含まれている場合、これは非常に不便です (たとえば、UTF-8 エンコーディングがページ エンコーディングとして設定されていない場合、疑問符が表示されます)。