meta 要素

4.2.5 meta 要素

カテゴリー
メタデータ・コンテンツ
この要素を使うことができるコンテキスト：
charset 属性が存在する、または、要素の http-equiv 属性がエンコーディング宣言状態にある場合：head 要素の中
http-equiv 属性が存在するが、エンコーディング宣言状態にない場合：head 要素の中
http-equiv 属性が存在するが、エンコーディング宣言状態にない場合：head 要素の子となる noscript 要素の中
name 属性が存在する場合： メタデータ・コンテンツが期待される場所
コンテンツ・モデル：
空
コンテンツ属性：
グローバル属性
name
http-equiv
content
charset
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 要素を、ひとつのドキュメントにつき 2 つ以上入れてはいけません。

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

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

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

4.2.5.1 標準メタデータ名

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

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

application-name

この値は、該当のページが表すウェブ・アプリケーションの名前を与える短い自由記述形式の文字列でなければいけません。もしページがウェブ・アプリケーションでないなら、application-name メタデータ名を使ってはいけません。ドキュメントにつき、application-name を値にセットした name 属性を持つ meta 要素を、1 つしか入れてはいけません。ユーザーエージェントは、ページの title の参照において、ユーザー・インタフェース上にそのアプリケーション名を使うことができます。なぜなら、そのタイトルは、アプリケーション名そのものになる代わりに、いずれくる特別な瞬間におけるページの状態に相当する状態メッセージやその類を含むかもしれないからです。

author

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

description

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

generator

この値は、ドキュメント生成に使われたソフトウェアを識別する自由記述形式の文字列でなければいけません。この値は、手作りのページで使ってはいけません。

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

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

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

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

<!DOCTYPE HTML>
<html>
 <head>
  <title>Typefaces on UK motorways</title>
  <meta name="keywords" content="british,type face,font,fonts,highway,highways">
 </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 ページでタイプを追加することができます。新しい名前を登録する際には、次の情報を指定しなければいけません：

キーワード

実際の定義名。この名前は、他の定義済みの名前に似ていて、他の定義済みの名前と混乱するような名前ではいけません。（例：大文字と小文字が違っているだけ、とか）

簡単な説明文

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

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

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

状態

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

Proposed
該当の名前は、広く対等にレビューや承認を受けていないことを表します。誰かが、それをすでに提案し、それを現在使っている、または使う予定であることを意味します。
Ratified
該当の名前は、広く対等にレビューや承認を受けたことを表します。その名前を使うページをどうやって扱うのかを明確に定義した仕様があります。その仕様では、それが不適切な方法で使われたときの扱いについても触れられています。
Discontinued
該当のメタデータ名は、広く対等にレビューを受けたが、不足があることを意味します。すでに存在しているページではこのキーワードが使われていますが、新しいページではそれを使うことを避けるべきです。"簡単な説明" と "仕様" のエントリがあれば、そこから、ウェブ制作者は代わりに何を使うべきかについて詳細を得ることができるでしょう。

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

もしメタデータ名が、一ヶ月以上の間、使われることも仕様化されることもなく "proposed" 状態のまま登録されていたなら、レジストリから削除されるでしょう。

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

誰でも、いつでも、状態を変更することができますが、上記の定義に基づき、それに一致するときにのみ、そうするべきです。

準拠チェッカーは、この仕様で明確に定義されていない値を使って良いのか悪いのかを確定するために、WHATWG Wiki MetaExtensions ページで公開されている情報を使わなければいけません：本仕様で定義されている、または、"proposed" や "ratified" としてマークされている値は、受け入れられるべきです。一方、"discontinued" としてマークされている、または、本仕様にも前述のページにもリストされていない値は、妥当でないものとして拒否されなければいけません。準拠チェッカーはこの情報をキャッシュすることができます（例えば、パフォーマンスの理由から、または、信頼性が低いネットワーク接続の利用を避けるため）。

