meta 要素

4.2.5 meta 要素

カテゴリー:
メタデータ・コンテント
この要素を使うことができるコンテキスト:
charset 属性が存在する、または、要素の http-equiv 属性がエンコーディング宣言状態にある場合:head 要素の中
http-equiv 属性が存在するが、エンコーディング宣言状態にない場合:head 要素の中
http-equiv 属性が存在するが、エンコーディング宣言状態にない場合:head 要素の子となる noscript 要素の中
name 属性が存在する場合: メタデータ・コンテントが期待される場所
コンテントモデル:
コンテント属性:
グローバル属性
name — メタデータ名
http-equiv — プラグマ指示子
content — 要素の値
charset文字エンコーディング宣言
text/html におけるタグの省略:
終了タグはありません。
指定可能な ARIA role 属性 の値:
なし
指定可能な ARIA ステートとプロパティ属性:
グローバル aria-* 属性
DOM インタフェース:
interface HTMLMetaElement : HTMLElement {
           attribute DOMString name;
           attribute DOMString httpEquiv;
           attribute DOMString content;
};

meta 要素は、title, base, link, style, script 要素を使って表現することができないさまざまな種類のメタデータを表します。

meta 要素は、name 属性を使ってドキュメントレベルのメタデータを、http-equiv 属性を使ってプラグマ指示子を表すことができます。そして、charset 属性を使って、HTML ドキュメントが文字列の形式(例:ネットワーク上での転送や、ディスクストレージに使います)にシリアル化されたときのファイルの文字エンコーディング宣言を表すことができます。

name, http-equiv, charset 属性のうち、正確に、少なくとも一つを指定しなければいけません。

name, http-equiv 属性のいずれかが指定されていれば、content 属性も指定されなければいけません。そうでなければ、省略されなければいけません。

charset 属性は、ドキュメントで使われる文字エンコーディングを指定します。これは、文字エンコーディング宣言です。もしこの属性が XML ドキュメントに存在すれば、その値は、文字列 "UTF-8" に一致しなければいけません。大文字と小文字の違いは区別されません。(ゆえに、そのドキュメントは、エンコーディングとして UTF-8 を使わなければいけないということになります。)

XMLドキュメントでは、meta 要素の charset 属性は何も作用しません。XHTMLへ、またはXHTMLから移行しやすくするために、この要素の利用が認められているに過ぎません。

charset 属性を持った meta 要素は、ひとつのドキュメントにつき 1 つしか入れることができません。

content 属性は、この要素がその目的で使われているとき、ドキュメントのメタデータの値や、プラグマ指示子を与えます。本仕様の次のセクションで説明するように、どんな値が許されるのかは、そのコンテキストに厳密に依存します。

meta 要素が name 属性を持つなら、それはドキュメントのメタデータをセットします。ドキュメントのメタデータは、名前と値をペアとした単位で表されます。meta 要素の name 属性が名前の部分に相当し、同じ要素の content 属性が値の部分に相当します。名前は、メタデータのどんな特徴がセットされているのかを指定します。妥当な名前とその値の意味は、次のセクションで説明します。meta 要素が content 属性を持っていないなら、名前と値のペアとしてのメタデータの値の部分は、空文字列となります。

namecontent IDL 属性は、同じ名前のコンテンツ属性を反映しなければいけません。IDL 属性 httpEquiv は、コンテンツ属性 http-equiv反映しなければいけません。

4.2.5.1 標準メタデータ名

この仕様では、meta 要素の name 属性に使う名前をいくつか定義します。

名前は大文字と小文字を区別しませんので、ASCII case-insensitive で比較されなければいけません。

application-name

この値は、ページが表しているウェブアプリケーションの名前を与える自由形式の短い文字列でなければいけません。もしそのページがウェブアプリケーションでないなら、application-name メタデータ名を使ってはいけません。この属性を使って、それぞれの名前の言語を指定して、ウェブアプリケーションの名前を翻訳することができます。

