Copyright © 2004-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本文書は、World Wide Webの文字モデル1.0：基礎 [CHARMOD]を基盤として、 仕様作成者、ソフトウェア開発者、およびコンテンツ開発者に、World Wide Web上の文字列同一性 照合に関する共通の参照情報を提供し、それによって相互運用性を向上させます。
この節では、公開時点における本文書の位置付けについて 説明します。現在のW3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C標準および草案の 索引にあります。
コメントを追跡しやすくするため、コメントごとに個別の課題またはメールを作成し、URLを使用して コメント対象の節を示してください。
本文書は、国際化 ワーキンググループによって、 勧告 標準化過程を使用する初回公開作業草案として公開されました。
初回公開作業草案としての 公開は、W3Cおよびその会員による 承認を意味するものではありません。
本文書は草案であり、いつでもほかの文書によって更新、置換、または廃止される 可能性があります。本文書を進行中の作業以外のものとして引用することは 不適切です。
本文書は、 W3C 特許 方針に基づいて活動するグループによって作成されました。 W3Cは、このグループの成果物に関連して行われた 特許開示の 公開一覧を管理しており、 そのページには特許を開示するための 手順も記載されています。本人が 必須クレームを含むと考える特許を 実際に知っている場合、その者は W3C特許方針の第6節に従って情報を開示しなければなりません。
本文書には、 2025年8月18日付のW3Cプロセス文書が適用されます。
World Wide Webの文字モデルの目的は、W3Cのユニバーサルアクセスという目標に従い、 言語、用字系、書記体系、または文化的慣習にかかわらず、すべての人々によるウェブの利用を促進することです。この目標を 達成するための基本的な前提条件の一つは、世界中で使用される文字を、明確に定義され、十分に理解された方法で 送信および処理できることです。
本文書は、World Wide Webの文字モデル：基礎 [CHARMOD]を基盤としています。 本文書を正しく理解し適用するには、その文書に記載された概念を理解することが重要です。
World Wide Webの文字モデルのこの部分では、文字列 照合、すなわち仕様または実装が二つの文字列値を 同一または異なるものとして定義する処理を扱います。この部分では、 意味的に等価なテキストが異なる方法で符号化される仕組みと、それが 形式言語（ウェブを構成する形式や プロトコルで使用されるものなど）にとって重要な照合処理に与える影響について 説明します。
この仕様の主な対象読者は、W3C仕様の 開発者です。この仕様またはその一部は、 他のW3C仕様から参照でき、W3C 仕様およびその他の仕様に対する適合基準を 定義します。
この仕様のその他の対象読者には、ソフトウェア開発者、 コンテンツ開発者、およびW3C以外の仕様作成者が含まれます。 ソフトウェア開発者およびコンテンツ開発者は、W3C 仕様を実装し、使用します。この仕様は、W3C 仕様を実装および使用する実装（ソフトウェア）とコンテンツに対して、いくつかの適合基準を 定義します。また、ソフトウェア開発者およびコンテンツ 開発者が、W3C 仕様における文字関連の規定を理解するのにも役立ちます。
この仕様で説明する文字モデルは、仕様作成者、 ソフトウェア開発者、およびコンテンツ開発者に、 World Wide Web上で一貫性と相互運用性のあるテキスト操作を行うための 共通の参照情報を提供します。これら三つのグループが協力することで、 世界中からアクセス可能なウェブを構築できます。
本文書は、文書形式における文字列 同一性照合の規則および処理を定義することにより、この問題に関連する ウェブの基本的な構成要素の一つを定義します。これらの規則は、 文書形式で使用される識別子および構造的マークアップ（構文コンテンツ）を 一貫して処理できるように設計されており、 仕様作成者を対象としています。この 節は実装者を対象としています。
本文書は、主に二つの節に分かれています。
第1の節では、 文字列照合に関わる問題、これらの問題に対するUnicodeおよびケース フォールディングの影響、ならびにそれらの問題に対処するために 使用できるさまざまな問題点および正規化機構の概要を示します。
第2の節では、 W3C仕様で定義される多くの文書形式などの 形式言語で使用する文字列同一性照合の 要件および推奨事項を示します。これは主に、 ウェブを機能させ、文書 作成者に一貫した結果を提供することを目的としています。
この節では、この仕様で扱う主題に関する 歴史的背景を示します。
文字モデルの中核には、Unicode標準 [Unicode]およびISO/IEC 10646 [ISO10646]によって共同で定義された、 Universal Character Set（UCS）があります。 本文書では、Unicodeを Universal Character Setの同義語として使用します。適切な 文字モデルにより、世界中の書記体系、用字系、および言語で （かつ異なるプラットフォーム上で）作成されたウェブ文書を、 世界中のウェブ利用者が交換、閲覧、および検索できるようになります。
Unicode標準の最初の数章 [Unicode]は、有用な背景資料です。
この仕様の重要な部分の開発に影響を与えた要件については、 文字列同一性照合および文字列索引付けの要件 [CHARREQ]を参照してください。
この節では、本文書に固有の用語および表記法を示します。
ウェブは、テキストベースの形式およびプロトコル上に構築されています。 文字列の照合または検索を効果的に説明するには、 要件および詳細が大きく異なるため、 特定の形式またはプロトコル内の異なる種類のテキストについて 議論できる用語を確立する必要があります。
Unicodeコードポイント（または「コードポイント」）とは、
各Unicode文字に割り当てられた数値を指します。Unicodeコードポイントの範囲は、0から
0x10FFFFまでです。（文字符号化に関する用語の
詳細については、[CHARMOD]の第4.1節を
参照してください。）
Unicodeコードポイントは、U+hhhhとして表記します。ここで、hhhhは、4桁以上6桁以下の
16進数です。たとえば、文字€ [U+20AC EURO
SIGN]のコードポイントはU+20ACであり、文字😺 [U+1F63A SMILING CAT FACE WITH OPEN
MOUTH]のコードポイントはU+1F63Aです。
本文書の例で使用される一部の文字は、特定のデバイスまたは ディスプレイ上で意図したとおりに表示されないことがあります。通常、これは用字系固有のフォントが ローカルにインストールされていないこと、または使用しているレンダリングシステムの その他の制限によるものです。本文書では、多くの非ラテン文字に 代替グリフを提供するためにウェブフォントを使用していますが、使用しているデバイスがそのフォントの表示を サポートしていない可能性があります。編集者は、可能な限り、 それでも例を理解できるように努めています。
従来の文字エンコーディングとは、 Unicode文字集合のすべての文字レパートリを符号化しない 文字符号化形式です。
トランスコーダとは、二つの文字エンコーディング間で テキストを変換する処理です。本文書では通常、 従来の文字エンコーディングから、 UTF-8などのUnicode符号化 形式へ変換する処理を指します。
自然言語とは、人間が使用する音声、文字、または手話による コミュニケーションです（こちら [LTLI]も参照してください）。
構文コンテンツとは、文書形式 またはプロトコル内にある、その形式またはプロトコルの構造に属するあらゆるテキストです。この定義には、 通常「マークアップ」と考えられる値が含まれますが、HTTPヘッダーのフィールド名など、 その他の値も含まれることがあります。構文コンテンツは、形式またはプロトコルの 構造を形成するすべての文字で構成されます。たとえば、<および>（ならびにそれらが囲む要素名および各種属性）は、 HTML文書内の構文コンテンツの一部です。
構文コンテンツは通常、一つ以上の仕様によって定義され、 特定のプロトコルまたは形式に対して定義された予約キーワードと、 文書作成者が文書の構造（文書の「コンテンツ」ではなく）を形成するために 定義する文字列トークンおよび識別子の両方を含みます。
語彙とは、予約キーワードの一覧、および／または形式もしくは プロトコルでユーザー指定値（識別子など）を割り当てるための規則です。 これには、異なる位置に出現できる文字の範囲、順序、または種類に関する 制限が含まれることがあります。
たとえば、HTMLは要素名、属性名、および列挙属性の 値を定義しており、これによってHTMLの構文コンテンツの「語彙」が定義されます。 別の例としてECMAScriptがあります。ECMAScriptでは、識別子または変数名の先頭や 本体に出現できる文字の範囲を制限します。また、文字列リテラルの値など、 その他の場合には異なる規則を適用します。
語彙内の値は、大きく二つのクラスに分けられます。人間が 閲覧、読解、または操作することを目的とするもの（したがって自然言語テキストを含むことが 期待されるもの）と、アプリケーションまたはプロトコル内部で使用され、 人間による操作を目的としないものです。
ユーザー向け識別子とは、 語彙内でユーザーによって定義または割り当てられ、 少なくともエンドユーザーに表示される可能性があることを意図した識別子です （したがってローカライズ可能なコンテンツです）。
アプリケーション内部識別子とは、 語彙内でユーザーによって定義または割り当てられ、 文書形式またはプロトコルの内部で使用され、人間による操作を目的としない識別子です。 このような値は通常、ローカライズ可能なコンテンツではありません。
ユーザー指定値とは、
特定の形式またはプロトコルにおける予約キーワードとは異なり、
ユーザーによって割り当てられる、語彙内の予約されていない構文コンテンツです。ユーザーは一般に、
ユーザー指定値として、好みの自然言語の単語または語句を使用できることを期待します。
このため、[CHARMOD]は、
「仕様は、U+0000からU+10FFFFまでを含むUnicodeコードポイントの
全範囲から、コードポイントを恣意的に除外するべきではない（SHOULD NOT）」と推奨しています。
ローカライズ可能な
コンテンツとは、人間が読むことを意図した文書コンテンツを指し、文書構造の一部を形成する
周囲または埋め込みの構文コンテンツを指すものではありません。構文コンテンツの内部に
ローカライズ可能なコンテンツを埋め込むこともできます。たとえば、[HTML]のimg要素に画像の説明を含むalt属性がある場合です。
本文書の文脈におけるリソースとは、ローカライズ可能なコンテンツと、
それを囲むか内部に含む識別子などの構文コンテンツの両方を含む、特定の文書、ファイル、または
プロトコルの「メッセージ」です。たとえば、CSSと、JavaScriptが埋め込まれたいくつかのscriptタグも含むHTML文書では、ファイルとして考えたHTML文書全体が
リソースです。この用語は、[RFC3986]で使用される
「リソース」という用語と意図的に類似していますが、ここでは緩やかに適用されます。
書記素とは、テキストの視覚表現において、
一般的な利用者が単一の単位（文字
）として認識する、
一つ以上の文字の列です。
書記素は、並べ替えやテキスト選択などの多くのテキスト処理で重要であるため、
利用者が認識する各文字間の境界を計算できる必要があります。
Unicodeは、Unicode
Standard Annex #29: Text Segmentation [UAX29]で
書記素を計算する既定の機構を定義し、この近似を書記素クラスタと呼びます。既定の書記素クラスタには
二つの種類があります。特に記載がない限り、本文書の書記素
クラスタは、拡張既定書記素
クラスタを指します。（書記素クラスタについては、Unicode標準の第2章
[Unicode]でも説明されています。
Unicode標準バージョン8.0の
第2.11節の末尾付近も参照してください。）
自然言語ごとに異なる要件があるため、書記素クラスタにも 調整が必要になる場合があります。たとえば、スロバキア語の利用者は、 既定では二つの書記素クラスタである「ch」を一つの 書記素クラスタとして扱うことを望むかもしれません。文字列コンテンツの言語と エンドユーザーの設定との相互作用は、複雑になる可能性があることに注意してください。
この節では、上記で定義した用語の一部を例示します。説明のため、次の小さなHTMLファイルを 例として使用します（参照用に行番号を追加しています）。
1 <html lang="en" dir="ltr">
2 <head>
3 <meta charset="UTF-8">
4 <title>Shakespeare</title>
5 </head>
6 <body>
7 <img src="shakespeare.jpg" alt="William Shakespeare" id="shakespeare_image">
8 <p>What’s in a name? That which we call a rose by any other name would smell as sweet.</p>
9 </body>
10 </html>
’は、 構文コンテンツの一部です。）
William Shakespeare）も ローカライズ可能なコンテンツです。
上記のすべてのテキスト（テキストファイル内のすべてのテキスト）がリソースを構成します。
特定のリソースにローカライズ可能なコンテンツが
一切含まれない場合もあります（オレンジ色の長方形としてスタイル設定された、
四つの空のdiv要素からなるHTML文書を考えてください）。
また、リソースに構文コンテンツが一切なく、ローカライズ可能なコンテンツのみで
構成される場合もあります。たとえば、Hamletの独白を含むプレーンテキストファイルです。
また、HTMLエンティティ’がローカライズ可能なコンテンツ内に出現し、
このリソースではローカライズ可能なコンテンツと構文コンテンツの両方に属することにも注意してください。
非規範的と明記された節に加えて、この仕様内のすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のその他すべての内容は規範的です。
本文書におけるキーワードMAY、MUST、MUST NOT、OPTIONAL、RECOMMENDED、SHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で表記されている場合に限り、 BCP 14 [RFC2119] [RFC8174]に 記載されているとおりに解釈されます。
本文書では、他の仕様の作成者向けのベストプラクティスと、 実装およびコンテンツ作成者向けの推奨事項について説明します。これらのベストプラクティスは、 国際化ワーキンググループの文書仕様開発者のための国際化ベストプラクティス [INTERNATIONAL-SPECS]にも 記載されています。この文書は、W3C仕様におけるすべての国際化ベストプラクティスの 一般的な参照情報として使用することを目的としています。
本文書のベストプラクティスでは、特定の推奨事項に関する 国際化ワーキンググループの意図を明確にするために、[RFC2119]のキーワードを使用します。 本文書の推奨事項に従うことで、W3Cの「広範なレビュー」過程、実装時、または 作成者が制作するコンテンツにおける問題を回避できます。本文書自体は規範的ではなく、 随時改訂されることがあります。
仕様は、次の条件を満たす場合、本文書への適合を主張できます。
仕様に課される要件は、その仕様への適合を主張する実装またはコンテンツに 間接的に要件を課す可能性があります。
この仕様に手続き的な説明が含まれる場合、それは望ましい外部動作を指定する方法として 理解されるものとします。観測可能な動作に影響しない限り、実装は同じ結果を達成するために その他の手段を使用してもよい（MAY）です。
ウェブは主に、文字データに基づく文書形式およびプロトコルで 構成されています。これらの形式またはプロトコルは、何らかの構造的マークアップまたは 構文コンテンツを含む テキストファイルを主として構成されるリソースの集合とみなすことができます。 このような構文コンテンツまたは文書データの処理には、 照合（正規表現を含む）、索引付け、検索、並べ替えなどの 文字列ベースの処理が必要です。
利用者、特に実装者は、類似する文字列が照合されるかどうか、または テキストに適用するさまざまな変換の有効性について、 単純すぎる期待を抱くことがあります。これは特に構文コンテンツに当てはまりますが、 ウェブ上の多くの種類のテキスト処理にも当てはまります。
ウェブは根本的に、文書内でテキストが表現されるさまざまな方法に影響されるため、 同じテキストを表現する異なる方法を考慮しないと、 利用者を混乱させたり、予期しない、または不満を招く結果を引き起こしたりする可能性があります。 以下の節では、ウェブ上のテキストに対する利用者の認識と、 ウェブが依存する文字列処理の両方に影響する、 さまざまな種類のテキストの相違を検討します。
一部の用字系および書記体系では、大文字、小文字、およびタイトルケースの文字を区別します。 インドのブラーフミー系用字系、アラビア文字、中国語、日本語、または韓国語の表記に使用される 用字系を含む大部分の用字系には、大文字と小文字の区別がありませんが、 一部の重要な用字系には区別があります。このような用字系の例には、 本文書の大部分で使用されているラテン文字のほか、ギリシャ文字、アルメニア文字、 キリル文字などがあります。
ケースマッピングとは、 文字を大文字、小文字、またはタイトルケースなど、特定の文字ケースに変換する処理です。 大文字と小文字を区別する用字系について、Unicodeは各Unicodeコードポイントの 既定の大文字、小文字、およびタイトルケースの文字マッピングを定義します。 ケースマッピングは一見単純に見えます。しかし、多様な言語にわたるUnicodeの全範囲を 処理する場合に考慮する必要がある相違があります。
ケース フォールディングとは、大文字と小文字だけが異なる二つのテキストを、比較のために同一にする処理です。 すなわち、文字列照合を目的とします。これは、主に表示を目的とするケースマッピングとは異なります。 既定のケースマッピングと同様に、Unicodeは各Unicodeコードポイントに対する 既定のケースフォールドマッピング（「ケースフォールディング」）を定義します。 Unicodeは二つの形式のケースフォールディングを定義しており、以下で検討します。
大部分の用字系には大文字と小文字の区別がないため、ケースマッピングと同様に、
大部分のUnicodeコードポイントにはケースフォールディングが必要ありません。
ケースフォールディングを持つコードポイントの大部分は、単純かつ直接的に、
別の一つの対応する（通常は小文字の）コードポイントへマッピングされます。Unicodeは、
Unicodeが定義する両方の種類のケースフォールディングに含まれるため、このフォールディングの集合を
commonと呼びます。
少数の文字には、一つのUnicodeコードポイントを二つ以上のコードポイントへマッピングする
ケースフォールディングがあります。このケースフォールディングの集合は、full
ケースフォールディングと呼ばれます。fullおよびcommonケースフォールディングは、
Unicode全体に既定のケースフォールディングを提供するために一緒に使用されます。本文書では、
この形式のケースフォールディングを完全
ケースフォールディングまたはUnicode完全と呼びます。
一部のアプリケーションは、ケースフォールド処理の実行時に追加の記憶域を
割り当てることができないため、Unicodeは、通常はより多いか少ないコードポイントへ
フォールドされるコードポイントを、代わりに比較用の一つのコードポイントへマッピングする
simpleケースフォールディングを提供します。
完全フォールディングとは異なり、このフォールディングは常にテキストの内容
（および場合によっては意味）を変更します。完全ケースフォールディングと同様に、単純
ケースフォールディング、すなわちUnicode単純ケースフォールドは、Unicodeの全範囲を対象とするため、
simpleおよびcommonマッピングを組み合わせたものです。
Unicode単純は、ウェブでの使用には適していません。
ケースフォールディングは、後から復元できない情報を文字列から削除することに注意してください。 たとえば、ドイツ語の二つのsが、フォールド前のテキストで必ずしも ßを表すとは限りません。
ケースマッピングおよびケースフォールディングのもう一つの側面は、言語に依存する可能性があることです。 Unicodeは、符号化された各文字について既定のケースマッピングおよび ケースフォールディングを定義しますが、これらは既定値にすぎず、 すべての場合に適切なわけではありません。一部の言語では、特定の言語的要件を 満たすためにケースマッピングを調整する必要があります。その一例は、 ラテン文字で書かれるテュルク諸語です。
上記の例（および本文書全般）は照合を目的とするケースフォールディングに焦点を当てていますが、
ケースマッピングも言語固有であることに注意してください。トルコで二番目に大きい都市の名称は
「Diyarbakır」であり、点付きと点なしの両方のiを含みます。
一部の文書形式またはプロトコルは、相互運用性を支援するため、またはコンテンツ作成者を支援するために、 定義する語彙や、 形式またはプロトコルで許可されるユーザー指定値における文字ケースの相違を無視します。
文字ケースは、意味的に重要ではない方法で変化する場合や、 利用者が完全には制御できない方法で変化する場合があります。これは特に 文書を検索する場合に当てはまりますが、識別子など、 利用者またはコンテンツによって生成された値を照合する規則を定義する場合にも 当てはまることがあります。このような状況では、代わりに大文字と小文字を 区別しない照合が望ましい場合があります。
語彙を定義するときの重要な考慮事項の一つは、 値がUnicodeのASCII [ASCII] サブセットに制限されるか、または語彙が、より複雑なケースフォールディング要件を持つ可能性のある 文字（ラテン文字のアクセント付き文字や、非ラテン用字系を含む広範なUnicodeなど）の使用を 許可するかどうかです。これらの異なる要件に対応するため、本文書では、 文書形式またはプロトコルにおける文字列同一性照合を目的として、 四つの種類のケースフォールド照合を定義します。
大文字と小文字を 区別する照合：ケースフォールディングを行わず、コードポイントを直接比較します。
ASCIIの 大文字と小文字を区別しない照合は、[INFRA]で定義されています。この定義では、 0x41から0x5A（AからZ）の範囲のすべてのASCIIコードポイントが、 0x61から0x7A（aからz）の対応するコードポイントへマッピングされたものとして、 二つのコードポイント列を比較します。語彙自体がASCIIに制限されている場合は、 ASCIIの大文字と小文字を区別しない照合が必要になることがあります。
Unicodeの 大文字と小文字を区別しない照合は、両方の入力列にUnicode完全ケースフォールディング（上記参照）が 適用されたものとして、二つのコードポイント列を比較します。
言語依存の 大文字と小文字を区別する照合は、文書形式またはプロトコルに 構文コンテンツの言語に関する情報が含まれ、言語依存のケースフォールディングを 適切に適用できるまれな場合に有用です。これらのケースフォールディングは、 UnicodeコンソーシアムのCommon Locale Data Repository [UAX35]プロジェクトで定義されています。
ケースフォールディングを処理する方法については、3.2.6 ケースフォールディングに関する追加の考慮事項を参照してください。
Unicodeテキストでは、別の種類の相違が発生することがあります。同じ抽象文字を表すために、 複数の異なるUnicodeコードポイント列を使用できる場合があります。 コードポイントを比較してテキストを検索または照合するとき、これらの符号化の相違により、 利用者が同じであると期待するテキスト値が照合しなくなります。
異なるコードポイント列を使用するテキスト間の意味的等価性を アプリケーションが検出する必要があるため、Unicodeは、意味的に等価な二つのテキストを 同一にする手段としてUnicode正規化形式 [UAX15]を定義します。
リソースは、これらの相違の影響を受けやすいことがあります。 ウェブ上の仕様および実装がテキストのUnicode正規化を要求していないことや、 後で構文コンテンツ（ユーザー指定値を含む）およびローカライズ可能なコンテンツを処理する際に使用される 文字列照合アルゴリズムを考慮していないことが理由です。このため、コンテンツ開発者は、 後の問題を回避するために、一貫した表現を提供していることを確認する必要があります。
しかし、テキストとして表示した場合には通常その違いが見えないため、 特定のリソースまたはリソース集合が 一貫したテキスト表現を使用していることを、利用者が保証するのは困難な場合があります。 したがって、ツールおよび実装は、視覚的または論理的に等価で、 利用者の考えでは照合「するはず」の文字列が異なる値として扱われるときに、 利用者が経験する困難を考慮する必要があります。 利用者がこれらの違いを確認し、必要に応じて正規化できる手段を提供することで、 ソース文書内の目に見えない違いから生じる失敗をエンドユーザーが回避できます。 たとえば、HTML文書がUnicode正規化形式Cに完全には準拠していない場合、 W3C Validatorは警告を表示します。
Unicodeは、文字間の二つの種類の等価性、すなわち正準等価性および 互換等価性を定義します。
正準 等価性とは、同じ抽象文字を表すUnicodeコードポイントまたはUnicodeコードポイント列間の 基本的な等価性です。正準等価な列は、理想的には同じ視覚的外観を持つべきですが （多少異なって見える原因は多数あります）、同一であるかのように扱い、処理する必要があります。 Unicodeは、異なる方法で符号化されているものの正準等価である二つのテキスト間の 主要な相違を取り除く、正準分解という処理を定義します。
Unicodeによって定義される正準等価性の例には、次のものがあります。
互換等価性とは、同じ抽象文字を表すUnicode文字または Unicode文字列間の、より弱い等価性であり、視覚的外観または動作が異なる可能性があります。 一般に、互換分解という処理は、上付き、下付き、回転、 丸囲みなどの書式上の相違を取り除きますが、その他の相違も存在します。 多くの場合、互換分解を持つ文字は意味的な相違を表します。 したがって、異なる文字の使用を互換分解で置き換えると、 テキストの意味が変化する可能性があります。互換分解後に等価となるテキストは、 それ以前には同一であると認識されないことが多く、形式言語では等価として 扱うべきではありません（SHOULD NOT）。
上記の表で重要なのは、示されている文字が、 文脈またはスタイルによる単なる表示上の相違ではなく、実際のUnicodeコードポイントであることです。 各文字は、さまざまな従来の文字エンコーディングとの互換性のためにUnicodeへ符号化されました。 これらは、非互換文字に対して通常行われる表示処理と混同しないでください。
たとえば、アラビア文字のテキストの大部分は、Unicodeのアラビア文字ブロック （U+0600から始まります）の文字を使用します。 テキストの表示に実際に使用されるグリフは、「シェーピング」と呼ばれる処理で、 単語内の位置（語頭、語中、語末、または独立）に基づき、 フォントおよびテキスト処理ロジックを使用して選択されます。上記の表には、 アラビア文字ه [U+0647 ARABIC LETTER HEH]の四つの表示形式が示されています。 示されている文字は、U+FE00ブロック内の互換文字であり、 それぞれが特定の「位置的」字形を表します。示されている四つのコードポイントは、 いずれも「通常の」アラビア文字ه [U+0647 ARABIC LETTER HEH]への互換分解を持ちます。これらの表示形式は、 等価な表示形式を含む従来の文字エンコーディングとの 往復符号化変換をサポートするためだけに使用することを意図しています。 それ以外の場合、「heh」という一連の文字を含む文字列は、単に一連の U+0647コードポイントとして符号化され、 レンダリングシステムおよびフォントが適切な字形を提供します。
同様に、半角形式と全角形式の相違、および回転文字 （縦書きで使用するもの）は、主に従来の文字エンコーディングとの互換性のために、 別個のコードポイントとして符号化されています。多くの場合、これらの相違は、 East Asian Width [UAX11]で説明されるUnicodeプロパティに 関連付けられています。縦書きの表示形式については、Unicode Vertical Text Layout [UAX50]も参照してください。
上記に示したような互換分解を持つ文字の場合、 K Unicode正規化形式は、 テキストを「通常」または「期待される」Unicodeコードポイントへ変換します。 しかし、これらの互換文字の存在から、通常のテキストレイアウトおよび表示で生成される 類似した外観の相違もUnicode正規化の影響を受けると考えることはできません。 そのような相違は影響を受けません。
Unicodeが定義するこれら二つの種類の等価性は、さらに別の相違の組、 「分解」と「合成」によって分類されます。「分解」では、視覚的な文字の分離可能な論理部分を、 基底文字と結合記号の列に分解し、その結果のコードポイントを固定された正準順序に配置します。 「合成」では、分解を実行した後、特定の規則に従って、 結合記号を基底文字と再結合します。
大まかに言えば、NFCは、 各結合文字列（基底文字の後に一つ以上の結合文字が続くもの）を、 可能な限り正準等価な合成済み文字で置き換えるように定義されています。
これが何を意味しないかに注意することは非常に重要です。 すべての文字列に合成済みの等価文字があるわけではないため、 結果の文字列には結合記号が含まれる場合があります。実際、前述のとおり、 この例のデーヴァナーガリー母音など、 多くの用字系では結合記号を使用する以外の方法がありません。 その他の場合、特定の基底文字と結合記号の組み合わせは、 正規化規則によって合成が阻止されるため、合成済み文字で置き換えられません。 たとえば、一部のインド系用字系は、対応する合成済み文字が存在する場合でも、 合成除外規則により、基底文字と発音区別符号の特定の列を合成しません。 通常であれば結合する二つの文字の間に別の結合記号がある場合にも、 合成が阻止されることがあります。
Unicode正規化形式には四つあります。各形式には文字コードを使用した名称があります。
Unicode正規化は、これらの列（および同じ文字を表すその他の可能な エスケープ列）を、わずか三つの相違に減らします。しかし、Unicode正規化は すべてのテキスト上の区別を取り除くわけではなく、Unicode正規化を適用すると、 特定の文脈で区別される、または意味を持つ内容が失われる場合があります。たとえば、次のとおりです。
NFKDまたはNFKC）の一つを使用して
正規化すると、ASCII文字列81/2になります。
多くの利用者は、外観が同一の二つの文字列（特定のUnicode正規化形式を
適用した文字列を含む）が、実際には同じ基礎となるUnicodeコードポイントを
使用していない可能性があることに驚きます。これには、より破壊的なNFKCおよび
NFKD互換正規化形式を適用した文字列も含まれます。文字列、トークン、または識別子が
視覚的に同じに見える場合でも、異なる方法で符号化されている可能性があります。
Unicodeの正準正規化形式は、特定の抽象文字または書記素クラスタに使用できる
複数の異なるコードポイント列を、同じコードポイント列へまとめることを目的とします。
しかし、論理的に異なる文字または書記素クラスタが、依然として同じ、または非常に似て
見える場合があります。一組の書記素が同一（または非常に類似）に見える場合、それらは
同形異字と呼ばれます。一組の書記素が類似して見えるか、
同形異字であるものの、実際には論理的に異なる文字または
文字列を表す場合、それらは紛らわしい
と呼ばれます。
同一または同一に見える外観の例は、一つの用字系内でも発生する可能性があります。 これは、「0」と「O」または「l」と「1」など、形状が類似する文字として現れることがあります。 しかし、その他の用字系または異なる互換文字の使用では、区別がはるかに困難な相違が生じる場合があります。 Unicode正規化によってこれらが同一になる場合もありますが、そうならない場合も多数あります。
外観が同一または紛らわしい
文字は、なりすましやその他のセキュリティリスクを
引き起こす可能性があります。これは、一つの用字系内でも、異なる用字系にある類似文字間でも
当てはまります。同形グリフおよび紛らわしさに関する詳細な説明と例については、
[UTS39]が有用な参照資料です。
同一または類似して見える文字に加えて、反対の問題も存在します。
Unicode正規化は、NFKCおよびNFKD互換形式であっても、
本質的な意味または機能は同じであるものの、外観または使用法が異なる文字を
同一にはしません。たとえば、U+002E（.）とU+3002（。）は、
どちらも文末の句読点として機能しますが、それぞれが異なる同一性を持つため、
正規化によって区別が取り除かれることはありません。
大文字と小文字を区別しない方法で文字列を照合するときの複雑な点の一つは、 元の文字列が正規化されていた場合でも、ケースフォールディング処理によって 正規化されていない文字列が生成される可能性があることです。 文字列比較はコードポイント列の照合に依存するため、照合処理を信頼できるものにするには、 ケースフォールディングされた各文字列を正規化する必要があります。
Unicodeの正準正規化形式（NFCまたはNFD）と ケースフォールディングは、一緒に使用すると閉じています。文字列にケースフォールディングを行い、 その後NFDまたはNFCを適用すると、 同じケースフォールディングまたはUnicode正規化形式をさらに適用しても、 異なる文字列にはなりません。
文字間の互換等価性 （すなわち、NFKC/NFKD形式）を比較するときは、 ケースフォールドと正規化の処理を二回実行する必要があります。 これは、互換分解の手順によってケースフォールディングが必要な文字が生成される可能性があり、 その後のケースフォールドによって、さらに正規化する必要がある列が生成される可能性があるためです。
Unicodeによる正準ケースフォールド照合（規則[D145]）および
互換ケースフォールド照合（規則[D146]）の定義には、
複数の正規化手順が含まれています。これにより、大文字と小文字を区別しない照合を
実行する複雑さとコストが増加します。ケースフォールディングを実行する前の
最初の正規化手順は、本文節で詳しく説明する特定の特殊な場合に対処します。
Unicodeのケースフォールド照合処理の最後の正規化手順は、 結果の文字列が特定のUnicode正規化形式になることを保証するために存在します。 結果のケースフォールディングされた文字列を保存または利用者へ表示する場合、 ケースフォールド処理によって生成された非正規化列を、表示のために再正規化することが ベストプラクティスです。しかし、追加の正規化を実行しても文字列比較の結果は変わらないため、 この手順はUnicode正準 ケースフォールド正規化手順およびUnicode 互換ケースフォールド正規化手順では任意（OPTIONAL）です。
63個のギリシャ語の合成済み文字には、文字 ͅ
[U+0345 COMBINING GREEK YPOGEGRAMMENI]を
含む分解マッピング（すなわち、NFD形式へ正規化されるもの）があります。
この発音区別符号は、下付きのイオタを表します（prosgegrammeiまたは
ypogegrammeniと呼ばれます）。この記号は、より現代的な言語には存在しない音を
表す、古代または古典ギリシャ語に見られる正書法上の形式です。
これらの文字の大文字およびタイトルケースのマッピングは、この結合記号を別個の基底文字
iotaとして分離します。タイトルケース／大文字マッピングとの一貫性を保つため、
これらの文字のケースフォールドマッピングにもι [U+03B9 GREEK SMALL LETTER IOTA]が含まれます
（Unicodeのケースフォールドは通常小文字になることを思い出してください）。
これら63個の文字の一つに結合記号が続く場合に限り、 ケースフォールディングの前に正準分解を適用しないと、比較が一致しない可能性があります。 このような文字列は正規化形式ではなく、キーボードやその他の入力処理を通じて 「自然に」生成することは困難です。
たとえば、合成済み（NFC）文字 ᾌ [U+1F8C GREEK CAPITAL LETTER ALPHA WITH PSILI AND OXIA AND PROSGEGRAMMENI]（この基底文字と発音区別符号の組み合わせを表す最も一般的な方法） から開始し、ケースフォールド変換のみを実行すると、最終的にἄι [U+1F04 GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA + U+03B9 GREEK SMALL LETTER IOTA]になります。
代わりに、同じ文字を表す完全に分解された（NFD）列、ᾌ [U+0391 GREEK CAPITAL LETTER ALPHA + U+0313 COMBINING COMMA ABOVE + U+0301 COMBINING ACUTE ACCENT + U+0345 COMBINING GREEK YPOGEGRAMMENI]から開始すると、最終的にἄι [U+03B1 GREEK SMALL LETTER ALPHA + U+0313 COMBINING COMMA ABOVE + U+0301 COMBINING ACUTE ACCENT + U+03B9 GREEK SMALL LETTER IOTA]になります。この文字列をNFCへ正規化すると、上記の最初の例と同じ文字列になります。
これら両方の場合、アキュートアクセントは末尾のイオタではなく、 アルファ基底文字に関連付けられます。
しかし、半分だけ合成済みの列ᾌ [U+1F88 GREEK CAPITAL LETTER ALPHA WITH PSILI AND PROSGEGRAMMENI + U+0301 COMBINING ACUTE ACCENT]から開始すると、最終的にἀί [U+1F00 GREEK SMALL LETTER ALPHA WITH PSILI + U+03B9 GREEK SMALL LETTER IOTA + U+0301 COMBINING ACUTE ACCENT]となり、アキュートアクセントはイオタに関連付けられます。 これにより、他の列と一致するように正規化できない列が生成されます （また、利用者が認識する元の文字とは異なる意味を持つため、実際には正しくありません）。
前述のとおり、Unicodeは、ケースフォールド処理を実行する前にテキストをNFDへ正規化することで、 この照合問題を解決します。その結果、ᾌ [U+1F8C GREEK CAPITAL LETTER ALPHA WITH PSILI AND OXIA AND PROSGEGRAMMENI]と、ᾌ [U+1F88 GREEK CAPITAL LETTER ALPHA WITH PSILI AND PROSGEGRAMMENI + U+0301 COMBINING ACUTE ACCENT]は、 どちらも分解済みの形式、すなわちᾌ [U+0391 GREEK CAPITAL LETTER ALPHA + U+0313 COMBINING COMMA ABOVE + U+0301 COMBINING ACUTE ACCENT + U+0345 COMBINING GREEK YPOGEGRAMMENI]と同じになります。この列にケースフォールドを行い、 正規化すると、すべての場合に一致する結果が生成されます。
大部分の文書形式またはプロトコルは、入力、処理、または符号化が困難な文字を 含められるようにするためのエスケープ機構を提供します。これらのエスケープ機構は、 特定のリソース内で文字を表現する、追加の等価な手段を提供します。 また、文書で使用される文字符号化方式では表現されないUnicode文字を 符号化できるようにします。
文字エスケープおよびインクルードの展開は、文脈、すなわち文字列照合処理を実行するときに
適用されるとみなされる構文コンテンツまたはプログラミング言語に依存します。
suçonを含むもののsuçonを含まないXML文書で、
文字列suçonを検索する場合を考えてください。
プレーンテキストエディターで検索する場合、文脈はプレーンテキスト
（構文コンテンツまたはプログラミング言語は適用されません）です。
ç文字エスケープは認識されないため展開されず、検索は失敗します。
XMLブラウザーで検索する場合、文脈はXMLであり、XMLによって定義された文字エスケープが
展開されるため、検索は成功します。
中間的な例として、XMLエンティティ参照を展開しない状態で XML文書を表示するビューを意図的に提供するXMLエディターがあります。 この場合、その疑似XMLビューに対する検索では、意図的にエンティティを 展開しません。その特定の文脈では、エンティティ参照はインクルードと みなされず、展開する必要はありません。
たとえば、€ U+20AC
EURO SIGNは、HTMLでは16進数エンティティ€または
10進数エンティティ€として符号化することもできます。
JavaScriptまたはJSONファイルでは、\u20acまたは\u{20AC}として表すことができ、
CSSスタイルシートでは\20acとして表すことができます。
これらの表現はすべて、同じリテラル文字値€を符号化します。
文字エスケープは通常、文書を処理し、形式またはプロトコル内の文字列を 照合する前に解釈されます。上記で使用した例に戻ります。
このテキストは、次のように表示されることを期待するでしょう。Hello world!
これを機能させるには、CSSとHTMLで異なるエスケープ機構を使用していたとしても、
ユーザーエージェント（ブラウザー）が、クラス名hélloを表す二つの文字列を
照合する必要があります。上記の断片は、テキストが変化しても、
仕様に従って「同じ」とみなされる方法の一つを示しています。クラス名h\e9lloは、
HTMLマークアップ内のクラス名hélloと照合し
（また、コードポイントé [U+00E9 LATIN SMALL
LETTER E WITH ACUTE]を使用するリテラル値
hélloとも照合します）。
形式言語および文書形式は、多くの場合、一つのリソースにあるテキストの一部を 別のリソース内に含める機能を提供します。インクルードとは、 リソースの本体へコンテンツを挿入する機構です。 インクルード機構は、処理時にコンテンツをリソースへ取り込みます。 これは文書の構造に影響し、場合によっては文書の語彙との照合にも影響します。 インクルードの例には、XMLのエンティティ参照、XInclude [XInclude]仕様、および CSSの@import規則があります。
インクルードが結合記号で始まらない場合 （文字エスケープの形式であるか、取り込まれるリソース内の文字リテラルであるかを問いません）、 そのインクルードはインクルード正規化済みであるといいます。
Unicodeは、文書作成者がテキストの外観または動作を制御するために役立つ、 特殊な用途の文字を多数提供します。これらの文字の多くは不可視であるか、 キーボード上に対応するキーがないため、利用者はその存在または不在を 常に認識しているとは限りません。その結果、これらの文字が符号化された文字列の一部であるものの、 照合対象のテキストに含まれていない場合、文字列照合を妨げる可能性があります。 これらの文字の例には、次のものがあります。
Unicode制御文字U+200D Zero Width Joiner （ZWJとも呼ばれます）およびU+200C Zero Width Non-Joiner （ZWNJとも呼ばれます）。 これらの文字は、望ましくない合字の形成を防止したり、望ましい合字の形成を促進したりするなど、 合字の形成を制御するために使用できますが、主な用途は、アラビア文字や さまざまなインド系用字系などの複雑な用字系における結合および字形選択を制御することです。 一部のインド系用字系では、特定の結合文字の字形を作成者が制御できるようにするため、 ZWJおよびZWNJ文字を使用します。[Unicode]の第12章にある説明を参照してください。
Zero Width Non-Joinerは、ペルシア語で、 特定の「通常の」アラビア文字の結合を防ぐために使用されます。この場合、文字の存在または不在は 実際に意味に影響します。たとえば、単語تنها（「単独」）と単語 تنها （「身体」または「死体」）は、それぞれ「U+062A U+0646 U+0647 U+0627」および「U+062A U+0646 U+200C U+0647 U+0627」として 符号化され、唯一の違いは後者の単語にあるZWNJです。
ZWJ文字は、特定の絵文字列を形成するためにも使用されます。これについては、 以下で詳しく説明します。
異体字セレクター（U+FE00から U+FE0Fまで）は、 代替の外観またはグリフを選択するために使用される文字です （文字モデル：基礎 [CHARMOD]を参照してください）。 たとえば、白黒絵文字とカラー絵文字を選択するために使用されます。 これらは、あらかじめ定義された表意文字異体字列（IVS）でも使用されます。 Unicode文字データベース（UCD）の「Standardized Variants」の部分に多数の例があります。
いくつかの用字系は、視覚的な異体字を符号化する方法も提供します。代表的な例は、 モンゴル文字の自由異体字セレクター（U+180Bから U+180Dまで）です。
文字U+034F Combining Grapheme Joinerは、 その名称に反して書記素を結合するものではありません。この文字は、 並べ替えの目的で一つの書記素とみなされる可能性のある文字を分離するため、 またはUnicode正規化をテキストに適用するときに、特定のテキスト上の区別を 維持する手段を提供するために使用されます。
空白の相違も、テキストの解釈および照合に影響する可能性があります。 たとえば、NBSP、NNBSPなどのさまざまな改行しない空白文字があります。
U+200B Zero Width Spaceは、 通常は空白が現れないテキスト内で単語境界を示すために使用される文字です。 たとえば、タイ語の文書で単語分割を支援するために使用される場合があります。
U+00AD Soft Hyphenは、 ハイフネーションが可能または望ましい位置をテキスト内で示すために使用できます。 テキストがその位置で折り返される場合にのみ表示されます。
U+2060 WORD JOINERは、WJとも呼ばれることがあり、 幅がゼロの改行しない空白文字です。その目的は、二つの文字間での改行を防ぐことです。 改行の目的を除き、無視する必要があります。U+FEFF ZERO WIDTH NO-BREAK SPACEは、「バイト順マーク」（BOM）として より一般的に知られているため、この文字はその代替として機能します。 バイト順マークは、一部のプレーンテキストファイルの先頭で、 ファイルがUnicode文字エンコーディングを使用していることを示すために使用されます。
最後に、大部分の用字系は、横書きの場合、左から右へ進みます。しかし、
アラビア文字およびヘブライ文字など、一部の用字系は主に右から左へ書かれます。
テキストはこれらの用字系を混在させて書くことがあり、また、数字や別の用字系の引用符など、
テキストのその他の部分とは反対方向に進む文字列を含む場合があります。
このテキスト方向の混在は、双方向テキスト、略してbidi
と呼ばれます。
Unicode双方向アルゴリズム [UAX9]は、このような方向が混在するテキストを
表示のために処理する方法を説明します。大部分のテキストでは、方向の処理はテキスト自体から
導出できます。しかし、アルゴリズムがテキストを正しく表示するために、
追加情報を必要とする場合も多数あります。その他の例については、
[html-bidi]を参照してください。
Unicodeがテキスト方向の曖昧さに対処するために定義する方法の一つは、 方向ランの開始と終了を示す一連の不可視制御文字です。双方向制御文字は、 Unicode双方向アルゴリズムによるテキスト表示を支援するため、テキストの外観に影響を 与える可能性がありますが、制御文字がなくても自然に同じ双方向ランになるテキストには、 影響を与えない場合があります。これらの制御文字は、上記の文字と同様に不可視であるため、 照合に意図しない影響を与える可能性があります。
これらのほぼすべての場合、利用者は、特定の文書または文字列に これらの文字の一つが含まれているか、または省略されているかを認識できない、 あるいは確信できないことがあります。テキスト照合は基礎となるコードポイントの照合に 依存するため、これらのマーカーによるテキスト符号化の相違によって、 利用者の観点からは成功するはずの照合が不可解に失敗する可能性があります。
Unicodeの比較的新しい機能の一つが絵文字です。[UTS51]で、Unicodeは絵文字を次のように説明しています。
絵文字は、通常は色鮮やかな漫画のような形式で表示され、 テキスト内でインラインに使用される絵文字記号です。顔、天候、乗り物および建物、 食べ物および飲み物、動物および植物、または感情、気持ち、もしくは活動を表すアイコンなどを 表します。
絵文字は、U+200D ZERO WIDTH JOINER、すなわちZWJを含む、 さまざまな絵文字修飾子とともに使用して、より複雑な絵文字を形成できます。
たとえば、絵文字（👪 [U+1F46A FAMILY]）は、列 U+1F468 U+200D U+1F469 U+200D U+1F466で絵文字間にZWJを使用して 形成することもできます。その他の絵文字を変更または追加すると、家族の構成を変更できます。 たとえば、列👨👩👧👧 U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467は、 この種類の合成をサポートするシステム上で、「家族：男性、女性、少女、少女」を表す 合成絵文字を生成します。一般的な絵文字の多くは、ZWJ列を使用しなければ形成できません。 詳細については、[UTS51]を参照してください。
絵文字の後には、絵文字修飾文字を続けることができます。これらの修飾子により、 人物を表す絵文字の肌の色を選択できます。これらの文字は通常、 修飾する基底絵文字の後に続く不可視の修飾子です。たとえば、次のとおりです。 👨 👨🏻 👨🏼 👨🏽 👨🏾 👨🏿
絵文字の後には、基底絵文字をテキスト表示 （白黒、U+FE0E Variation Selector 15によって示されます）またはカラー表示 （U+FE0F Variation Selector 16によって示されます）にすることを示す、 異体字セレクターを続けることもできます。
絵文字の使用に関する別の複雑な点は、旗です。国旗は、[BCP47]レジストリから派生した国コードを使用して 構成できます。たとえば、文字列🇿 [U+1F1FF REGIONAL INDICATOR SYMBOL LETTER Z] 🇲 [U+1F1F2 REGIONAL INDICATOR SYMBOL LETTER M]は、 ザンビアの国コード（ZM）である🇿🇲を表します。その他の地域旗または特別用途の旗は、 旗の絵文字とさまざまな記号を組み合わせるか、キャンセルタグで終了する地域標識コードを使用して 構成できます。たとえば、スコットランドの旗（🏴）は、次のように構成できます。
これらの機構は一緒に使用できるため、非常に複雑な文字列を使用して、 一つの絵文字書記素または画像を形成できます。非常に類似する絵文字列であっても、 まったく同じ符号化列を使用しないことがあります。多くの場合、上記の修飾子および組み合わせは、 エンドユーザーのキーボードによって生成されます （キーボード上では一つの絵文字「文字」として表示されます）。 このような符号化方法の多様性は、各ベンダーがUnicodeによって 「交換に推奨される」列だけを、かつその列を正確に使用する限り、部分的に対処されます。 これにより、ベンダーは、フォントおよびキーボードが利用者の期待する選択肢を提供できるように 準備できます。それでも、利用者は通常、基礎となる符号化の複雑さを認識せず、 生成機構も推奨されるものだけに制限されません。 絵文字列は急速に進化しているため、近い将来、絵文字の照合を支援または妨げる さらなる進展がある可能性があります。Unicode正規化は、これらの列の順序を変更せず、 修飾子の挿入または削除も行いません。したがって、利用者および実装者は、 名前空間およびその他の照合文脈で絵文字を使用する利用者が、 符号化の相違によって予期しない「文字」の不一致に容易に遭遇する可能性があることに 注意する必要があります。
リソースは、従来の文字エンコーディングを含む異なる文字符号化方式を使用して、 ウェブ上の文書形式を直列化できます。各文字符号化方式は、Universal Character Setの 特定のサブセットを表すために、異なるバイト値およびバイト列を使用します。
すべての文書、形式、およびプロトコルにUTF-8などのUnicode文字エンコーディングを 選択することは、強く推奨される推奨事項です。 従来の文字エンコーディングを使用しても追加の有用性は得られず、 この節の残りの考慮事項を完全に回避できるためです。
たとえば、€ [U+20AC EURO
SIGN]は、UTF-8文字エンコーディングでは
バイト列0xE2.82.ACとして符号化されます。同じ文字は、
従来の文字エンコーディングwindows-1252では、
バイト列0x80として符号化されます。
（その他の従来の文字エンコーディングでは、この文字を符号化するバイト列が
提供されない場合があります。）
仕様は主に、各文書を、その文書の文字エンコーディング （従来の文字エンコーディングであるか、UTF-8などのUnicode符号化であるかを問いません）から 変換し、文字エスケープを展開した後のUnicode文字列として扱うことにより、 こうして生じる相違に対処します。その後、文書の処理を続行します。
一つの従来の文字エンコーディング内でも、
実装によって相違が生じることがあります。有名な例の一つは、
従来の日本語エンコーディングShift_JISです。
異なるトランスコーダ実装は、特定のバイト列をUnicodeへマッピングする方法を選択する必要がありました。
そのため、バイト列0x80.60
（JIS X 0208文字集合では0x2141）は、
一部の実装ではU+301C
WAVE DASHへマッピングされ、その他の実装ではU+FF5E
FULL WIDTH TILDEへマッピングされました。
これは、合理的で内部的に一貫した二つのトランスコーダが、
同じ入力から異なるUnicode文字列を生成する可能性があることを意味します。
Encoding [Encoding]仕様は、
ウェブ実装が相互運用可能で同一のマッピングを使用することを保証する目的もあって存在します。
しかし、Encoding仕様に適合するトランスコーダが、ウェブ上にある文書に適用されることや、
特定の文書形式またはプロトコルに現れるデータを処理するために使用されることは
保証されません。
Unicodeへ変換する際のもう一つの考慮事項は、視覚的な格納順序を使用する、 双方向用字系（ヘブライ文字およびアラビア文字など）の従来の文字エンコーディングが 存在することです。すなわち、Unicodeおよびその他の現代的な符号化とは異なり、 文字は画面上で左から右へ印刷される順序（ラインプリンターと同様）でメモリに格納されます。 これらの符号化をUnicodeへ変換するとき、またはこれらの符号化のテキストを比較するときは、 ソースと対象の両方のテキストを論理順序に配置するよう注意する必要があります。 詳細については、[CHARMOD]の第3.3.1節を 参照してください。
自然言語の検索または「検索」機能を実行するときに適切な、 その他の種類の等価性または処理があります。これらは、文字モデル文書シリーズの 別の部分（[STRING-SEARCH]）で説明されています。 語彙の仕様、または形式構文で使用する照合アルゴリズムを定義する仕様は、 一貫性があり予測可能な結果の生成を妨げるため、その文書で説明されているような 追加の独自フォールディング、マッピング、または処理を適用しようとすることを 避けるべきです（SHOULD）。
文字列が異なる文字エンコーディングを使用したり、それらのエンコーディング内で異なる文字列を使用したり、 本文書で説明するその他の相違（文字ケースなど）を持つ可能性があるウェブ環境では、 文字列の同一性を評価するための一貫した処理を確立することが重要です。
この章では、構文 コンテンツにおける文字列照合を指定および実装するための要件を定義します。
文字列照合をより効果的かつ一貫したものにする方法の一つは、 照合対象のコンテンツに制限を適用することです。語彙の定義、 特にその語彙内でユーザー指定値を許可する語彙の定義には、 「有効な識別子」を構成する規則が必然的に含まれます。これには通常、長さおよびコンテンツの 制限が含まれます。これらの制限を定義するためのベストプラクティスには、次のものがあります。
仕様は、識別子でサロゲートコードポイント （U+D800からU+DFFFまで）または 非文字コードポイントを許可するべきではありません（SHOULD NOT）。
仕様は、識別子でC0
（U+0000からU+001Fまで）および
C1（U+0080からU+009Fまで）の制御文字を
許可するべきではありません（SHOULD NOT）。
識別子には、大きく分けて二つのクラスがあります。ユーザー向け識別子と アプリケーション内部識別子です。
アプリケーション内部識別子は、 文書形式またはプロトコルの語彙のうち、機械可読であり、表示を目的としない部分です。 これらには、文書形式またはプロトコルの内容を操作またはデバッグする必要がある開発者や コンテンツ作成者にとって使いやすいように、多くの場合、意味のある名称 （一般に英語）が付けられます。
アプリケーション内部識別子 （利用者に表示されることがなく、常にアプリケーションまたはプロトコル内での照合または処理に 使用されるもの）を定義する仕様は、コンテンツをASCIIの印刷可能なサブセットに 制限するべきです（SHOULD）。ASCIIの大文字と小文字を区別しない照合が 推奨されます（RECOMMENDED）。
アプリケーション内部 識別子のフィールドまたは値をエンドユーザーに表示する場合、 ローカライズ可能な表示値で包まなければなりません（MUST）。
ユーザー向け識別子は、文書形式または プロトコルの語彙のうち、利用者によって割り当てまたは編集されるか、 選択のために利用者へ提示される部分です。ユーザー向け識別子の例には、ネットワーク名 （SSIDなど）、デバイス名、クラス名、スタイル名、属性名、またはユーザー定義の設定や値があります。 この種類の識別子は、本文書で説明する問題のため照合がより複雑ですが、 特に英語を話さない利用者やラテン文字にあまり馴染みのない利用者にとって、 最良の利用体験を提供します。
多くのユーザー向け識別子は、ユーザー指定値でもあり、文書形式またはプロトコルの 利用者によって割り当てることができます。利用者、利用者のコミュニティ、または文化が好む自然言語を 使用できることは、優れた利用体験を提供し、特に英語の言語能力が限られている可能性のある 利用者にとって、機能をより利用しやすくします。
識別子が利用者に表示されるか、表示される可能性がある場合、 すべての言語の利用者が、生成される文書形式またはプロトコルを平等に利用できるようにするため、 仕様は非ASCIIのUnicode文字の使用を許可するべきです（SHOULD）。大文字と小文字を区別すること （すなわち、ケースフォールディングを行わないこと）が推奨されます （RECOMMENDED）。
広範囲のUnicode文字を許可することが望ましい一方で、仕様は ユーザー向け識別子の コンテンツに一定の実用的制限を課すことができます。この種類のコンテンツ規則を定義する仕様の 一例は、Unicode Identifier and Pattern Syntax [UAX31]にあります。
特定の仕様で使用する照合アルゴリズムを選択する際の基本的な決定事項は、 照合対象の文字列に適用するテキスト正規化の水準 （大文字と小文字の区別およびUnicode正規化の両方を含みます）です。 歴史的に、ウェブ上の大部分の仕様は、Unicode正規化を行わず、 大文字と小文字を区別する照合を選択してきました。これは、すべての新しい仕様に対して 推奨される（RECOMMENDED）照合形式です。 ただし、大文字と小文字を区別しないことや正規化が有用な場合もあります。
対象となる形式またはプロトコルの利用者にとっての利点が、 実装のコストおよび複雑さを上回る場合、仕様は大文字と小文字を区別しないことを選択できます。 ケースフォールディングと正規化はどちらも、テキストの表示や、場合によっては意味を含め、 比較される値に影響する可能性があり、これらの処理は比較的高コストであるため、 大文字と小文字を区別しないことを選択するのは一般に推奨されません。
大文字と小文字を区別しない照合の特殊な場合として、ASCII／基本ラテン文字の範囲
（すなわち、コードポイントU+0000から
U+007Fまで）に制限された語彙があります。
これらの仕様は、その文字範囲だけで大文字と小文字を区別しないことを選択できます。
これにより、照合の実装が大幅に簡単になります。しかし、この形式の照合は、
識別子または構文でより広いUnicode範囲を許可する仕様には適していません。
照合の動作を利用者が理解するのが困難であり、非ASCIIの用字系および言語の利用者にとって
不利になるためです。すなわち、greenが
GREENと照合する一方で、grüßが
GRÜẞまたは場合によってはGRÜSSと照合せず（代わりにGRüßと照合する）場合、利用者はその動作を奇妙で予測不能だと感じます。
照合アルゴリズムは、二つの文字列を比較するために必要な一連の手順を説明します。
特定の仕様に適したテキスト正規化は、その形式またはプロトコルの語彙の要件によって決まります。 テキスト正規化には、次の四つの選択肢があります。
識別子および構文コンテンツ内の文字列を照合するとき、 コンテンツに対してケースフォールディングもUnicode正規化も一切行わないことが 推奨されます（RECOMMENDED）。
この正規化手順はテキストに影響を与えないため、比較では、 比較対象の元の文字列にある文字ケースの相違とUnicode正規化形式の相違の両方を区別します。 コンテンツ作成者は、トークンが照合することを期待する場合、 影響を受けるテキストを符号化する際に一貫した文字ケースおよび一貫した文字列を 使用する必要があることを認識し、それを保証する必要があります。
「ASCIIケース フォールド」手法は、語彙自体がASCII範囲に制限されている場合 （またはASCIIトークンだけで照合を行う場合）の例外的な場合にのみ使用するべきです。
ASCIIケースフォールド正規化手順は、ASCII範囲だけでケースフォールディングを実行します。 Unicode正規化形式は適用されません。この手順は、語彙自体がASCII範囲に制限されている場合 （またはASCIIトークンだけで照合を行う場合）にのみ適切です。
各文字列について、次の手順を実行します。
大文字と小文字を区別しないことは、大部分の仕様には推奨されません。 ただし、語彙が非ASCII文字を許可し、文字ケースの区別を行わない例外的な場合には、 「Unicode正準ケースフォールド」手法を 使用するべきです（SHOULD）。
非ASCII文字を許可する語彙を持つ仕様には、 大部分の新しい語彙が含まれるべきです。
Unicodeケースフォールディングは非正規化文字列を生成する可能性があるため、 照合を利用者の期待と一致させるには、Unicodeケースフォールドの後に Unicode正規化を行う必要があります。例については、2.4 正規化とケースフォールディングの相互作用を参照してください。
[Unicode]の要件D145は、 結果の文字列が正規化形式になることを保証するため、 ケースフォールド処理の後に正規化手順を行うことを要求します。 ケースフォールド後の正規化を含めることは任意です。結果の文字列が比較だけに使用され、 保存または利用者へ表示されない場合、ケースフォールド後のコードポイント列は等価になります。 ただし、特定の正規化形式になることは保証されません。 これはD145に対する意図的な違反です。 Unicodeは、これが有効な推奨事項であることを確認しています。
各文字列について、次の手順を実行します。
「Unicode 互換ケースフォールド」手法を使用するべきではありません。
非ASCII文字を許可し、Unicodeの互換等価文字を照合する必要がある語彙を持つ仕様は、 この正規化手順を使用する場合があります。互換正規化形式 （NFKCおよびNFKD）は、テキストの意味、外観、および処理を 変更するため、この手順はウェブ上の大部分のアプリケーションで 使用するべきではありません（SHOULD NOT）。
ケースフォールディングは入力コードポイント列の影響を受けます。 また、非正規化コードポイント列を生成する可能性もあります。 互換分解とケースフォールディングの相互作用では、一貫した照合を生成するために 複数回の処理が必要です。そのため、この正規化手順にはUnicode正規化を複数回使用します。 例については、2.4 正規化とケース フォールディングの相互作用を参照してください。
各文字列について、次の手順を実行します。
コンテンツ作成者は、Unicode文字エンコーディング （ウェブでは一般にUTF-8）でリソースを入力および保存するべきです （SHOULD）。
テキストを比較する最初の手順は、両方が同じデジタル表現を使用することを保証することです。 これは、実装が従来の 文字エンコーディングで符号化されたテキストをUnicodeコードポイント列へ 変換する必要があることを意味します。通常、これはトランスコーダを適用し、データを一貫したUnicode 符号化形式（UTF-8またはUTF-16など）へ変換することで行います。 これにより、文字列が等しいかを判定するためのビット単位の比較が可能になります。
特定の文字のマッピングが意味を妨げる場合を除き、 コンテンツ作成者は、従来の符号化を使用したテキストまたはリソースをUnicodeへ変換するとき、 正規化トランスコーダを 選択するべきです（SHOULD）。
正規化トランスコーダとは、従来の文字エンコーディングから Unicodeへの変換を実行し、かつ結果がUnicode正規化形式C （NFC）になることを保証するトランスコーダです。 大部分の従来の文字エンコーディングでは、任意のトランスコーダの後に正規化器を使用することで、 正規化トランスコーダを構築できます。ただし、従来の文字 エンコーディングのレパートリに Unicodeで表現されていない文字が含まれる場合は、構築できません。 正規化トランスコーダはNFCの文字列だけを生成しますが、 変換された文字列はインクルード正規化済みではない可能性があります （たとえば、結合記号で始まる場合）。
ウェブ上の文書形式は、多くの場合、追加の外部リソースと相互作用するか、 外部リソースを使用して処理されるため （たとえば、HTML文書にCSSスタイルシートを適用する場合）、 異なる文字エンコーディングを使用する文書間で値を照合するとき、 テキストの一貫した表現が重要になります。正規化トランスコーダを使用すると、 従来の符号化を使用した文書を、大部分の言語で通常期待されるUnicode文字列と 照合させることにより、相互運用性の保証に役立ちます。
ウェブで使用される大部分のトランスコーダは、出力として NFCを生成しますが、生成しないものもいくつかあります。 これは通常、トランスコーダが元の従来の文字エンコーディングとの往復互換性を持つようにするため、 その他の文字の区別を維持するため、またはユーザーエージェントで使用される他のトランスコーダと 一貫性を保つためです。つまり、Encoding仕様 [Encoding]およびその他のさまざまな重要な トランスコーディング実装には、正規化を行わないトランスコーダが多数含まれています。 実際、Unicodeの大部分の互換文字は、従来の符号化からの往復変換のためだけに存在し、 そのうち多数はNFCで単一の正準マッピングを持ちます。 この例は、本文書の前の部分にあるÅ [U+212B ANGSTROM SIGN]で示しました。
大部分のトランスコーダはNFC出力を生成し、 すべての文字についてNFCを生成しないトランスコーダでも、 圧倒的多数の文字についてはNFCを生成することに 留意してください。特に、合成済み形式が存在する場合に分解形式を生成する、 または正規化された列とは異なる結合文字列を生成する、一般的に使用されるトランスコーダはありません （これは[Encoding]にあるすべてのトランスコーダに 当てはまります）。
仕様は、Unicode文字エンコーディングを許可しなければなりません （MUST）。
仕様は、既定の文字エンコーディングを指定しなければならず （MUST）、既定のエンコーディングとしてUTF-8を 指定するべきです（SHOULD）。
仕様は、UTF-8以外のエンコーディングを許可しないようにするべきです （SHOULD）。
従来の文字エンコーディングは、 ウェブ上では一般にその有用性を失っています。新しい仕様は、最初からUnicode符号化をサポートし、 Unicode符号化（一般にUTF-8）を既定値とし、可能であれば、その他のエンコーディングの使用を 許可しないようにする必要があります。これは相互運用性を促進するだけでなく、 文字およびデータ表現における無意味な相違の範囲を減らします。
大部分の文書形式およびプロトコルは、文字をエスケープ列として符号化する手段、 またはテキストを含む外部データをリソースへ取り込む手段を提供します。 これについては、[CHARMOD]の 第4.6節および上記で詳しく説明しています。
照合を実行するときは、照合が適切に成功（または失敗）するように、 文字エスケープをいつ解釈するかを把握することが重要です。 通常、エスケープ、参照、およびインクルードは、照合 （または照合に依存する処理）を実行する前に処理または展開されます。 これらの構文は、符号化が困難な列を文書内へ簡便に配置できるようにしつつ、 対象の文書内でコードポイント列として直接符号化されたかのように 文字を動作させるために存在するためです。
これが複雑になる可能性がある領域の一つは、構文 コンテンツとローカライズ可能なコンテンツの相互作用を 決定することです。たとえば、次のHTML断片について考えてください。
技術的には、結合記号 ̀ [U+0300 COMBINING GRAVE ACCENT]は直前の引用符と結合しますが、 HTMLは、その文字がエンティティとして符号化されているかどうかにかかわらず、 HTML構文の一部を形成するとはみなしません。
リソースに対して照合処理を実行するときの一般的な規則は、
利用者が操作しているものと同じ「水準」でエスケープを展開することです。
たとえば、上記の例について考えると、HTMLのソースを表示するツールは、
エスケープ列̀をアンパサンドで始まる文字列として表示します。
一方、JavaScriptプログラムはブラウザーによる文書の解釈を操作するため、
属性idの値として文字U+0300を照合します。
文書形式の構文を処理するとき、形式の処理規則によって明示的に禁止されている場合を除き、 エスケープは通常、構文を処理する前に、それが表す文字列へ変換されます。 これにより、リソースの構文構造へあらゆる種類の文字を含めることができます。
場合によっては、エスケープの前処理が問題を引き起こします。
たとえば、HTML文書を構文解析する前に列<を展開すると、
文書エラーが発生します。
特定のUnicode正規化形式が、常にコンテンツ作成者にとって適切または利用可能であるとは限らず、 利用者によるテキスト符号化の選択が、後続のデータ利用者にとって明らかでないこともあります。 本文書で示すように、コンテンツ作成者またはアプリケーションがテキストを入力または交換するとき、 同じ意味値を表すために選択できる方法は多数あります。 正規化は、利用者が意図的に適用した区別を取り除く可能性があります。 そのため、照合アルゴリズムは、 文字列のケースフォールド照合を実行するときにのみ、かつアルゴリズム内部でのみ、 Unicode正規化を使用するよう指定します。コンテンツに正規化を課すことは、 利用者および実装者にとって障壁となる可能性があります。したがって、次のとおりです。
仕様は、特定の語彙の符号化、保存、または交換のために Unicode正規化形式を指定するべきではありません（SHOULD NOT）。
実装は、コンテンツをUnicode文字エンコーディングへ トランスコードすること、ケースフォールディング、またはその他の利用者が開始した変更など、 テキスト変換の副作用として必要な場合を除き、交換、読み取り、構文解析、または処理される 構文コンテンツ（ユーザー指定値を含む）またはローカライズ可能なコンテンツの正規化形式を 変更してはなりません（MUST NOT）。 データ利用者またはコンテンツ自体が非正規化表現に依存している可能性があるためです。
作成ツールは、リソースを正規化する手段を提供し、 特定のリソースがUnicode正規化形式Cではない場合に利用者へ警告するべきです （SHOULD）。
特定の正規化形式でテキストを保存および交換することを要求する仕様は、 3.2.5.1 文書形式で正規化を指定する 際の要件にある要件に対処する必要があります。
追加の要件が必要となる具体的かつ明確な理由がない限り、 仕様が形式またはプロトコルに対して正規化形式でデータを保存または交換することを 要求するのは、一般に推奨されません。ウェブ上の多くの文書形式は正規化を要求しないため、 コンテンツ作成者が非正規化文字列に依存する場合があります。 正規化手順は、このようなコンテンツに悪影響を与える可能性があります。
正準正規化形式（NFC形式またはNFD形式）は、 適用対象のテキストの意味および表示を維持することを意図しています。 ただし、常に維持されるとは限らず、これが正規化を推奨しない理由の一つです。 NFCには、ほぼすべての従来のデータ （単純に1対1でUnicode符号化へトランスコードした場合）、 現在のソフトウェアによって作成されたデータ、および大部分 （ただしすべてではありません）のキーボードで利用者が入力したデータが、 すでにこの形式であるという利点があります。NFCには、わずかな圧縮性の利点もあり、 文字と書記素の関係について、大部分の言語で利用者の期待により適合します。
仕様は、互換正規化形式（NFKC、NFKD）を指定するべきではありません （SHOULD NOT）。
エンドユーザーが明示的に要求しない限り、 実装は互換正規化形式（NFKC、NFKD）を適用してはなりません （MUST NOT）。
互換正規化形式（NFKC形式およびNFKD形式）は、構造を変更し、 重要な点でテキストの意味を失わせます。利用者は、Unicodeで互換マッピングを持つ文字を 意図的に使用する場合があり、またはUnicodeへ変換したときに互換マッピングを持つ 従来の文字エンコーディングの文字を使用する場合があります。 これは、コンテンツ作成者による意図的な選択として扱う必要があります。 NFKC／NFKDは、「検索」処理またはローカライズ可能なコンテンツの文字列検索で 有用な場合がありますが、互換性の相違を消去することは有害です。
NFCを要求する場合、 ウェブ上のコンテンツは一般に既知の正規化状態ではないため、仕様開発者は 追加の注意を払う必要があります。この場合、非正規化コンテンツの境界条件および エラー条件を慎重に検討し、十分に指定する必要があります。
正準等価であるものの互いに異なるUnicode文字列が セキュリティ上の問題となる場合、仕様はその問題を文書化するか、 注意喚起を提供しなければなりません（MUST）。
コンテンツ作成者は、可能な限りコンテンツに Unicode正規化形式C（NFC）を 使用するべきです（SHOULD）。
NFCは、常にコンテンツに適しているとは限らず、 一部の言語ではコンテンツ作成者が利用できない場合もあることに注意してください。
形式または実装が実行する照合にUnicode正規化形式が 含まれている場合でも、照合を容易にするため、コンテンツ作成者は常に一貫した Unicode文字列を使用してテキストを符号化するべきです （SHOULD）。
コンテンツを一貫して処理できるようにするため、コンテンツ作成者は、 同じテキストを表すために一貫したコードポイント列を使用するよう努めるべきです。 コンテンツは任意の正規化形式であってもよく、非正規化 （ただし有効な）Unicode文字列を使用する場合もありますが、 表現が一貫していないと、実装は異なる列を異なるものとして扱います。 一貫した選択、アクセス、抽出、処理、または表示を保証する最良の方法は、 常にNFCを使用することです。
コンテンツ作成者は、リソース内で直前に基底文字がない結合記号を 含めるべきではありません（SHOULD NOT）。
これには例外があります。たとえば、文字の一覧
（[Unicode]文字の一覧など）を作成するとき、
作成者は対応する基底文字なしで結合記号を使用することを望む場合があります。
しかし、基底文字なしで結合記号を使用すると、単純な実装が結合記号を隣接する構文コンテンツ、
ユーザー指定コンテンツ、またはローカライズ可能なコンテンツと結合する場合など、
意図しない表示または処理の問題が発生する可能性があります。
たとえば、文字 ́ [U+0301 COMBINING
ACUTE
ACCENT]などの結合記号を、HTMLのclass属性値の先頭に
使用すると、クラス名がエディター内で正しく表示されず、編集が困難になる可能性があります。
推奨される基底文字には、基底文字を表示する必要がある場合の◌ [U+25CC DOTTED CIRCLE]や、 基底文字を不可視にする必要がある場合の [U+00A0 NO-BREAK SPACE]があります。
コンテンツ作成者が常にこれらのガイドラインに従うとは限らないため、次のとおりです。
語彙の仕様は、構文コンテンツと文字データの間の境界、 およびエンティティ境界（言語にインクルード機構がある場合）を定義しなければなりません （MUST）。これには、任意の文字を表現するよう設計された 文字エスケープを許可しつつ、その言語のインスタンスを処理するときに、 コンテンツの処理または照合で競合を引き起こす可能性のある境界を含める必要があります。
仕様が保存、送信、または処理のためにUnicode正規化を要求する場合、 その仕様の作成者および実装者は、いくつかの追加の考慮事項に対処する必要があります。
正規化されたテキスト入力から処理が非正規化出力を生成する可能性がある場合、 仕様は、結果の出力を正規化する必要があるかどうかを定義しなければなりません （MUST）。仕様は、一部の処理で正規化の実行が任意であると 規定してもよい（MAY）ですが、この場合、既定では正規化を 実行するべきであり（SHOULD）、正規化を無効にするために明示的な選択肢を 使用するべきです（SHOULD）。
正規化を要求する仕様は、正規化の実装を任意にしてはなりません （MUST NOT）。
一部の実装が正規化し、その他の実装が正規化しない場合、相互運用性を達成できません。
正規化を実行する必要がある実装は、次の要件を考慮する必要があります。
実装が、テキストが正規化形式であることを検査によって確認するか、 テキスト自体を再正規化するまでは、正規化に依存する処理を実行してはなりません （MUST NOT）。これらの規則の対象とならない非公開システム内では、 非公開の取り決めを作成してもよい（MAY）ですが、外部から観測可能な結果は、 規則に従った場合と同じでなければなりません（MUST）。
テキストを変更し、正規化に依存する処理を実行する 正規化テキスト処理コンポーネントは、各変更後に正規化が行われたかのように 動作しなければなりません（MUST）。 これにより、その後の正規化に依存する処理は常に、正規化されたテキストを 扱っているかのように動作します。
作成ツールの実装は、処理、表示、または交換を妨げる可能性がある、 結合記号で始まる構文コンテンツの入力または作成について、 利用者へ警告するか、それを防止するべきです（SHOULD）。
文字列同一性照合における重要な考慮事項の一つは、 比較で大文字と小文字を区別するかどうかです。
形式または実装がケースフォールド照合をサポートする場合でも、 照合を容易にするため、コンテンツ作成者は識別子を常に一貫した大文字、小文字、 および大小文字混在の形式で表記するべきです（SHOULD）。
ユーザー定義値を含む構文コンテンツの照合には、 大文字と小文字を区別する照合が推奨されます （RECOMMENDED）。
語彙では通常、コンテンツ作成者および利用者にとっての予測可能性が重視されます。 大文字と小文字を区別する照合は最も実装が容易であり、 一般に基礎となるUnicodeコードポイント列を比較するだけで構成されるため、 混乱の可能性が最も低くなります。言語固有のケースマッピングなどの考慮事項の影響を 受けないため、上記のトルコ語の例のような語を 構文コンテンツに含めた文書作成者にとって、最も予想外の結果が少なくなります。
大文字と小文字を区別しない処理は通常、ローカライズ可能な コンテンツの処理、たとえば自然言語のテキスト検索に 使用されます。ただし、大文字と小文字を区別しないことが望ましい場合もあります。 この場合、形式言語が考慮する必要がある実装上の選択肢がいくつかあります。
Unicodeの基本ラテン文字（ASCII）範囲を超える文字を含む語彙で 大文字と小文字を区別しない照合を定義する仕様は、 Unicode完全ケースフォールド照合を指定しなければなりません （MUST）。
仕様は、ユーザー定義値にUnicodeの全範囲を許可するべきです （SHOULD）。
語彙は一般に、特にユーザー指定値について、 不利益を与えることなく最も広範な言語および文化で使用できるようにするため、 幅広いUnicode文字を許可するべきです。そのため、ケースフォールディングなどの テキスト処理は、選択された一部だけでなく、Unicodeの全範囲に対処する必要があります。 大文字と小文字を区別しない照合が必要な場合、これはUnicodeケースフォールディングを使用することを意味します。
Unicode単純ケースフォールディング形式は、 ウェブ上の文字列同一性照合には適していません。
Unicodeの基本ラテン文字（ASCII）サブセットに制限された語彙で 大文字と小文字を区別しない照合を定義する仕様は、ASCIIの大文字と小文字を区別しない照合を指定してもよい （MAY）。
語彙がASCIIに制限され、 ユーザー定義の名称または識別子を許可しない形式言語は、ASCIIの 大文字と小文字を区別しない照合を指定できます。この例の一つはHTMLであり、 HTML仕様によって定義される要素名および属性名に対して、 ASCIIの大文字と小文字を区別しない比較を使用するよう定義しています。
すべてのトークンおよび識別子が仕様によって直接定義され、 それらの識別子またはトークンがUnicodeの基本ラテン文字サブセットだけを使用する場合に限り、 語彙は「ASCIIのみ」とみなされます。ユーザー定義識別子を許可する場合、 Unicode文字の全範囲（セキュリティまたは交換上の懸念に応じて適切に制限します。 [UTR36]を参照してください）を 許可し、同一性照合にはUnicodeの大文字と小文字を区別しない照合を使用するべきです。
ASCIIのみの語彙は、識別子または値により広いUnicode範囲を許可する 文書形式またはプロトコル内に存在できます。たとえば、[CSS-SYNTAX-3]は、 識別子および値でUnicodeの全範囲を使用できるようにCSSスタイルシートの形式を定義します。 ただし、CSS仕様は常にASCII範囲のサブセットを使用してCSSキーワードを定義します。 したがって、多くのスタイルシートにASCIIではない識別子またはデータ値が含まれていても、 CSSの語彙はASCIIのみです。
ロケールまたは言語固有の調整は、自然言語処理 （本文書の範囲外です）の一部である場合に最も適しています。 ケースマッピングまたはケースフォールディングの言語固有の調整は、 一般的なケースフォールディング規則とは異なる結果を生成するため、 予測可能性が重視される形式言語では避けるべきです。
語彙で大文字と小文字を区別しない照合を定義する仕様は、 言語依存の大文字と小文字を区別しない照合を指定するべきではありません （SHOULD NOT）。
言語依存の大文字と小文字を区別する照合を指定する場合、 Unicodeケースマッピングを言語に従って調整するべきであり （SHOULD）、各調整に使用する言語の情報源を 指定しなければなりません（MUST）。
照合される二つの文字列は異なる言語である可能性があり、 さらに第三の言語の文脈内に現れる場合があります。 したがって、ケースフォールディングに使用する言語は、 アプリケーションおよび利用者の期待によって決まります。
言語情報は取得、検証、または管理が困難な場合があり、 結果の処理が利用者を不満にさせたり、照合を実行する利用者の言語設定または システム設定によって一部の利用者では失敗し、その他の利用者では成功したりする 可能性があるため、形式言語では言語固有の調整は推奨されません。
言語固有の処理には、適切な場合、 言語固有のケースフォールディングを含めるべきです （SHOULD）。
たとえば、CSSの処理text-transformは、
文字列をケースマッピングするために使用される場合、言語に依存します。
Unicodeケースフォールディングは、文書形式およびプロトコルで推奨される 大文字と小文字を区別しない照合ですが、既定値とは異なるマッピングを持つ言語の コンテンツ作成者および利用者は、通常、自分が話す言語と一致する結果を期待するため、 依然として結果に驚く可能性があります。
言語依存の文字列比較は、多くの場合ロケール依存と呼ばれます。
大部分のプログラミング言語およびオペレーティング環境は、
それぞれのロケールベースのAPIを使用して言語固有の調整へアクセスするためです。
たとえば、Javaプログラミング言語のjava.text.Collatorクラスまたは
JavaScriptのIntl.Collatorを参照してください。
仕様は、照合処理の一部として行う追加の調整を 明確に定義しなければなりません（MUST）。
一部の仕様は、特定の語彙での照合を支援するために、追加の調整を含めることを 望む場合があります。その例には、第2節で説明した 追加のテキスト上の相違を取り除くこと、構文の一部である文字を同じ文字へマッピングするか 削除すること、または空白のトリミングを実行することがあります。
追加の調整は、異なる言語がUnicodeで表現される方法を妨げないようにする必要があります。 たとえば、テキストを分解してからすべての結合文字を削除することで文字からアクセントを 取り除こうとする処理は、結合記号に依存する言語を破壊します。 その例は、例2にあるデーヴァナーガリーのテキストです。 （このような処理では、すべての可能なアクセントを取り除くこともできず、 テキストの意味および表現を損なう可能性があります。）
形式言語内の文字列およびトークンの照合が本文書の主な関心事ですが、 仕様が単純な文字列の等価性を超える追加の種類の照合を考慮する必要がある場合もあります。
正規表現構文を定義する仕様は、[UTS18]に従い、 少なくとも基本Unicodeレベル1をサポートしなければならず（MUST）、拡張または調整済み （レベル2および3）をサポートするべきです（SHOULD）。
正規表現構文は、利用者が部分的にしか分からない値や、 予測可能な方法で変化する値を指定できるため、形式またはプロトコルを定義するときに 有用な場合があります。本文書のさまざまな節で示したように、 Unicodeで文字を符号化する方法には相違があり、これが式で文字列を指定または照合する方法を 妨げる可能性があります。たとえば、文字数の計数は、使用されるUnicodeコードポイント数ではなく 書記素境界に依存する必要がある場合があります。大文字と小文字を区別しない照合では、 ケースフォールディングの相違を考慮する必要がある場合があります。 また、処理対象の式またはテキストのUnicode正規化を考慮する必要がある場合があります。
Unicode正規表現レベル1のサポートには、エスケープを使用する場合を含め、 正規表現でUnicodeコードポイントを指定する機能、Unicode文字プロパティへアクセスする機能、 および大部分の正規表現構文に共通する特定の種類の境界へアクセスする機能が含まれます。
レベル2では、特定の種類の書記素クラスタ境界でテキストを選択する機能や、 文字ケース変換のサポートなど、重要な機能が追加されます （これら二つの主題は上記で詳しく説明しました）。 レベル3では、ロケール [LTLI]に基づく 正規表現の調整が提供されます。これは形式言語ではあまり有用ではありませんが、 ローカライズ可能なコンテンツの処理には 有用な場合があります。
本文書への変更（2018-04-20付の作業草案以降）は、GitHubの コミットログで確認できます。
この版では、Unicode正準ケースフォールド正規化手順およびUnicode互換ケースフォールド正規化手順で、どの正規化手順を任意とするかを変更しました。この 版では、最初の手順として正規化を要求し、出力の正規化を任意としています。この変更は、 Unicodeとのテストおよび協議に基づいています。
W3C国際化ワーキンググループおよびインタレストグループをはじめ、 多くの方々からコメントや提案をいただきました。ワーキンググループは、次の方々に感謝します。 Mati Allouche、 Ebrahim Byagowi、 John Cowan、 Martin Dürst、 Behdad Esfahbod、 Asmus Freitag、 Richard Ishida、 John Klensin、 Peter Saint-Andre、 Amir Sarabadani、 Najib Tounsi、 Richard Wordingham、 および本文書の20年（!!）にわたる開発に貢献したすべてのCharMod貢献者。
本文書の以前の版は、次の方々によって編集されました。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: