Loading article…
ハイパーテキストマークアップ言語（HTML）は1991年から使用されていますが、1997年12月にリリースされたHTML 4.0は、国際文字をほぼ完全に扱う最初の標準化バージョンでした。HTML文書に7ビットASCIIの範囲外の特殊文字が含まれる場合、情報の整合性と、あらゆるブラウザでの表示という2つの目標を考慮する必要があります。
現在廃止されているW3C仕様のバージョン5.3と、WHATWGが発行している現在のLiving Standardでは、有効なエンコーディングはUTF-8のみです。[ 1 ] [ 2 ]
文書内で使用される文字コードを指定するには、大きく分けて2つの方法があります。
まず、Webサーバーはハイパーテキスト転送プロトコル（HTTP）ヘッダーcharsetに文字エンコーディングまたは「 」を含めることができ、通常は次のようになります。[ 3 ]Content-Type
Content-Type: text/html; charset=utf-8この方法により、HTTP サーバーはコンテンツ ネゴシエーションに応じてドキュメントのエンコーディングを変更する便利な方法を得ることができます。特定の HTTP サーバー ソフトウェアではこれが可能です。たとえば、Apache のモジュールmod_charset_liteなどです。[ 4 ]
第二に、宣言文は文書自体の中に含めることができる。
headHTMLでは、この情報をドキュメントの上部付近の要素内に含めることができます。 [ 2 ]
< meta http-equiv = "Content-Type" content = "text/html; charset=utf-8" >HTML5では、以下の構文もまったく同じ意味になります。[ 2 ]
< meta charset = "utf-8" >XHTML文書には、文字エンコーディングをXML宣言で表現するという 3 番目のオプションがあります。以下のように記述します。[ 5 ]
<?xml version="1.0" encoding="utf-8"?>この2番目のアプローチでは、宣言が解析されるまで文字エンコーディングがわからないため、宣言自体を含むドキュメントで使用されている文字エンコーディングがどれであるかを判断するのが困難です。文字エンコーディングがASCII拡張である場合、宣言自体を含むコンテンツは純粋なASCIIである必要があり、正しく動作します。UTF -16BEやUTF-16LEなど、ASCII拡張ではない（つまりASCIIのスーパーセットではない）文字エンコーディングの場合、WebブラウザなどのHTMLプロセッサは、ヒューリスティックを使用して宣言を解析できる場合があります。
現在のリビングスタンダードに準拠したHTMLはUTF-8である必要がありますが、上記いずれかの形式のエンコーディング宣言は必須です。文字列「utf-8」と大文字小文字を区別せずに一致させる必要があり、ドキュメントは実際にUTF-8である必要があります。[ 2 ] [ 1 ]
仕様書では、「エンコーディングスニッフィングアルゴリズム」が定義されており、以下の複数の入力ソースに基づいて文書の文字エンコーディングを判定します。
印刷可能なASCII範囲（32～126）外の文字は、文書が誤った文字エンコーディングで配信された場合、正しく表示されないことがあります。これは英語圏のユーザーにとってはほとんど問題になりませんが、他の言語では、この範囲外の文字が頻繁に、場合によっては常に必要となります。中国語、日本語、韓国語（CJK ）など、複数の異なるマルチバイトエンコーディングが使用されている言語環境では、自動検出がよく用いられます。また、ブラウザでは通常、ユーザーが誤った文字セットラベルを手動で上書きすることも可能です。
UTF-8は2008年以来、Web上で最も一般的な文字エンコーディングとなっています。その理由の一つは、 Unicodeのエンコーディングであるため、すべての言語で同じエンコーディングを使用できるからです。2026年1月現在 UTF-8 は W3Techs が調査した Web サイトの 98.9% で使用されています。[ 7 ] UTF-16やUTF-32などの Unicode のその他のエンコーディングは、バイト指向のASCII スーパーセット エンコーディングを前提とするプログラミング言語では扱いが難しく、HTML ドキュメントのように ASCII 文字が頻繁に出現するテキストでは効率が悪いため、あまり広く使用されていません。
ページの表示に成功したからといって、必ずしもエンコーディングが正しく指定されているとは限りません。ページの作成者と閲覧者の両方がプラットフォーム固有の文字エンコーディングを前提としており、サーバーが識別情報を提供しない場合、閲覧者は作成者の意図どおりにページを表示できますが、異なるプラットフォームや異なる母国語を使用する他の閲覧者は、意図どおりにページを表示できません。
廃止されたW3C標準のバージョン5.3と現在の（2026年時点）WHATWG Living StandardはどちらもUTF-8を要求します。他のエンコーディングは有効とはみなされません。[ 1 ] [ 2 ]ただし、実装は堅牢性の原則に従って、どのエンコーディングをドキュメントに適用するかを決定するためにエンコーディングスニッフィングアルゴリズムを使用する必要があります。
両方の標準で参照されているWHATWGエンコーディング標準は、ブラウザがサポートしなければならないエンコーディングのリストを規定しています。HTML 標準は、他のエンコーディングのサポートを禁止しています。[ 8 ] [ 9 ] [ 10 ]エンコーディング標準はさらに、新しいフォーマット、新しいプロトコル (既存のフォーマットを使用する場合でも)、および新しいドキュメントの作成者は、UTF-8のみを使用することが義務付けられていると規定しています。[ 11 ]
UTF-8 に加えて、以下のエンコーディングがエンコーディング標準を参照して HTML 標準自体に明示的にリストされています。[ 10 ]
TIS-620ISO-8859-11ASCIIISO-8859-1ISO-8859-9関連ラベルについても指定されています。 [ 11 ]UTF-16ラベルにも指定されていますが、 [ 23 ]バイト オーダー マーク(BOM) が存在する場合は、どのラベルよりも優先されます。 [ 24 ]デコードのみに指定されています。UTF-16 でエンコードされたドキュメントからのフォーム送信はUTF-8でエンコードされます。 [ 22 ]以下の追加のエンコーディングはエンコーディング標準に記載されており、したがってそれらのサポートも必要です。[ 11 ]
KOI8-U。KOI8-RU[ 11 ]は、位置 0xAE および 0xBE (つまりЎ/ўを含む)でKOI8-RUに続きます[ 27 ] [ 28 ]しかし、位置 0x93–9F では KOI8-U になります。 [ 27 ]GB2312と同じように扱われます。 [ 29 ]エンコード目的では、GBK (またはGB 2312 ) としてラベル付けすると、4 バイトのコードが除外され、U+20AC には 1 バイトの 0x80 表現が優先されます。 [ 12 ]以下のエンコーディングは、禁止されているエンコーディングの明示的な例として挙げられています。[ 10 ]
この規格では、「置換」デコーダも定義されており、特定のエンコーディングとしてラベル付けされたすべてのコンテンツを置換文字（�）にマッピングし、処理を一切拒否します。これは、クライアントとサーバー間でサポートされているエンコーディングの違いを利用して悪意のあるコンテンツを隠蔽する可能性のある攻撃（クロスサイトスクリプティングなど）を防ぐことを目的としています。 [ 31 ] ASCII バイトのシーケンスを異なる方法で解釈できるISO-2022-JPとUTF-16にも同じセキュリティ上の懸念がありますが、これらは展開されたコンテンツで比較的頻繁に使用されるため、このアプローチは実現可能とは見なされませんでした。[ 32 ]次のエンコーディングはこの処理を受けます。[ 33 ]
ネイティブ文字エンコーディングに加えて、文字は文字参照としてエンコードすることもできます。文字参照は、数値文字参照（10進数または16進数）または文字実体参照のいずれかです。文字実体参照は、名前付きエンティティ、またはHTMLの場合はHTMLエンティティと呼ばれることもあります。HTMLにおける文字参照の使用はSGMLに由来します。
HTML の数値文字参照は、 Universal Character Set / Unicodeコードポイントで文字を参照し、次の形式を使用します。
&#nnnn;または
&#xhhhh;ここで、nnnnは10 進数形式のコードポイント、hhhhは16 進数形式のコードポイントです。XML文書では、x は小文字でなければなりません。nnnnまたはhhhh は任意の桁数で、先頭にゼロを含めることができます。hhhh は大文字と小文字を混在させることができますが、通常は大文字を使用します。
HTML文書の受信者が使用するすべてのWebブラウザや電子メールクライアント、あるいはHTML文書の作成者が使用するテキストエディタが、すべてのHTML文字を正しく表示できるとは限りません。最新のソフトウェアのほとんどは、ユーザーの言語の文字のほとんど、あるいはすべてを表示でき、表示できない文字については枠線などの分かりやすい表示で示します。
0から127までのコード（元の7ビットASCII標準セット）では、これらの文字のほとんどは文字参照なしで使用できます。160から255までのコードはすべて文字実体名を使用して作成できます。数値が大きいコードのうち、実体名を使用して作成できるのはごく一部ですが、すべて10進数文字参照で作成できます。
文字実体参照は、名前が大文字小文字を区別する英数字文字列である形式を持つこともできます。たとえば、「λ」はHTML 文書では のようにエンコードすることもできます。文字実体参照、、およびは、、 、 および がマークアップの区切りにすでに使用されているため、 HTML および SGML で定義されています。これは特に、 HTML5より前の XML の (') エンティティを含みませんでした。名前付きのすべての HTML 文字実体参照と、それらが導入されたバージョンのリストについては、「XML および HTML 文字実体参照のリスト」を参照してください。&name;λ<>"&<>"&'
HTML の文字参照を不必要に使用すると、HTML の可読性が著しく低下する可能性があります。Web ページの文字エンコーディングが適切に選択されていれば、HTML の文字参照は通常、前述のマークアップ区切り文字といくつかの特殊文字にのみ必要となります ( UTF-8のようなネイティブUnicodeエンコーディングが使用されている場合はまったく必要ありません)。HTML エンティティのエスケープが不適切だと、クロスサイトスクリプティングなどのインジェクション攻撃に対するセキュリティ脆弱性が生じる可能性もあります。HTML 属性を引用符で囲まない場合、スペースやタブなどの特定の文字、特に空白文字は、エンティティを使用してエスケープする必要があります。HTML に関連する他の言語には、文字をエスケープするための独自の方法があります。
文字実体参照の範囲が広い従来の HTML とは異なり、XMLには定義済みの文字実体参照が 5 つしかありません。これらは、特定のコンテキストでマークアップに敏感な文字をエスケープするために使用されます。[ 34 ]
その他の文字実体参照はすべて、使用する前に定義する必要があります。たとえば、éXML 文書で (é、ラテン文字の小文字の E、アキュートアクセント付き、Unicode では U+00E9) を使用すると、実体が既に定義されていない限りエラーが発生します。また、XML では、x16 進数値参照の は小文字である必要があります。たとえば、ਛではなく ですਛ。XMLアプリケーションであるXHTMLは、XML の事前定義された実体とともに HTML 実体セットをサポートしています。