ドキュメントにつき、言語が指定され、application-name が値にセットされた name 属性を持つ meta 要素を、1 つしか入れてはいけません。

ユーザーエージェントは、ユーザーインタフェースで、ページの title に優先して、そのアプリケーション名を使うことができます。なぜなら、そのタイトルは、アプリケーション名そのものになる代わりに、いずれくる特別な瞬間におけるページの状態に相当する状態メッセージやその類を含むかもしれないからです。

言語の順位リスト(たとえば、イギリス英語、アメリカ英語、そして英語)からアプリケーション名を探すために、ユーザーエージェントは次の手順を実行しなければいけません:

  1. languages を、言語のリストとします。

  2. default language を、Documentルート要素言語とします。ただし、それが存在し、その言語が未知のものでない場合に限ります。

  3. default language が存在し、それが languages の中のどの言語にも一致しないなら、それを languages に追加します。

  4. winning language を、languages の中のひとつ言語とします。それは、name 属性が値 application-name にセットされ、言語が該当の言語となる Document の中の meta 要素が存在する言語のうち、languages の中で最初の言語とします。

    どの言語もそのような meta 要素を持たないなら、これらの手順を中止します。アプリケーション名は存在しないことになります。

  5. name 属性に値 application-name がセットされ、言語winning language となる meta 要素のうち、Document 内でツリー順で最初の meta 要素の content 属性の値を返します。

author

この値は、ページの著者のうちひとりの名前を与える自由形式の文字列でなければいけません。

description

この値は、ページを説明する自由記述形式の文字列でなければいけません。この値は、ページの一覧で利用する場合にふさわしいものとなるようにしなければいけません。例えば、検索エンジンでの利用があげられます。ドキュメントにつき、description を値にセットした name 属性を持つ meta 要素を、1 つしか入れてはいけません。

generator

この値は、ドキュメント生成に使われたソフトウェアパッケージの一つを識別する自由記述形式の文字列でなければいけません。この値は、マークアップがソフトウェアによって生成されていないページで使うことはできません。たとえば、テキストエディアでマークアップが書かれたページなどです。

これは、"Frontweaver" と呼ばれるツールがページ生成に使われたとき、そのツール自身が、そのページを出力する際に、そのページの head 要素の中に、ページ生成のツールとして自身を特定するために何を入れることできるかを示しています:

<meta name=generator content="Frontweaver 8.2">
keywords

この値は、カンマ区切りトークン・セットでなければいけません。それぞれは、そのページに関連するキーワードとなります。

このページは英国の高速道路に書かれている書体に関するものですが、meta 要素を使って、ユーザーがこのページを探すために使うと考えられるいくつかのキーワードを指定しています:

<!DOCTYPE HTML>
<html>
 <head>
  <title>英国の高速道路の書体</title>
  <meta name="keywords" content="英国,書体,フォント,高速道路">
 </head>
 <body>
  ...

多くの検索エンジンは、このようなキーワードを考慮しません。なぜなら、この機能は歴史的に信頼して使えるものではなかったからです。そして、スパムとして検索エンジンの結果に誤解を与えるといった行為もあり、ユーザーには役に立たなかったからです。

ウェブ制作者がページに適したものとして指定したキーワードのリストを取得するために、ユーザーエージェントは、次の手順に従わなければいけません:

  1. keywords を、空のリストとします。

  2. name 属性と content 属性を持ち、その name 属性の値が keywords である meta 要素それぞれに対して、次の副手順を実行します:

    1. 該当の要素の content 属性の値をカンマで区切ります

    2. 結果としてトークンが得られれば、それらを keywords に追加します。

  3. keywords から重複分を削除します。

  4. keywords を返します。これが、ウェブ制作者が該当のページに適しているとして指定したキーワードのリストとなります。

ユーザーエージェントは、この値の信頼性において、十分に確信を得られなければ、この情報を使うべきではありません。