ウェブ制作者が、この仕様もしくは Wiki ページのいずれにも定義されていない新しいタイプを使った場合、準拠チェッカーは、前述の詳細な説明を表示した上で、Wiki にその値を "proposed" 状態で追加するよう提案すべきです。

値が 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. コンテンツ言語状態にある http-equiv 属性を持った他の meta 要素の処理がすでに成功したら（つまり、それが、ユーザーエージェントに挿入され、この手順リストの最後の手順に到達したとき）、これらの手順を中止します。

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

  3. 該当の要素の content 属性に U+002C COMMA 文字 (,) が含まれていたら、これらの手順を中止します。

  4. input を該当の要素の content 属性の値とします。

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

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

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

  8. プラグマ・セットのデフォルト言語を、前の手順から得られた文字列となるようにセットします。

このプラグマは、HTTP の Content-Language ヘッダーと全く同じではありません。 [HTTP]

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

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

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

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

エンコーディング宣言状態は、HTML ドキュメントだけで利用することができます。この状態にある http-equiv 属性を伴ったこの要素を XMLドキュメントで使ってはいけません。

デフォルトスタイル状態 (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. U+0030 DIGIT ZERO から U+0039 DIGIT NINE の範囲の文字の列を集め、非負整数パース規則を使って、その文字列をパースします。結合した連続文字が空文字列なら、何も数値はパースされないことになります。この手順を終了します。そうでなければ、パースされた数値を time とします。

  7. U+0030 DIGIT ZERO から U+0039 DIGIT NINE の範囲と U+002E FULL STOP (".") の文字の列を集めます。集められた文字はすべて無視します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  22. url から、U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR) のすべてを切り取ります。

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

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

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

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

  • 妥当な非負整数のみ、または、
  • 妥当な非負整数に、U+003B SEMICOLON (;) が続き、一つ以上のスペース文字が続き、 U+0055 LATIN CAPITAL LETTER U または、U+0075 LATIN SMALL LETTER U のいずれかひとつ、そして、U+0052 LATIN CAPITAL LETTER R または、U+0072 LATIN SMALL LETTER R のいずれかひとつ、そして、U+004C LATIN CAPITAL LETTER L または、U+006C LATIN SMALL LETTER L のいずれかひとつ、そして、ひとつの U+003D EQUALS SIGN (=) が続き、そして、その後に妥当な URL が続く。

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

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

<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 としてエンコードしたものから構成されます。Act as if receiving a set-cookie-string for the document's address via a "non-HTTP" API, [COOKIES] [RFC3629]

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

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

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

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

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

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

キーワード

定義する実際の名前。この名前は、同じ要件を持った事前登録済み HTTP ヘッダーに一致しなければいけません。

簡単な説明

短くて、非規定の、プラグマ指示子の目的の説明。

仕様
対応する HTTP ヘッダーを定義している仕様へのリンク

準拠チェッカーは、この仕様で明確に定義されていないその値を使って良いのか悪いのかを確定するために、WHATWG Wiki PragmaExtensions ページで公開されている情報を使わなければいけません。準拠チェッカーは、この情報をキャッシュすることができます（例えば、パフォーマンスの理由から、または、信頼性が低いネットワーク接続の利用を避けるため）。

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

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

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

  • 文字エンコーディング名は、ファイルをシリアル化するために使われる文字エンコーディングの名前でなければいけません。
  • その値は、妥当な文字エンコーディング名でなければいけません。そして、そのエンコーディング用の推奨 MIME 名に、ASCII の大文字と小文字を区別しないものに一致しなければいけません。 [IANACHARSET]
  • 文字エンコーディング宣言は、文字参照や文字エスケープといった類を使わずにシリアル化されてはいけません。
  • 文字エンコーディング宣言を含んだ要素は、ドキュメントの最初の 1024 バイト以内で完全にシリアル化されなければいけません。

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

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

ドキュメントが 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] [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/2011/WD-html5-20110525/semantics.html#the-meta-element