例えば、コンテンツ・マネージメント・システムが、サイト固有の検索エンジンのインデックスを追加するために、そのシステムの内部でページのキーワード情報を使うのであれば、問題ないでしょう。しかし、大規模なコンテンツ・アグリゲータがこの情報を使ってしまうと、不適切なキーワードを使ってランキング・メカニズムを操作しようとするユーザーが出てきてもおかしくないでしょう。

4.2.5.2 その他のメタデータ名

事前定義済みのメタデータ名セットの拡張は、WHATWG Wiki MetaExtensions のページで登録することができます。 [WHATWGWIKI]

誰でもいつでも自由に、WHATWG Wiki MetaExtensions ページでタイプを追加することができます。新しい名前を登録する際には、次の情報を指定しなければいけません:

Keyword(キーワード)

定義する実際の名前。この名前は他の定義済みの名前に似た紛らわしいものにするべきではありません(たとえば、大文字と小文字が違うだけ、など)。

Brief description(簡単な説明文)

メタデータ名が何を意味するのかが分かる非規定の短い説明文。その値に要求されるフォーマットを含めてください。

Specification(仕様)
そのメタデータ名のセマンティクスと要件に関する詳細な説明へのリンク。Wiki 上の別のページでも構いませんし、外部のページへのリンクでも構いません。
Synonyms(同義語)

正確に同じ処理要件を持つ他の名前のリスト。ウェブ制作者は、同義語として定義された名前を使うべきではありません。それらは、ユーザーエージェントが古いコンテンツをサポートするため使われることを想定しているに過ぎません。誰でも、実際に使われていない同義語を削除することができます。古いコンテンツとの互換性のために同義語として処理される必要がある名前は、このようにして登録されることになります。

Status(状態)

次のいずれかひとつです:

Proposed
その名前は広く査読も受けてなく同意も得られていません。誰かがそれを提案し、それが使われている、または、使われるであろう、という状態です。
Ratified
その名前は広く査読を受け同意を得た状態です。その名前を使うページをどう処理するのかを、それを間違った使い方をしたときも含めて、明確に定義する仕様があります。
Discontinued
そのメタデータ名は広く査読を受け、これまでも必要とされてきている分かっているものです。既存のページではこのメタデータ名が使われていますが、新たなページでは避けるべきです。"brief description" と specification" に、もしあれば、ウェブ制作者は代わりに何を使うべきかについて、詳細が掲載されています。

メタデータ名が既存の値と重複していることが分かったら、それは削除され、既存の値の同義語としてリストされるべきです。

メタデータ名が使われることなく仕様化されることもなく一ヶ月の間 "proposed" で登録されたままなら、それはレジストリから削除されるかもしれません。

メタデータ名が "proposed" 状態で追加され、既存の値との重複が見つかったら、それは削除され、既存の値に対する同義語としてリストされるべきです。メタデータ名が "proposed" 状態で追加され、害があると分かったら、それは "discontinued" 状態に変更されるべきです。

誰でもいつでもその状態を変更することができますが、前述の定義に従ってそうするべきです。

準拠チェッカーは、WHATWG Wiki MetaExtensionsページで与えられる情報を使って、値が許可されたものかそうでないかを確定することができます。この仕様で定義された値や、"proposed" や "ratified" と書かれた値は、受け入れられなければいけません。一方、"discontinued" と書かれた値や、本仕様または前述のページのいずれでも取り上げられていない値は、正しくないものとして報告されなければいけません。準拠チェッカーは、この情報をキャッシュすることができます(たとえば、パフォーマンスの理由や、不安定なネットワーク接続での利用を避けるため)。

ウェブ制作者が、本仕様にも Wiki ページにも定義されていない新たなタイプを使うとき、準拠チェッカーは、前述の詳細を添えて、ステータス を "proposed" にして Wiki にその値を追加することを提案べきです。

値が URL となるメタデータ名を提案そして承認してはいけません。リンクは、meta 要素ではなく、link 要素を使って表されるべきです。

4.2.5.3 プラグマ指示子

http-equiv 属性が meta 要素に指定されると、その要素はプラグマ指示子となります。

http-equiv 属性は列挙属性です。下表ではこの属性に定義されたキーワードが列挙されています。キーワードがある行の最初のセルに記載された状態は、そのキーワードに対応する状態を表します。キーワードのいくつかは非準拠ですが、最後のカラムに記載されています。

状態 キーワード 備考
コンテント言語 content-language 非準拠
エンコーディング宣言 content-type
デフォルトスタイル default-style
リフレッシュ refresh
クッキーセッター set-cookie 非準拠

meta 要素がドキュメントに挿入されたとき、http-equiv 属性が存在し、上記の状態のいずれかを表していれば、ユーザーエージェントは、次で説明されているとおり、その状態に適したアルゴリズムを実行しなければいけません:

コンテント言語状態 (http-equiv="content-language")

この機能は非準拠です。ウェブ制作者は代わりに lang 属性を使うことが推奨されます。

このプラグマは、プラグマセットのデフォルト言語をセットします。 このプラグマの処理が成功するまでは、プラグマセットのデフォルト言語がないということになります。

  1. meta 要素に content 属性がないなら、これらの手順を中止します。

  2. この要素の content 属性に "," (U+002C) が含まれているなら、これらの手順を中止します。

  3. input を、この要素の content 属性の値とします。

  4. position を、input の最初の文字を指し示すようにします。

  5. ホワイトスペースをスキップします。

  6. スペース文字でない文字の列を集めます

  7. candidate を、前の手順から結果として得られた文字列とします。

  8. candidate が空文字列なら、これらの手順を中止します。

  9. プラグマセットのデフォルト言語candidate にセットします。

このプラグマは、同じ名前の HTTP の Content-Language ヘッダーと、まったくではないですが、ほとんどは、異なります。 [HTTP]

エンコーディング宣言状態 (http-equiv="content-type")

エンコーディング宣言状態は、charset 属性のセッティングの代替の形式です。それは文字エンコーディング宣言です。この状態のユーザーエージェントの要件は、すべて、本仕様の parsing のセクションで扱っています。

エンコーディング宣言状態にある http-equiv 属性を伴った meta 要素では、その content 属性は、文字列 "text/html;" に加え、オプションで、いくつかのスペース文字、文字列 "charset=" 、そして、文字エンコーディング宣言文字エンコーディングラベルのひとつをつなげたものを後ろに加えることができ、これらで構成される文字列に一致する値でなければいけません。大文字・小文字は区別されません

エンコーディング宣言状態にある http-equiv 属性を伴った meta 要素と、charset 属性を持った meta 要素の両方をドキュメントに入れてはいけません。

エンコーディング宣言状態は、HTML ドキュメントXML ドキュメントで利用することができます。エンコーディング宣言状態XML ドキュメントで使われる場合、文字エンコーディングの名前は、大文字・小文字を区別せずに、文字列 "UTF-8" に一致しなければいけません(ゆえに、そのドキュメントはそのエンコーディングとして UTF-8 が強制されます)。

エンコーディング宣言状態は、XML ドキュメントに何も影響を与えません。これは、XHTML へ、または、XHTML からの移行を容易にするためだけに許されたものです。

デフォルトスタイル状態 (http-equiv="default-style")

このプラグマは、デフォルトの代替スタイルシートセットの名前をセットします。

  1. meta 要素が content 属性を持たない、または、その属性の値が空文字列なら、これらの手順を中止します。

  2. 優先スタイルシートセットを、この要素の content 属性の値にセットします。 [CSSOM]

リフレッシュ状態 (http-equiv="refresh")

このプラグマは、時限リダイレクトとして動作します。

  1. リフレッシュ状態にある http-equiv 属性を伴った別の meta 要素の処理が成功したら(つまり、それが挿入されたときに、ユーザーエージェントがそれを処理して、これらの手順の最後の手順に達したのなら)、この手順を中止します。

  2. meta 要素が content 属性を持っていない、もしくは、その属性値が空文字列であれば、これらの手順を中止します。

  3. input を、この要素の content 属性の値とします。

  4. position を、input の最初の文字を指し示すようにします。

  5. ホワイトスペースをスキップします。

  6. ASCII 数値となる文字の列を集め非負整数パース規則を使って、その結果となる文字列をパースします。集められた文字の列が空文字列なら、何も数値はパースされないことになりますので、この手順を終了します。そうでなければ、time を、パースされた数値とします。

  7. ASCII 数値と "." (U+002E) 文字となる文字の列を集めます。集められた文字はすべて無視します。

  8. ホワイトスペースをスキップします。

  9. url を、現在のページのアドレスとします。

  10. position で指し示される input 内の文字が ";" (U+003B) 文字なら、position を次の文字の位置に進めます。そうでなければ、最後の手順に飛びます。

  11. ホワイトスペースをスキップします。

  12. position によって指し示されている input の文字が "U" (U+0055) 文字、または U+0075 LATIN SMALL LETTER U character (u) のいずれかなら、position を次の文字の位置に進めます。そうでなければ、最後の手順に飛びます。

  13. position によって指し示されている input の文字が "R" (U+0052) 文字、または U+0072 LATIN SMALL LETTER R character (r) のいずれかなら、position を次の文字の位置に進めます。そうでなければ、最後の手順に飛びます。

  14. position によって指し示されている input の文字が "L" (U+004C) 文字、または U+006C LATIN SMALL LETTER L character (l) のいずれかなら、position を次の文字の位置に進めます。そうでなければ、最後の手順に飛びます。

  15. ホワイトスペースをスキップします。

  16. position によって指し示されている input の文字が "=" (U+003D) なら、position を次の文字の位置に進めます。そうでなければ、最後の手順に飛びます。

  17. ホワイトスペースをスキップします。

  18. position によって指し示されている input の文字が "'" (U+0027) 文字、または """ (U+0022) 文字のいずれかなら、quote をその文字として、position を次の文字の位置に進めます。そうでなければ、quote を空文字列とします。

  19. url を、inputposition に位置する文字から最後までに相当する部分文字列と同じにします。

  20. quote が空文字列ではなく、url の中に quote と等しい文字が存在すれば、その文字と、その後ろに続く文字列が削除されるように、url をその文字の位置で切り詰めます。

  21. url の最後に続くスペース文字を切り取ります。

  22. url から、"tab" (U+0009), "LF" (U+000A), "CR" (U+000D) のすべてを切り取ります。

  23. meta 要素に対して url の値を解決して絶対 URL にします。これに失敗したら、これらの手順を中止します。

  24. 次の手順の一つ以上を実行します:

    さらに、よくあるように、ユーザーエージェントは、あらゆるタイマーの状態やあらゆる時限リダイレクトの宛先なども含め、その処理の一部またはすべての側面をユーザーを通知することができます。

リフレッシュ状態にある http-equiv 属性を伴った meta 要素では、その content 属性は、以下のいずれかで構成された値を持たなければいけません:

前者の場合では、整数は、ページがリロードされる前の秒数を表すことになります。後者の場合は、整数は、ページが指定 URL のページに置き換えられるまでの秒数を表すことになります。

新しい組織のトップページでは、このページが確実に 5 分おきに自動的にサーバーからリロードされるようにするために、head 要素の中に次のマークアップが入れられています。:

<meta http-equiv="Refresh" content="300">

自動スライドショーとして、連続したページを使うことができるでしょう。次のようなマークアップを使って、各ページから連続的に次のページへリフレッシュするようにしておきます:

<meta http-equiv="Refresh" content="20; URL=page4.html">
クッキーセッター (http-equiv="set-cookie")

このプラグマは HTTP クッキーをセットします。 [COOKIES]

これは非準拠です。代わりに実際の HTTP ヘッダーを使うべきです。

  1. meta 要素に content 属性がなければ、または、その属性値が空文字列なら、これらの手順を中止します。

  2. ストレージ・ミューテックスを取得します

  3. "非 HTTP" の API 経由で、ドキュメントのアドレスに対する set-cookie 文字列を受信したかのように振る舞います。要素の content 属性の値を UTF-8 としてエンコードしたものから構成されます。 [COOKIES] [RFC3629]

ドキュメント内に特定の状態を持った meta 要素を 2 つ以上同時に入れることはできません。

4.2.5.4 その他のプラグマ指示子

事前定義のプラグマ指示子セットの拡張は、条件付きですが、WHATWG Wiki PragmaExtensions ページで登録することができます。[WHATWGWIKI]

このような拡張は、Permanent Message Header Field Registry に登録されている HTTP ヘッダーと同等の名前を使わなければいけません。そして、その HTTP ヘッダーで説明されているのと同等の挙動をしなければいけません。 [IANAPERMHEADERS]

メタデータを記述するヘッダーに対応するプラグマ指示子、または、ユーザーエージェントで特定の処理を必要としないプラグマ指示子は、登録できません。その場合は、メタデータ名を使ってください。HTTP 処理モデル(例:キャッシング)に影響を与えるヘッダーに相当するプラグマ指示子は登録できません。それは、HTML を実装しているユーザーエージェントと、そうでないユーザーエージェントとで、HTTP レベルの挙動が違ってしまう結果になる可能性があるからです。

これらの条件を満たせば、誰でもいつでも自由に、WHATWG Wiki PragmaExtensions ページを編集してプラグマ指示子を追加することができます。登録には次の情報が指定なければいけません:

Keyword(キーワード)

定義する実際の名前。同じ要件を持つ事前登録済みの HTTP 名と一致しなければいけません。

Brief description(簡単な説明)

プラグマ指示子の目的が分かる非規定の短い説明。

Specification(仕様)
対応する HTTP ヘッダーを定義する仕様へのリンク。

準拠チェッカーは、この仕様で明確に定義されていないその値を許容してもよいかのいけないのかを確定するために、WHATWG Wiki PragmaExtensions ページで公開されている情報を使うことができます。本仕様で定義された値や前述のページに列挙された値は許容されなければいけません。一方、本仕様や前述のページに列挙されていない値は無効として拒絶されなければいけません。準拠チェッカーは、この情報をキャッシュすることができます(例えば、パフォーマンスの理由から、または、信頼性が低いネットワーク接続の利用を避けるため)。

4.2.5.5 ドキュメントの文字エンコーディングの指定

文字エンコーディング宣言とは、どの文字エンコーディングを使ってドキュメントを蓄積したり転送するのかを指定するメカニズムのことです。

次の制限が文字エンコーディング宣言に適用されます:

  • 指定する文字エンコーディング名は、ファイルをシリアル化するために使われる文字エンコーディングラベルのひとつに一致しなければいけません。大文字と小文字は区別されません[ENCODING]
  • 文字エンコーディング宣言は、文字参照や文字エスケープといった類を使わずにシリアル化されなければいけません。
  • 文字エンコーディング宣言を含んだ要素は、ドキュメントの最初の 1024 バイト以内で完全にシリアル化されなければいけません。

さらに、meta 要素における数の制限によって、ドキュメントにつき、meta ベースの文字エンコーディング宣言は 1 つしか入れることができません。

HTML ドキュメントの先頭が BOM でない場合や、エンコーディングContent-Type メタデータで明示的に指定されていない場合や、ドキュメントが iframe srcdoc ドキュメントでない場合は、採用する文字エンコーディングは ASCII 互換文字エンコーディングでなければいけません。そして、そのエンコーディングは、charset 属性を伴う meta 要素か、エンコーディング宣言状態にある http-equiv 属性を伴う meta 要素を使って特定されなければいけません。

たとえエンコーディングが US-ASCII だとしても、文字エンコーディング宣言は必須です(Content-Type メタデータか、ファイルの中で明示的に)。これは、ユーザーがフォームに入力したり、スクリプトによって生成される URL の中などで、非 ASCII 文字を処理する必要があるからです。

ドキュメントが an iframe srcdoc ドキュメントなら、そのドキュメントに文字エンコーディング宣言を入れてはいけません。(この場合、そのソースは、該当の iframe が入れられているドキュメントの一部であるため、ソースはすでにデコードされています。)

HTML ドキュメントが、charset 属性を伴った meta 要素、または、エンコーディング宣言状態にある http-equiv 属性を伴った meta 要素を含んでいるなら、採用される文字エンコーディングは ASCII 互換文字エンコーディングでなければいけません。

ウェブ制作者は UTF-8 を使うことが推奨されます。準拠チェッカーは、旧来のエンコーディングが使われていたら、ウェブ制作者にアドバイスすることができます。 [RFC3629]

オーサリングツールは、新規にドキュメントを作成する際には、UTF-8 をデフォルトで使うべきです。 [RFC3629]

0x20 から 0x7E の範囲のバイト列が U+0020 から U+007E の範囲の文字に相当しない文字をエンコードできてしまうようなエンコーディングは、潜在的なセキュリティー脆弱性を意味します:そのようなエンコーディングをサポートしない(または、そのエンコーディングを宣言するために使われたラベルをサポートしていない、または、ラベル付けされていないコンテンツのエンコーディングを検知するメカニズムが、他のユーザーエージェントと同じでない)ユーザーエージェントでは、技術的に害のない平文のテキストを、HTML タグや JavaScript として解釈してしまうかもしれないのです。ゆえに、ウェブ制作者はそのようなエンコーディングを使うべきではありません。例えば、これは、ASCII で "<script>" に相当するバイトが違う文字列にエンコードできてしまうようなエンコーディングに当てはまります。ウェブ制作者は次のようなエンコーディングを使うべきではありません。例えば、よく知られているものとては、JIS_C6226-1983 , JIS_X0212-1990 , HZ-GB-2312 , JOHAB (Windows code page 1361) や、ISO-2022 に基づいたエンコーディングや、EBCDIC に基づいたエンコーディングです。さらに、ウェブ制作者は、CESU-8, UTF-7, BOCU-1, SCSU といったエンコーディングを使ってはいけません。これらも、同類になります。なぜなら、これらのエンコーディングはウェブコンテンツに使うことをまったく想定していないからです。 [RFC1345] [RFC1842] [RFC1468] [RFC2237] [RFC1554] [CP50220] [RFC1922] [RFC1557] [CESU8] [UTF7] [BOCU1] [SCSU]

ウェブ制作者は UTF-32 を使うべきではありません。本仕様で説明しているエンコーディング検知アルゴリズムでは意図的に UTF-16 と区別しないからです。 [UNICODE]

非 UTF-8 エンコーディングの利用は、フォームサブミッションや URL エンコーディングで予期せぬ結果をもたらすことがあります。これらは、デフォルトでドキュメントの文字エンコーディングを使うからです。

XHTML では、必要に応じて、インライン文字エンコーディング情報として XML 宣言を使うべきです。

HTML では、文字エンコーディングが UTF-8 だと宣言するには、ウェブ制作者はドキュメントの最初の方(head 要素の中)に次のマークアップを入れることができます:

<meta charset="utf-8">

XML では、代わりに、マークアップの一番最初で XML 宣言が使われるでしょう:

<?xml version="1.0" encoding="utf-8"?>

※ 原文:http://www.w3.org/TR/2014/REC-html5-20141028/document-metadata.html#the-meta-element