UTS #39: Unicodeセキュリティメカニズム

Unicodeセキュリティメカニズム

Unicode®技術標準 #39

概要

Unicodeは非常に多くの文字を含み、世界の多様な文字体系を取り込んでいるため、誤った使用はプログラムやシステムを潜在的なセキュリティ攻撃に晒す可能性があります。この文書は、潜在的なセキュリティ問題を検出するために使用できるメカニズムを指定します。

ステータス

この文書は、Unicodeメンバーおよびその他の関係者によってレビューされ、Unicodeコンソーシアムによる公開が承認されました。これは安定した文書であり、参照資料として使用したり、他の仕様で規範的な参照として引用したりできます。

Unicode技術標準（UTS）は独立した仕様です。Unicode標準への準拠は、いかなるUTSへの準拠を意味するものではありません。

修正およびその他のコメントは、オンライン報告フォーム（フィードバック）で提出してください。この文書の理解に役立つ関連情報は、参考文献にあります。Unicode標準の最新バージョンについては、Unicodeを参照してください。現在のUnicode技術レポートのリストについては、レポートを参照してください。Unicode標準のバージョンに関する詳細については、バージョンを参照してください。

目次

• 1 はじめに
• 2 準拠
• 3 識別子文字
  • 3.1 識別子のための一般セキュリティプロファイル
    • 表1. Identifier_Status と Identifier_Type
    • 3.1.1 結合制御文字
      • 3.1.1.1 結合制御文字の限定されたコンテキスト
      • 3.1.1.2 制限事項
    • 3.1.2 Identifier_Type 値の選択
  • 3.2 識別子のためのIDNセキュリティプロファイル
  • 3.3 識別子のための電子メールセキュリティプロファイル
• 4 紛らわしい文字の検出
  • 4.1 全体スクリプトの紛らわしい文字
  • 4.2 混合スクリプトの紛らわしい文字
• 5 検出メカニズム
  • 5.1 混合スクリプト検出
    • 表1a. 混合スクリプトの例
  • 5.2 制限レベル検出
  • 5.3 混合数字検出
  • 5.4 オプション検出
• 6 開発プロセス
  • 6.1 紛らわしい文字データの収集
  • 6.2 識別子変更データ収集
• 7 データファイル
  • 表2. データファイルリスト
• 移行
  • 表3. バージョン対応
  • 永続データの移行
  • バージョン8.0移行
  • バージョン7.0移行
• 謝辞
• 参考文献
• 改訂

---

1 はじめに

Unicode技術レポート #36、「Unicodeセキュリティに関する考慮事項」（UTR36）は、Unicodeの使用に関連するセキュリティ問題の検出と回避のためのガイドラインを提供します。この文書は、その文書で使用されているメカニズムを指定しており、他の場所でも使用できます。続行する前に、UTR36に精通している必要があります。Unicode FAQのセキュリティ問題（FAQSec）も参照してください。*

2 準拠

この仕様への準拠を主張する実装は、以下の条項に準拠しなければなりません：

UTS-39-C1. 識別子のための一般プロファイルの実装を主張する実装は、UTS-39-C1-1またはUTS-39-C1-2のいずれかに準拠するものとします。

UTS-39-C1-1. 実装は、セクション3.1、識別子のための一般セキュリティプロファイルの仕様に、変更なしで準拠するものとします。

UTS-39-C1-2. 実装は、プロファイルに追加または削除された文字の正確なリストを提供しますが、それ以外はセクション3.1、識別子のための一般セキュリティプロファイルの仕様に準拠するものとします。

UTS-39-C1.1. 識別子のためのIDNセキュリティプロファイルの実装を主張する実装は、UTS-39-C1.1-1またはUTS-39-C1.1-2のいずれかに準拠するものとします。

UTS-39-C1.1-1. 実装は、セクション3.2、識別子のためのIDNセキュリティプロファイルの仕様に、変更なしで準拠するものとします。

UTS-39-C1.1-2. 実装は、プロファイルに追加または削除された文字の正確なリストを提供しますが、それ以外はセクション3.2、識別子のためのIDNセキュリティプロファイルの仕様に準拠するものとします。

UTS-39-C1.2. 識別子のための電子メールセキュリティプロファイルの実装を主張する実装は、UTS-39-C1.2-1またはUTS-39-C1.2-2のいずれかに準拠するものとします。

UTS-39-C1.2-1. 実装は、セクション3.3、識別子のための電子メールセキュリティプロファイルの仕様に、変更なしで準拠するものとします。

UTS-39-C1.2-2. 実装は、プロファイルに追加または削除された文字の正確なリストを提供しますが、それ以外はセクション3.3、識別子のための電子メールセキュリティプロファイルの仕様に準拠するものとします。

UTS-39-C2. セクション4、紛らわしい文字の検出で定義されている識別子のための以下の紛らわしい文字検出機能のいずれかを実装すると主張する実装は、UTS-39-C2-1またはUTS-39-C2-2のいずれかに準拠するものとします。

1. XとYは単一スクリプトの紛らわしい文字である
2. XとYは混合スクリプトの紛らわしい文字である
3. XとYは全体スクリプトの紛らわしい文字である
4. XはスクリプトセットSにおいて全体スクリプトの紛らわしい文字を持つ

UTS-39-C2-1. 機能の実装は、セクション4、紛らわしい文字の検出の仕様に、変更なしで準拠するものとします。

UTS-39-C2-2. 実装は、プロファイルに追加または削除された文字マッピングの正確なリストを提供しますが、それ以外はセクション4、紛らわしい文字の検出の仕様に準拠するものとします。

UTS-39-C3. 混合スクリプトを検出すると主張する実装は、UTS-39-C3-1またはUTS-39-C3-2のいずれかに準拠するものとします。

UTS-39-C3-1. 実装は、セクション5.1、混合スクリプト検出の仕様に、変更なしで準拠するものとします。

UTS-39-C3-2. 実装は、動作の変更に関する正確な説明を提供しますが、それ以外はセクション5.1、混合スクリプト検出の仕様に準拠するものとします。

UTS-39-C4. 制限レベルを検出すると主張する実装は、UTS-39-C4-1またはUTS-39-C4-2のいずれかに準拠するものとします。

UTS-39-C4-1. 実装は、セクション5.2、制限レベル検出の仕様に、変更なしで準拠するものとします。

UTS-39-C4-2. 実装は、動作の変更に関する正確な説明を提供しますが、それ以外はセクション5.2、制限レベル検出の仕様に準拠するものとします。

UTS-39-C5. 混合数字を検出すると主張する実装は、UTS-39-C5-1またはUTS-39-C5-2のいずれかに準拠するものとします。

UTS-39-C5-1. 実装は、セクション5.3、混合数字検出の仕様に、変更なしで準拠するものとします。

UTS-39-C5-2. 実装は、動作の変更に関する正確な説明を提供しますが、それ以外はセクション5.3、混合数字検出の仕様に準拠するものとします。

3 識別子文字

識別子（「ID」）は、特定のアプリケーションにおける特定のエンティティを参照するために使用される文字列です。特定のアプリケーションでは、1つの識別子は最大で1つの特定のエンティティにマッピングされます。多くのアプリケーションには、識別子に関連するセキュリティ要件があります。一般的な例は、インターネット上のページやその他のリソースを参照するURLです。ユーザーがリソースにアクセスしたい場合、意図したサービスを偽装して悪意のある目的で他のエンティティになりすまそうとする他のエンティティではなく、特定の金融サービスとやり取りしていることをユーザーが確実に把握できることが重要です。これは、識別子に関する一般的なセキュリティ上の懸念、つまり文字列の潜在的な曖昧さを示しています。機械は2つの異なる文字シーケンスを区別することに問題はありませんが、アプリケーションが識別子に使用できるUnicode文字を制限しない場合、人間が識別子を認識し区別することは非常に困難になる可能性があります。この仕様の焦点は、識別子に関連するこのような問題の緩和です。

識別子に使用できる文字を意図的に制限することは、重要なセキュリティ技術です。識別子から文字を除外しても、文書の一般的なテキストなどの他の目的でのそれらの文字の一般的な使用には影響しません。Unicode標準Annex #31、「Unicode識別子と構文」（UAX31）は、どの文字列が識別子として適格であるかを決定するための推奨方法を提供します。UAX #31仕様は、識別子を文字と数字の観点から定義するという一般的な慣行をUnicodeレパートリーに拡張します。

その仕様はまた、他のプロトコルがその方法を基盤として使用し、文字を追加または削除するプロファイルを定義することを許可しています。たとえば、特定のプログラミング言語の識別子は通常、「$」のような文字を追加し、「-」（マイナスとしての使用のため）のような文字を削除します。一方、IDNAは「_」（その他多数）を削除します。Unicode技術標準 #46、「Unicode IDNA互換性処理」（UTS46）、およびIDNA2003、IDNA2008を参照してください。

この文書は、セキュリティが問題となる環境のための追加の識別子プロファイルを提供します。これらは、Unicode標準（Unicode）のプロパティと仕様に基づいた拡張識別子のプロファイルです。これには以下が含まれます：

• Unicode文字データベースで定義されているXID_StartおよびXID_Continueプロパティ（DCore参照）
• Unicodeの「3章 準拠」で定義されているtoCasefold(X)操作
• Unicodeの「3章 準拠」で定義されているNFKCおよびNFKD正規化

これらのプロファイルを定義するために使用されるデータファイルは、UCDファイル形式に従っており、各フィールドは番号で参照され、指定された文字に関連付けられたデータフィールドのセミコロン区切りリストです。詳細については、UCDFormatを参照してください。*

3.1 識別子のための一般セキュリティプロファイル

idmodの下のファイルは、セキュリティが問題となる環境における識別子のプロファイルのためのデータを提供します。ファイルには、使用が制限されることが推奨される文字のセットが含まれています。また、XID_StartおよびXID_Continueプロパティによって定義された文字リストに追加されることが推奨される少数の文字も含まれています。これらは、プログラミング識別子のより広いコンテキストで使用される可能性があるためです。

制限された文字は、一般的でない文字であり、視覚的な紛らわしさをさらに減らすためにブロックすることができます。これらには以下が含まれます：

• 現代では使用されない文字
• 特定の分野のみで使用される文字、例えば典礼文字、音声文字、数学的な文字のような記号
• 非常に小規模なコミュニティによって限定的に使用される文字

制限される文字として指定する文字の選択は、保守的に開始されますが、文字の要件が洗練されるにつれて、将来的に追加が可能になります。時間の経過に伴う変更の処理については、Unicode技術レポート #36、「Unicodeセキュリティに関する考慮事項」のセクション2.10.1、後方互換性（UTR36）を参照してください。

識別子のための一般セキュリティプロファイルに従う実装は、\p{Identifier_Status=Restricted}の文字を一切許可しません。ただし、許可する追加の文字を文書化する場合を除きます。そのような文書化は、\p{Identifier_Type=Technical}のようなプロパティ、または明示的なリスト、あるいはこれらの組み合わせによって文字を指定できます。実装は、\p{Identifier_Status=Allowed}によって示唆されるよりも少ない文字を許可することもできます。たとえば、IDNA2008によって許可される文字のみを許可することができます。

このような追加の一般的な候補には、UAX31の表7、限定使用スクリプトにリストされているスクリプトの文字が含まれます。しかし、これらのスクリプトの文字は、紛らわしい文字の検査や、専門的、非現代的、または一般的でない使用の文字の特定においては優先順位が低くなっています。

正規化同値性は、許可された文字の包含について候補識別子をテストする際に適用されます。たとえば、候補文字列がシーケンス

<u, combining-diaeresis>

であるとします。ターゲット文字列は、次の2つの状況のいずれかで許可されたと見なされます：

1. uが許可され、¨が許可されている場合、または
2. üが許可されている場合

idmodファイル形式の詳細については、セクション7、データファイルを参照してください。*

表1. Identifier_Status と Identifier_Type

Identifier_Status

Identifier_Type

説明

Restricted

Not_Character

未割り当て文字、プライベート使用文字、サロゲート、非空白制御文字。

Deprecated

UnicodeプロパティDeprecated=Yesを持つ文字。

Default_Ignorable

UnicodeプロパティDefault_Ignorable_Code_Point=Yesを持つ文字。

Not_NFKC

NFKC正規化された文字列に現れない文字。

Not_XID

デフォルトのUnicode識別子として適格でない文字。つまり、UnicodeプロパティXID_Continue=Trueを持たない文字。

Exclusion

UAX31の表4、識別子からの除外候補文字に含まれるスクリプトのScript_Extensions値を持つ文字で、表7、限定使用スクリプトまたは表5、推奨スクリプトのスクリプト（「Common」または「Inherited」を除く）を含まない文字。

Obsolete

現代では使用されなくなった文字、または現代のテキストで一般的に使用されない文字。

Technical

専門的な用途：技術的、典礼的など。

Uncommon_Use

一般的でない文字、または使用が限定されている文字（「限定使用」ではないスクリプトに含まれている場合でも）、または使用が不明確な文字。
スクリプトの主要文字よりも一般的でない文字、または「限定使用」の文字と組み合わせて使用される場合があります。
Limited_Use

限定的に使用されているスクリプトの文字：UAX31の表7、限定使用スクリプトに含まれるScript_Extensions値を持つ文字で、表5、推奨スクリプトのスクリプト（「Common」または「Inherited」を除く）を含まない文字。

Allowed

Inclusion

例外的に許可される文字。これには、UAX31の表3a、中間文字のオプションおよび表3b、継続文字のオプション、および一部のIDNA2008の文字が含まれます。ただし、上記でRestrictedとされている特定の文字は除きます。

Recommended

広く日常的に一般的に使用されているスクリプトの文字：UAX31の表5、推奨スクリプトに含まれるScript_Extensions値を持つ文字。ただし、上記でRestrictedとされている文字は除きます。

注： Unicode 15.0では、結合制御文字（ZWJ/ZWNJ）がIdentifier_Type=Inclusionから削除されました。これにより、Identifier_Type=Default_IgnorableおよびIdentifier_Status=Restrictedのプロパティを持つことになります。プログラミング言語識別子プロファイルへのそれらの包含は、ユーザビリティとセキュリティに影響を与えます。

識別子のための一般プロファイルの実装でZWJとZWNJを保持したい場合は、セクション2、準拠に従ってプロファイルの変更を使用することを宣言し、セクション3.1.1、結合制御文字で説明されている制限を実装するようにしてください。

Identifier_StatusとIdentifier_Typeは文字（コードポイント）のプロパティです。正規表現におけるこれらのプロパティの長名と短名、およびその値については、それぞれのデータファイルで文書化されています。詳細については、セクション7、データファイルを参照してください。UTS #18: Unicode正規表現（UTS18）およびUTR #23: Unicode文字プロパティモデル（UTR23）を参照してください。

安定性に関する考慮事項については、永続データの移行を参照してください。

複数の理由で文字を制限する可能性があるため、Identifier_TypeプロパティはRestrictedに対応する複数の値を持つことができます。たとえば、一部の文字はIdentifier_Typeの値としてLimited_UseとTechnicalを持ちます。Not_Character、Deprecated、Default_Ignorable、Not_NFKCのような強い制限を持つ文字には、複数の値は割り当てられません。たとえば、文字がDeprecatedの場合、Uncommon_Useとしてマークしてもあまり意味がありません。使用の修飾子であるObsolete、Uncommon_Use、Technicalについては、Identifier_Type値間の区別は厳密ではなく、1つだけが与えられる場合があります。重要な特性はIdentifier_Status、つまり文字がRestrictedであるかどうかです。

他のカテゴリが適用されない場合、デフォルトのIdentifier_Typeプロパティ値はUncommon_Useであるべきです。セクション3.1.2、Identifier_Type 値の選択を参照してください。*

より多くの情報が文字について収集されるにつれて、このデータは後続のバージョンで変更される可能性があります。これにより、特定の文字のIdentifier_StatusまたはIdentifier_Typeが変更される可能性があります。したがって、ユーザーはこのデータに対して、以前サポートされていた文字または登録のための後方互換性ポリシーを持つことによって、後続のバージョンでの変更に備える必要があります。Identifier_StatusとIdentifier_Typeの値は、大文字小文字を区別せず、ハイフンとアンダースコアを無視して比較されるべきです。

Restricted文字は、識別子での使用を検討する際に注意して扱うべきであり、問題の環境で許可する正当な理由がない限り、無効にすべきです。しかし、Identifier_Status=Allowedの文字のセットは、通常、実装によってそのまま使用されるわけではありません。代わりに、識別子構文によってサポートされる文字のセットCにフィルターとして適用され、新しいセットC'が生成されます。通常、Cから特定の文字または文字クラスが例外文字として保持されます。

C' = (C ∩ {Identifier_Status=Allowed}) ∪ Exception

実装は単にC'に新しい識別子の使用を制限するか、他の戦略を適用することができます。たとえば、C'の外（ただしC内）にある文字を含むIDの登録のために異議申し立てプロセスがあるかもしれませんし、識別子のルックアップのためのユーザーインターフェースでは、何らかの警告が適切かもしれません。詳細については、UTR36を参照してください。*

Exception文字は実装固有のものになります。たとえば、特定の С'実装は、UnicodeプロパティXID_Continue=Falseを持つ「$」、「-」、「.」のようなException文字を追加することによって、デフォルトのUnicode識別子構文を拡張する場合があります。これらの文字はその識別子構文に固有であり、Identifier_Status=Allowedセットに含まれていなくても保持されます。一部の実装では、サポートされている特定の言語のCLDR（CLDR）の例示文字を追加したい場合もあります。

Identifier_Type=Inclusionの文字には、文字や数字ではないが、一部の言語で単語内に使用される文字がすでに含まれています。たとえば、カタルーニャ語で必要とされるため、U+00B7（·）MIDDLE DOTを識別子で許可することが推奨されます。

実装は、この文書で議論されている他の制限、たとえば紛らわしい文字のチェックや混合スクリプト検出を行うこともできます。*

3.1.1 結合制御文字

一般セキュリティプロファイルによって除外された特定の文字によって作成される視覚的な区別（特に結合制御文字）は、特定の言語では必要です。これらの文字を包括的に除外すると、それらの言語の一般的な単語やフレーズの正しい視覚的表現で識別子を作成することが不可能になります。

「現代の慣習的な使用」における用語のより自然な表現を提供しようとする識別子システムは、これらの文字を入力および表示で許可すべきですが、それらが必要なコンテキストに限定すべきです。「現代の慣習的な使用」という用語には、新聞、雑誌、一般向け出版物で使用される文字が含まれます。通り標識、商業看板、一般的な地理名や会社名の構成要素など。これには、数学的表現、古風なスクリプトや単語の使用、または半形や結合形の孤立した例示などの教育目的、または典礼目的のような技術的または学術的な使用は含まれません。

これらのフォーマット文字を特定のコンテキストに制限する目標は次のとおりです：

• 通常のテキストで必要な場所でこれらの文字の使用を許可する
• 可視的な区別が生じないケースを可能な限り除外する
• 正規表現のような標準的なメカニズムで容易に実装できるほど単純である

一般セキュリティプロファイルに従い、追加の文字ZWJおよびZWNJを許可する実装は、それらがセクション3.1.1.1、結合制御文字の限定されたコンテキストの条件A1、A2、およびBを満たす場合にのみ、それらを許可するものとします。それ以外の場合は、追加のコンテキストを文書化するものとします。

より高度な実装は、より詳細なテストのためにスクリプト固有の情報を使用できます。特に、それらは次のことができます：

1. 結合制御文字を禁止する。A1、A2、およびBの条件を満たすシーケンスで、一般的なフォントでは、結果のシーケンスの表示が、結合制御文字を除いた同じシーケンスの表示と通常は区別されない場合。
2. 結合制御文字を許可する。A1、A2、およびBの条件を満たさないシーケンスで、一般的なフォントでは、結果のシーケンスの表示が、結合制御文字を除いた同じシーケンスの表示と通常は区別される場合。以下の正規表現は、通常、明確なレンダリング結果をもたらすシーケンスを表します。これらは、A1で説明されている表記法を使用します。

/$L ZWNJ $V $L/

/$L ZWJ $V $L/

3.1.1.1 結合制御文字の限定されたコンテキスト

「現代の慣習的な使用」における用語のより自然な表現を提供しようとする実装は、以下の結合制御文字を、A1、A2、およびBで指定された限定されたコンテキストで許可すべきです。

U+200C ZERO WIDTH NON-JOINER (ZWNJ)
U+200D ZERO WIDTH JOINER (ZWJ)

また、A1、A2、およびBのそれぞれに組み込まれた2つのグローバル条件があります：

• スクリプト制限。 以下の各ケースでは、指定されたシーケンスは、単一のスクリプト（CommonおよびInheritedスクリプト文字を無視した後）のみで構成されなければなりません。
• 正規化。 以下の各ケースでは、指定されたシーケンスはNFC形式でなければなりません。（NFCである必要がない識別子をテストするには、まずNFC形式に変換してから条件をテストします。）

実装は、文字が視覚的な効果を持たない、または効果が意味的な重要性を持たない他の状況をいくつか排除するために、以下よりも厳しい制限を課すこともできます。*

A1. ZWNJを以下のコンテキストで許可する：

連結を切断する。 すなわち、Joining_Typeプロパティに基づくコンテキストで、次のものから構成される：

• 左結合または両結合文字、それに続くゼロ個以上の透明文字、それに続くZWNJ、それに続く右結合または両結合文字

これは、次の正規表現（Perlスタイル構文）に対応します： /$LJ $T ZWNJ $RJ/*

ここで、$Tのような文字クラスは、次のようなUnicodeプロパティ（UnicodeSet表記法に類似）で定義できます：

$T = \p{Joining_Type=Transparent}
$RJ = [\p{Joining_Type=Dual_Joining}\p{Joining_Type=Right_Joining}]
$LJ = [\p{Joining_Type=Dual_Joining}\p{Joining_Type=Left_Joining}]

たとえば、ペルシャ語の単語<Noon, Alef, Meem, Heh, Alef, Farsi Yeh>を考えます。ZWNJがない場合、「～の名前」と翻訳されます（最初の行）。HehとAlefの間にZWNJがある場合、「文字」を意味します（図1の2番目の行）。

図1. ZWNJを使用したペルシャ語の例

A2. 結合コンテキストでZWNJを許可する：

結合コンテキスト内。 すなわち、次の形式のシーケンス：

• 文字、それに続くヴィラマ、それに続くZWNJ（オプションで特定の非スペースマークの前または後に続く）、それに続く文字。

これは次の正規表現（Perlスタイル構文）に対応します： /$L $M $V $M₁ ZWNJ $M₁* $L/**

ここで：

$L = \p{General_Category=Letter}
$V = \p{Canonical_Combining_Class=Virama}
$M = \p{General_Category=Mn}
$M₁ = [\p{General_Category=Mn}&\p{CCC≠0}]

たとえば、マラヤーラム語の目撃者という単語は図2に示されています。2行目のZWNJがない形式はこのケースでは正しくありません。

図2. ZWNJを使用したマラヤーラム語の例

B. 結合コンテキストでZWJを許可する：

結合コンテキスト内。 すなわち、次の形式のシーケンス：

• 文字、それに続くヴィラマ、それに続くZWJ（オプションで特定の非スペースマークの前または後に続く）、そしてIndic_Syllabic_Category=Vowel_Dependentのタイプの文字に続かない。

これは次の正規表現（Perlスタイル構文）に対応します： /$L $M $V $M₁ ZWJ (?!$D)/**

ここで：

$L= \p{General_Category=Letter}
$V = \p{Canonical_Combining_Class=Virama}
$M = \p{General_Category=Mn}
$M₁ = [\p{General_Category=Mn}&\p{CCC≠0}]
$D = \p{Indic_Syllabic_Category=Vowel_Dependent}

たとえば、スリランカの国のシンハラ語の単語は、図3の最初の行に示されており、スペース文字とZWJの両方を使用しています。スペースを削除すると、図3の2番目の行に示されているテキストになりますが、これはまだ判読可能ですが、ZWJを完全に削除すると、「Sri」クラスターの表示が変更され、図3の3番目の行に示されている許容できないテキスト表示になります。

図3. ZWJを使用したシンハラ語の例

注： A1、A2、およびBの制限は、「Unicodeコードポイントと国際化ドメイン名アプリケーション（IDNA）のコンテキストルールレジストリ」（IDNA2008）の付録A、コンテキストルールで定義されているCONTEXTJルールよりも厳格です。特に、A1はZWNJの後に透明文字を許可しませんが、A2とBは、単一の先行ヴィラマだけでなく、実際の結合クラスターを示す拡張コンテキストを必要とします。したがって、これらの制約を満たす識別子は、IDNにおける結合制御文字のCONTEXTJルールも満たします。多くのレジストリが、CONTEXTJによって要求されるものよりも追加の制限を許可されるIDNに課していることに注意してください。*

3.1.1.2 制限事項

A1、A2、およびBの制限は視覚的な紛らわしさを大幅に軽減しますが、それを防ぐことはできません。たとえば、タミル語では結合制御文字が1つの特定のケースでのみ使用されるため、これらのルールがタミル語で許可するシーケンスのほとんどは、実際には視覚的に紛らわしいものです。したがって、関係するスクリプトに関する知識に基づいて、実装はセクション3.1.1.1、結合制御文字の限定されたコンテキストで指定されたよりも厳しい制限を設けることを選択する場合があります。たとえば、結合制御文字をコンテキストで無効にする一方で、例外的なシーケンスを明示的に提供するなどです。

また、結合子がヴィラマの前に来ることで、一部のスクリプトで視覚的な区別が生じるケースもあります。この区別が識別子において保持する価値があるほど重要であるかどうかは、現時点では不明です。詳細については、UTR #36: Unicodeセキュリティに関する考慮事項（UTR36）を参照してください。*

パフォーマンス。 識別子の解析はパフォーマンスに敏感なタスクになる可能性があります。しかし、これらの文字は実際には非常にまれであるため、正規表現（または同等の処理）はめったに呼び出される必要がありません。したがって、これらのテストは全体としてパフォーマンスに大きなコストを追加するべきではありません。*

3.1.2 Identifier_Type 値の選択

以下の識別子タイプは、単独または組み合わせて割り当てることができます。値は入手可能な最良の情報に基づいており、新しい情報が入手可能になったときに更新される可能性があります。特に、文字が一般的な書記体系では一種のタイプであり、別のコンテキストでは異なるタイプである場合、複数の分類が可能になることがあります。*

• Uncommon_Use は、生きている言語の正書法における文字の使用に焦点を当てています。Uncommon_Useは、広く使用されている正書法における「一般的な日常使用」に対応するレベルの使用に関する確認済みまたは信頼できるデータの不在を表すこともできます。Uncommon_Useは、除外スクリプト以外のすべてのスクリプトの新規エンコード文字のデフォルトですが、一般的な現代の使用において十分なレベルの使用が確認されている場合を除きます。
  • U+3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARKのような結合マークが、推奨文字のNFD形式でのみ必要な場合、Identifier_Type Uncommon_Useが割り当てられています。正規化されていないテキスト、またはNFDのテキストを扱う識別子システムは、正規化解除におけるすべての必要な文字セットを追加したい場合があります。
• Obsolete は、文字が一般的な現代の使用においてどの程度使用されているかに焦点を当てています。書記体系、または文字を使用した正書法が使用されなくなった場合、または特定のコンテキストで文字が使用されなくなった場合、Obsoleteとマークされます。文字は書記体系のコンテキストで廃止される可能性があり、書記体系全体が使用されなくなったとは限りません。文字は広く使用されている書記体系で廃止される可能性がありますが、Uncommon_Useでマークされるレベルで使用されている正書法の一部である可能性もあります。
• Technical は、使用の目的に焦点を当てています。文字が特定の種類のテキストに限定されている場合、または日常使用されていない表記法の一部である場合、Technicalとして分類するのが適切です。Technicalな用途には、典礼テキスト、詩、音声表記などが含まれます。文字は一般的な技術的使用を持つ場合がありますが、Uncommon_Useでマークされるレベルで1つ以上の正書法で使用される場合もありますし、一般的な使用のための文字としてObsoleteである可能性もあります。
• Inclusion は、Allowedな句読点や句読点のように見える文字に焦点を当てています。各識別子環境で注意深くレビューする必要があります。たとえば、文字がその環境の構文文字である場合、またはそれに紛らわしい場合などです。*

他の識別子タイプは、文字の他のプロパティ値によって、ほぼ、または完全に決定されるため、自動的に割り当てられます。*

3.2 識別子のためのIDNセキュリティプロファイル

この文書のバージョン1は、IDNA2003に適用される操作とデータについて定義しましたが、これはIDNA2008およびUnicode技術標準 #46、「Unicode IDNA互換性処理」（UTS46）に置き換えられました。識別子変更データは、使用されているIDNAの仕様に関わらず適用できます。詳細については、IDN FAQを参照してください。*

しかし、実装はドメイン名に適用されるこの文書の他の機能、たとえば制限レベルに準拠を主張できます。*

さらに、IDNに非常に役立つ他の仕様があります。特に、RFC7940は、なりすましに対するセキュリティをサポートする機能を備えたIDNのプロファイルを表現するための機械可読形式を指定しています。そのようなプロファイルは「ラベル生成ルール」（LGR）として知られており、通常はスクリプトまたは言語ごとに定義され、同じ「DNSゾーン」に対して複数のLGRをサポートする機能を備えています。*

LGR形式を使用して、実装は次のことができます：

1. 文字または列挙された文字シーケンスのレパートリーを選択する。 文字セットの選択は、IDNA2008の許可値とIdentifier_StatusまたはIdentifier_Typeの間の共通部分を考慮に入れることができます。
2. 特定の文字を、列挙されたシーケンスの1つ以上に制限する。 これは、ダイアクリティカルマークを期待されるコンテキストに制限したり、特定のシーケンスにのみ含まれる一部の文字の単独使用を除外したりするのに役立ちます。
3. コンテキストルールを提供する。 コンテキストルールは、ラベル内の文字またはシーケンスの必須または禁止コンテキストを記述するアンカー付き正規表現です。これは、インド系スクリプトの制限に役立ち、レンダリングエンジンが明確にレンダリングできる安全な境界内に留まることができます。1つのアプリケーションは、結合制御文字の限定されたコンテキストを実装することです。
4. 2つの文字/シーケンスを互いの「ブロックされた」バリアントにする。 いずれか一方が許可されますが、最初に登録されたラベルは、その位置にあるバリアント文字またはシーケンスのみが異なるラベルをブロックします。
5. 「全体ラベル評価」ルールを使用して識別子を検証する。 WLEルールは、有効または無効なラベルのパターンを記述する正規表現です。これは、たとえば、同じラベルでの数字セットの混合を防ぐため、またはラベルが地域的な文字の代替の選択において一貫していることを確認するために使用できます。*

RFC7940で定義されているLGRメカニズムでは、正規表現をUnicodeプロパティまたはLGRの文字に割り当てられたカスタム属性の観点から指定できます。同じメカニズムを他の種類の識別子に適用できます。詳細については、ICANNを参照してください。*

3.3 識別子のための電子メールセキュリティプロファイル

SMTP拡張国際化電子メールは、国際化電子メールアドレス（EAI）の仕様を提供します。しかし、それらはそれらのアドレスをセキュリティ問題についてテストするための仕様を提供しません。このセクションでは、それのために使用できる電子メールセキュリティプロファイルを提供します。これは、次のようなさまざまな目的で使用できます：

1. 電子メールアドレスが登録されるとき、プロファイルを満たさないものをフラグ付けする：
   • 登録を禁止するか、
   • 異議申し立てプロセスを許可する。
2. プレーンテキストのリンク化で電子メールアドレスが検出されるとき：
   • 識別子がプロファイルを満たさない場合は、リンク化しない。
3. 受信メールに電子メールアドレスが表示されるとき：
   • プロファイルを満たさない場合は、波線の下線で疑わしいとしてフラグ付けする。
   • 表示の問題を防ぐために、引用符付き文字列部分から文字をフィルタリングする。*

このプロファイルはEAIから文字を除外しません。代わりに、登録、リンク化、および通知に使用できるプロファイルを提供します。目的は、構造的に不健全なアドレスや予期しない不要なものを含むアドレスをフラグ付けすることです。*

電子メールアドレスは、3つの主要な部分から形成されます。（電子メールアドレスにはさらに多くの要素がありますが、これらはUnicodeセキュリティが重要である要素です。）たとえば：

"Joey" joe31834@gmail.com

• ドメインパートは「gmail.com」です
• ローカルパートは「joe31834」です
• 引用符付き文字列パートは「Joey」です

この仕様の識別子のための電子メールセキュリティプロファイルセクションの要件を満たすには、識別子は指定された<制限レベル>について、以下の条件を満たさなければなりません。*

ドメインパート

電子メールアドレスのドメインパートは、セクション3.2、識別子のためのIDNセキュリティプロファイルを満たし、UTS46の準拠条項を満たさなければなりません。*

ローカルパート

電子メールアドレスのローカルパートは、以下のすべての条件を満たさなければなりません：

1. NFKC形式でなければならない
2. 制限レベル検出からレベル=<制限レベル>以下でなければならない
3. 混合数字検出に従って混合数字システムを持ってはならない
4. RFC 5322 §3.2.3のdot-atom-textを満たさなければならない。ここでatextは次のように拡張される：

C ≤ U+007F の場合、C は §3.2.3で定義される。（すなわち、C ∈ !#-'*+-/-9=?A-Z^-~）。このリストは§3.2.3にあるものをコピーしたもので、ASCIIについてはHTML5に従います。*

C > U+007F の場合、以下の両方の条件が真である：

1. Cは一般セキュリティプロファイルのIdentifier_Status=Allowedを持つ
2. Cが最初の文字の場合、それはUAX31のデフォルト識別子構文のXID_Startでなければならない

RFC 5322 §3.2.3では次のように注意されています：

dot-atom-text   =   1*atext *("." 1*atext)

つまり、ドットはローカルパートにも現れる可能性がありますが、先頭、末尾、または連続して2つ現れることはできません。より一般的な正規表現構文では、これは次のようになります：

dot-atom-text   =   atext+ ("." atext+)*

双方向制御文字やその他のフォーマット文字は、上記の通り、ローカルパートでは明示的に無効になっていることに注意してください。*

引用符付き文字列パート

電子メールアドレスの引用符付き文字列パートは、以下の条件を満たさなければなりません：

1. NFC形式でなければならない。
2. ステートフルな双方向フォーマット文字を含んではならない。
   • すなわち、LRM、RLM、およびALMを除く[:bidicontrol:]は、双方向制御文字が引用符の外の文字の順序に影響を与える可能性があるためです。
3. 連続して4つ以上の非スペースマークを含んではならず、同じ非スペースマークのシーケンスを含んではならない。
4. 混合スクリプト、シンボル（絵文字を含む）などを含めることができます。*

その他の問題

上記の制限は、引用符付き文字列パートをローカルパートまたはドメインパートと混同する可能性のある双方向再順序付けを防ぐには不十分です。それを防ぐために、実装は表示時にこれらの各部分の周りに双方向アイソレート（または同等物）を使用することができます。*

実装は、紛らわしさのチェックなど、他のチェックを使用したり、セーフブラウジングのようなサービスを使用したりすることも望ましい場合があります。*

深刻な実際の問題は、クライアントが特定の電子メールサーバーのIDルールを知らないことです。つまり、2つの電子メールアドレスが同等と見なされるのはいつかということです。たとえば、mark@macchiato.comとMark@macchiato.comはサーバーによって同じように扱われますか？残念ながら、サーバーにどのようなIDルールに従っているかを問い合わせる方法はありません。この問題に対処するために使用される技術の1つは、大文字小文字を区別しない、ドットを区別しない、またはその両方である電子メールプロバイダーのホワイトリストを持つことです。*

4 紛らわしい文字の検出

confusablesのデータは、2つの文字列が視覚的に紛らわしい時期を判断するためのメカニズムを提供します。これらのファイル内のデータは、時間とともに洗練され、拡張される可能性があります。時間の経過に伴う変更の処理については、この文書の移行セクションを参照してください。*

データは、ソース文字からプロトタイプへのマッピングを提供します。プロトタイプは、各クラスに例示文字を持つ1つ以上のシンボルクラスのシーケンスとして考えるべきです。たとえば、文字U+0153（œ）、LATIN SMALL LIGATURE OEは、2つのシンボルクラスからなるプロトタイプを持っています。1つは例示文字U+006F（o）を持ち、もう1つは例示文字U+0065（e）を持ちます。入力文字にデータファイルで明示的に定義されたプロトタイプがない場合、プロトタイプは例示文字を持つシンボルクラスから構成されると想定されます。*

入力文字列Xについて、internalSkeleton(X)を文字列に対する次の変換として定義します：

1. XをUAX15で説明されているNFD形式に変換します。
2. X内のDefault_Ignorable_Code_Pointプロパティを持つ文字を削除します。
3. Xの各文字のプロトタイプを指定されたデータに従って連結し、例示文字の文字列を生成します。
4. NFDを再適用します。*

入力文字列Xと方向𝑑 ∈ {RTL, LTR, FS}について、bidiSkeleton(𝑑, X)を文字列に対する次の変換として定義します：

1. Unicode双方向アルゴリズム（UAX9）のルールL2までを、Xを孤立させて適用することにより、Xのコードポイントを表示用に並べ替えます。𝑑≠FSの場合、𝑑=RTLの場合はレベル1、𝑑=LTRの場合はレベル0を設定するためにプロトコルHL1を適用します。これにより、並べ替えられた文字シーケンスRが得られます。
2. ルールL3のUBAを適用します：R内の結合マークをベースの後に移動させます。これによりシーケンスR'が得られます。
3. UBAのルールL4によりミラーリングされるグリフを持つ文字を、そのBidi_Mirroring_Glyphプロパティの値に置き換えます。これによりR''が得られます。
4. bidiSkeleton(𝑑, X)は、internalSkeleton(R″)となります。*

文字列XとYは、bidiSkeleton(𝑑, X) = bidiSkeleton(𝑑, Y)である場合にのみ、𝑑-confusableであると定義されます。これはX ≒ Y (𝑑)と略されます。*

このメカニズムはデータに推移性を課すため、X ≒ Y (𝑑) かつ Y ≒ Z (𝑑) ならば X ≒ Z (𝑑) となります。与えられた文字間の「近さ」を示すメトリックを提供することにより、より洗練された紛らわしい文字検出を提供することは可能です。しかし、それは計算上非常にコストが高く、より洗練されたデータが必要なため、現時点ではより単純なメカニズムが選択されています。これは、場合によってはテストが過度に包括的になる可能性があることを意味します。*

注： internalSkeleton操作は文字のBidi_Classを変更する可能性があるため、並べ替えおよびミラーリングステップと可換ではなく、それらの後に実行する必要があります。*

例： コードポイントシーケンスS₁とS₂はLTR-confusableです：

S₁ ≔ "A1<שׂ" = (LATIN CAPITAL LETTER A, DIGIT ONE, LESS-THAN SIGN, HEBREW LETTER SHIN, HEBREW POINT SIN DOT)
S₂ ≔ "Αשֺ>1" = (GREEK CAPITAL LETTER ALPHA, HEBREW LETTER SHIN, HEBREW POINT HOLAM HASER FOR VAV, GREATER-THAN SIGN, DIGIT ONE)

bidiSkeleton(LTR, S₁)の計算：

R₁ = (LATIN CAPITAL LETTER A, DIGIT ONE, LESS-THAN SIGN, HEBREW POINT SIN DOT, HEBREW LETTER SHIN)
R′₁ = (LATIN CAPITAL LETTER A, DIGIT ONE, LESS-THAN SIGN, HEBREW LETTER SHIN, HEBREW POINT SIN DOT)
R″₁ = (LATIN CAPITAL LETTER A, DIGIT ONE, LESS-THAN SIGN, HEBREW LETTER SHIN, HEBREW POINT SIN DOT)
bidiSkeleton(LTR, S₁) = internalSkeleton(R″₁) = (LATIN CAPITAL LETTER A, LATIN SMALL LETTER L, LESS-THAN SIGN, HEBREW LETTER SHIN, COMBINING DOT ABOVE)

bidiSkeleton(LTR, S₂)の計算：

R₂ = (GREEK CAPITAL LETTER ALPHA, DIGIT ONE, GREATER-THAN SIGN, HEBREW POINT HOLAM HASER FOR VAV, HEBREW LETTER SHIN)
R′₂ = (GREEK CAPITAL LETTER ALPHA, DIGIT ONE, GREATER-THAN SIGN, HEBREW LETTER SHIN, HEBREW POINT HOLAM HASER FOR VAV)
R″₂ = (GREEK CAPITAL LETTER ALPHA, DIGIT ONE, LESS-THAN SIGN, HEBREW LETTER SHIN, HEBREW POINT HOLAM HASER FOR VAV)
bidiSkeleton(LTR, S₂) = internalSkeleton(R″₂) = (LATIN CAPITAL LETTER A, LATIN SMALL LETTER L, LESS-THAN SIGN, HEBREW LETTER SHIN, COMBINING DOT ABOVE)

これらのシーケンスはRTL-confusableではないことに注意してください。実際、右から左への段落では、文字列は異なって見えます：

S₁ = "A1<שׂ"
S₂ = "Αשֺ>1"

LTR、RTL、およびFSの紛らわしさは、文字列が単一スクリプトであること、または少なくとも単一方向であることを強制することが不適切な場合に、使用すべきです。これはプログラミング言語識別子のケースです。Unicode技術標準 #55、Unicodeソースコード処理（UTS55）のセクション5.1、紛らわしさ緩和診断を参照してください。*

bidiSkeletonは、双方向アルゴリズムを適用する必要があるため、internalSkeletonよりも計算コストが高くなります。しかし、高速パスを使用できます。𝑑=LTRで、XがRまたはALのbidiクラスを持つ文字を含まない場合、bidiSkeleton(𝑑, X) = internalSkeleton(X)となります。*

さらに、文字列に明示的な方向フォーマット文字が含まれていないことがわかっている場合（Unicode標準Annex #31、Unicode識別子と構文（UAX31）で定義されているUAX31-R1デフォルト識別子のケースなど）、アルゴリズムは大幅に簡略化できます。Xルールは単純であり、Unicode双方向アルゴリズムの方向ステータススタックの必要性をなくすためです。この場合、可能な最高解決レベルは2になります。Unicode標準Annex #9、Unicode双方向アルゴリズム（UAX9）の表5、暗黙レベルの解決を参照してください。*

注： bidiSkeleton(𝑑, X)およびbidiSkeleton(𝑑, Y)という文字列は、表示用ではありません。さらに、それらはUnicodeのバージョン間で安定しないため、bidiSkeletonの計算に同じUnicodeバージョンを使用するシステム間でのみ交換できます。それらを保存する場合、bidiSkeletonの計算に使用されるUnicodeバージョンを更新する際に再計算する必要があります。それらはハッシュコードに似た中間処理形式と見なされるべきです。例示文字は、識別子文字であるとは保証されません。*

適切な方向を持つ双方向紛らわしさを利用することが可能であれば望ましいです。しかし、識別子がどの方向で表示されるかわからない場合、および双方向再順序付けを考慮しなかった以前の紛らわしさ定義との互換性のために、操作skeletonはskeleton(X) = bidiSkeleton(LTR, X)として定義されます。文字列XとYは、skeleton(X) = skeleton(Y)である場合にのみconfusableであると定義されます。これはX ≅ Yと略されます。*

注： Unicode外の紛らわしい文字検出の一部の実装では、異なる用語が使用されています。特に、ICANNルートゾーンラベル生成ルール（RZLGR5）では、Xのバリアントという用語はXと紛らわしいというプロパティに似たものに使用され、インデックスバリアントという用語はスケルトンの同等物に使用されます。*

定義

紛らわしい文字は、単一スクリプト紛らわしい文字、混合スクリプト紛らわしい文字、および全体スクリプト紛らわしい文字の3つのクラスに分類されます。これらは以下で定義されます。すべての紛らわしい文字は、単一スクリプト紛らわしい文字または混合スクリプト紛らわしい文字のいずれかであり、両方ではありません。すべての全体スクリプト紛らわしい文字は、混合スクリプト紛らわしい文字でもあります。*

XとYは、それらが紛らわしく、かつそれらの解決済みスクリプトセットが少なくとも1つの要素を共有する場合にのみ、単一スクリプト紛らわしい文字です。*

例：「ljeto」と「ljeto」（クロアチア語で「夏」を意味する）はラテン文字です。最初の単語は4つのコードポイントのみを使用し、最初のコードポイントはU+01C9（lj）LATIN SMALL LETTER LJです。*

XとYは、それらが紛らわしいが、それらの解決済みスクリプトセットが共通の要素を持たない場合に混合スクリプト紛らわしい文字です。*

例：「paypal」と「pаypаl」。後者の単語には、文字U+0430（ а ）CYRILLIC SMALL LETTER Aが含まれています。*

XとYは、それらが混合スクリプト紛らわしい文字であり、かつそれぞれが単一スクリプト文字列である場合に全体スクリプト紛らわしい文字です。*

例：「scope」（ラテン文字）と「ѕсоре」（キリル文字）。*

セクション5で述べたように、解決済みスクリプトセットは、Script_Extensions {Common}および{Inherited}を持つ文字を無視し、CJKスクリプトを持つ文字にそれぞれの文字体系を追加します。Script_Extensionsプロパティ値がCOMMONまたはINHERITEDの文字は、スクリプトの違いをテストする際には無視されます。*

データファイル形式

データファイル内の各行は次の形式です：フィールド1はソース、フィールド2はターゲット、フィールド3は廃止されており、常に「MA」という文字が含まれています。例：

0441 ; 0063 ; MA # ( с → c ) CYRILLIC SMALL LETTER ES → LATIN SMALL LETTER C #

2CA5 ; 0063 ; MA # ( ⲥ → c ) COPTIC SMALL LETTER SIMA → LATIN SMALL LETTER C # →ϲ→

#以降のすべてはコメントであり、情報提供のみを目的としています。コメントの後のアスタリスクは、その文字がXID文字でないことを示します（UAX31）。コメントには文字名が含まれています。*

実装が紛らわしいデータを使用する場合、変換は冪等であるため、マッピングを再帰的に適用する必要はありません。すなわち、*

internalSkeleton(internalSkeleton(X)) = internalSkeleton(X)

データが推移性によって導出された場合、コメントの最後に余分なコメントがあります。たとえば、上記の例では、導出は次のとおりです：

1. ⲥ (U+2CA5 COPTIC SMALL LETTER SIMA)
2. → ϲ (U+03F2 GREEK LUNATE SIGMA SYMBOL)
3. → c (U+0063 LATIN SMALL LETTER C) *

データはバージョン間で変更される可能性があります。データが同じ場合でも、ファイル内の行の順序はバージョン間で変更される可能性があります。詳細については、移行を参照してください。*

注： 製造上の問題により、7.0より前のバージョンではすべてのケースで冪等性が維持されていませんでした。詳細については、移行を参照してください。*

4.1 全体スクリプトの紛らわしい文字

一部のアプリケーションでは、指定された入力文字列に全体スクリプトの紛らわしい文字があるかどうかを判断することが役立ちます。たとえば、キリル文字を使用した識別子「ѕсоре」は、セクション5.2、制限レベル検出で説明されている単一スクリプトテストに合格しますが、なりすまし試行である可能性が高いです。*

単一スクリプト文字列Xに全体スクリプトの紛らわしい文字があるかどうかを判断することは可能です：

1. Q、すなわちXと紛らわしいすべての文字列のセットを考慮します。
2. Qから、その解決済みスクリプトセットがXの解決済みスクリプトセットと交差するすべての文字列を削除します。
3. Qが空でなく、単一スクリプト文字列を含む場合、TRUEを返します。
4. それ以外の場合は、FALSEを返します。*

上記の論理的な説明は、テストのための参照実装として使用できますが、特に効率的ではありません。本番実装は、同じ結果を生成する限り最適化できます。*

紛らわしいデータには、ラテン文字とキリル文字のテキスト間の多数のマッピングが含まれていることに注意してください。このため、上記のアルゴリズムは、ラテン文字またはキリル文字で書かれた多数の正当な文字列を、全体スクリプトの紛らわしい文字としてフラグ付けする可能性が高いです。全体スクリプトの紛らわしい文字を効果的に使用するには、文字列が全体スクリプトの紛らわしい文字を持つかどうか、およびそれらの全体スクリプトの紛らわしい文字がどのスクリプトを持つかを判断することがしばしば役立ちます。*

この情報は、たとえば、ドメイン名のラベルのスクリプトがTLD（トップレベルドメイン）のスクリプトと同じでない場合など、全体スクリプトの紛らわしい文字の妥当な使用と疑わしい使用を区別するために使用できます。*

• キリル文字ラベルとTLD（.ruまたは.рф）のドメイン名
• 中国語ラベルとTLD（.com.auまたは.com）のドメイン名
• ラテン文字と紛らわしくないキリル文字ラベルとTLD（.com.auまたは.com）のドメイン名*

全体スクリプトの紛らわしい文字の使用が疑わしいかどうかを判断するプロセスは、単にドメイン名のラベルのスクリプトを確認するよりも複雑です。*

文字列Xに対する全体スクリプトの紛らわしい文字を含むすべてのスクリプトを判断するために、次の高レベルアルゴリズムを使用できます：

1. Q、すなわちXと紛らわしいすべての文字列のセットを考慮します。
2. Qから、その解決済みスクリプトセットが∅またはALLであるすべての文字列を削除します（すなわち、単一スクリプト文字列とCommonのみの文字を持つもののみを保持します）。
3. 残りのQ内のすべての文字列の解決済みスクリプトセットの和集合を取ります。*

通常どおり、このアルゴリズムは定義のみを目的としており、実装は同じ結果を生成する最適化されたルーチンを使用する必要があります。*

4.2 混合スクリプトの紛らわしい文字

混合スクリプトの紛らわしい文字の存在を判断するために、同様のプロセスを使用できます：

1. Q、すなわちXと紛らわしいすべての文字列のセットを考慮します。
2. Qから、その解決済みスクリプトセットがXの解決済みスクリプトセットと交差するすべての文字列を削除します。
3. Qが空でなければ、TRUEを返します。
4. それ以外の場合は、FALSEを返します。*

上記の論理的な説明は、テストのための参照実装として使用できますが、特に効率的ではありません。本番実装は、同じ結果を生成する限り最適化できます。*

紛らわしいデータによって提供されるマッピングの数により、上記のアルゴリズムは、潜在的な混合スクリプトの紛らわしい文字として多数の正当な文字列をフラグ付けする可能性が高いことに注意してください。*

5 検出メカニズム

5.1 混合スクリプト検出

Unicode標準は、文字のスクリプトを決定し、混合スクリプトテキストを検出するために使用できる情報を提供します。スクリプトの決定は、UAX #24、Unicodeスクリプトプロパティ（UAX24）に従い、Unicode文字データベース（UCD）のデータを使用します。*

文字の拡張スクリプトセットを、以下の2つの変更を加えた文字のScript_Extensionsとして定義します。*

1. 複数のスクリプトを含む文字体系のエントリ — Hanb (Han with Bopomofo), Hntl (Traditional Han with Latin), Jpan (Japanese), Kore (Korean) — は、以下のルールに従って追加されます。
   1. Script_ExtensionsにHani (Han)が含まれる場合、Hanb, Hntl, Jpan, Koreを追加します。
   2. Script_ExtensionsにHira (Hiragana)が含まれる場合、Jpanを追加します。
   3. Script_ExtensionsにKana (Katakana)が含まれる場合、Jpanを追加します。
   4. Script_ExtensionsにHang (Hangul)が含まれる場合、Koreを追加します。
   5. Script_ExtensionsにBopo (Bopomofo)が含まれる場合、Hanbを追加します。
   6. Script_ExtensionsにLatn (Latin)が含まれる場合、Hntlを追加します。
2. Zyyy (Common)またはZinh (Inherited)を含むセットは、ALL、すなわちすべてのスクリプト値のセットとして扱われます。*

Script_ExtensionsデータはUnicode文字データベース（UCD）からのものです。Script_ExtensionsプロパティおよびJpan、Kore、Hntl、Hanbの詳細については、UAX #24、Unicodeスクリプトプロパティ（UAX24）を参照してください。*

文字列の解決済みスクリプトセットを、文字列内のすべての文字の拡張スクリプトセットの交差として定義します。*

文字列は、その解決済みスクリプトセットが空である場合に混合スクリプトであると定義され、その解決済みスクリプトセットが空でない場合に単一スクリプトであると定義されます。*

注： 「単一スクリプト文字列」という用語は混乱を招く可能性があります。これは、解決済みスクリプトセットに1つだけのスクリプトがあるという意味ではなく、少なくとも1つのスクリプトがあるという意味です。たとえば、「〆切」という文字列は単一スクリプトです。なぜなら、それはその解決済みスクリプトセットに複数のスクリプト {Hani, Hntl, Hanb, Jpan, Kore} を持つからです。*

文字列が混合スクリプトを持つかどうかを検出するAPIを提供するだけでなく、それらのスクリプトを返すAPIを提供することも有用です。以下の例を参照してください。*

表1a. 混合スクリプトの例

スクリプトのセットが文字列をカバーするとは、そのセットと文字列内のすべての文字の拡張スクリプトセットとの交差が空でないことを意味します。言い換えれば、文字列内のすべての文字がカバーセットと少なくとも1つのスクリプトを共有する場合です。たとえば、{Latn, Cyrl}は「Сirсlе」（表1aの3番目の例）をカバーします。*

カバーセットが最小であるとは、それより小さいカバーセットが存在しないことを意味します。たとえば、{Hira, Hani}は「〆切」（表1aの7番目の例）をカバーしますが、最小ではありません。なぜなら{Hira}も文字列をカバーし、{Hira}は{Hira, Hani}より小さいからです。最小カバーセットは一意ではないことに注意してください。文字列は異なる最小カバーセットを持つ可能性があります。*

通常、文字列内のスクリプトを返すAPIは、最小カバーセットのいずれかを返します。*

計算効率のために、スクリプトセットのセット（SOSS）を計算できます。ここで、文字列内の各文字の拡張スクリプトセットは、SOSSのエントリの1つにマッピングされます。たとえば、{ {Latn, Hntl}, {Cyrl} }は、「Сirсlе」（表1aの3番目の例）のSOSSになります。SOSSをカバーするスクリプトセットは、入力文字列もカバーします。同様に、SOSSのすべてのエントリの交差は、入力文字列の解決済みスクリプトセットになります。*

5.2 制限レベル検出

制限レベル1〜5は、実装で使用するためにここで定義されています。これらは、セクション3、識別子文字で指定された適切な識別子プロファイルに従って、識別子の使用に制限を課します。推奨スクリプトのリストは、UAX31の表5、推奨スクリプトから取得されます。制限レベルの使用に関する詳細については、UTR36のセクション2.9、制限レベルとアラートを参照してください。*

制限レベル1〜6のそれぞれについて、識別子は、UAX31のデフォルト識別子構文のような、施行されている一般的な構文制約に従って、正しく形成されていなければなりません。*

さらに、アプリケーションは、識別子プロファイルを提供できます。たとえば、識別子のための一般セキュリティプロファイルなどです。これは、許可される文字をさらに制限します。制限レベル1〜5のそれぞれについて、文字列内の文字は識別子プロファイルにも含まれていなければなりません。そのような識別子プロファイルがない場合、レベル5と6は同一です。*

1. ASCIIのみ
   • 文字列内のすべての文字はASCII範囲内にある。
2. 単一スクリプト
   • 文字列はASCIIのみとして適格である、または
   • 文字列はセクション5.1の定義に従って単一スクリプトである。
3. 高度に制限的
   • 文字列は単一スクリプトとして適格である、または
   • 文字列は、以下のスクリプトセットのいずれかによってカバーされている（セクション5.1の定義による）：
     • ラテン文字 + ハン + ひらがな + カタカナ；または同等：Latn + Jpan
     • ラテン文字 + ハン + ボポモフォ；または同等：Latn + Hanb
     • ラテン文字 + ハン + ハングル；または同等：Latn + Kore
4. 中程度に制限的
   • 文字列は高度に制限的として適格である、または
   • 文字列は、ラテン文字と、キリル文字、ギリシャ文字を除く他のいずれかの推奨スクリプトによってカバーされている。
5. 最小限に制限的
   • 文字列をカバーするスクリプトセットに制限はない。
   • 制限は、識別子の正当性基準と識別子プロファイルのみであり、Ωmega、Teχ、HλLF-LIFE、Toys-Я-Usのような任意のスクリプトの混合を許可する。
6. 無制限
   • 文字列のスクリプトカバレッジに制限はない。
   • 制限は、識別子の正当性基準のみである。
   • このレベルは主に検出APIで使用され、文字列がレベル1〜5のいずれにも一致しないことを示す戻り値を提供する。*

ASCIIのみレベルを除き、すべてのレベルで、Script_Extensions {Common}または{Inherited}を持つ文字は、それらの文字が識別子プロファイル要件を満たす限り、識別子で許可されることに注意してください。*

これらのレベルは、セクション5.1の一部のメカニズムを再利用して検出できます。指定された入力文字列について、制限レベルは次の論理プロセスによって決定されます：

1. 文字列に識別子プロファイル外の文字が含まれている場合、無制限を返します。
2. 文字列のどの文字も0x7Fより大きくない場合、ASCIIのみを返します。
3. セクション5.1に従って文字列のSOSSを計算します。
4. SOSSが空であるか、またはSOSSのすべてのエントリの交差が空でない場合、単一スクリプトを返します。
5. SOSSからラテン文字を含むすべてのエントリを削除します。
6. 以下のセットのいずれかがSOSSをカバーする場合、高度に制限的を返します。
   • {Kore}
   • {Hanb}
   • {Jpan}
7. SOSSのすべてのエントリの交差が、キリル文字またはギリシャ文字を除くいずれかの単一推奨スクリプトを含む場合、中程度に制限的を返します。
8. それ以外の場合は、最小限に制限的を返します。*

このアルゴリズムの実際の実際の実装は最適化できます。通常どおり、仕様は結果のみに依存します。*

5.3 混合数字検出

Unicodeには3種類の数字があります。識別子では、General_Category = Decimal_Number (Nd) を持つ数字のみが許可されるべきです。しかし、異なる10進数システムの文字は簡単に紛らわしくなる可能性があります。たとえば、U+0660（ ٠ ）ARABIC-INDIC DIGIT ZEROはU+06F0（ ۰ ）EXTENDED ARABIC-INDIC DIGIT ZEROと紛らわしくなる可能性があり、U+09EA（ ৪ ）BENGALI DIGIT FOURはU+0038（ 8 ）DIGIT EIGHTと紛らわしくなる可能性があります。スクリプトの混合と同様に、識別子で混合数字システムを無効にする他の理由もあります。*

10進数以外の数字を含まない指定された入力文字列について、混合数字を検出する論理プロセスは次のとおりです：*

文字列内の各文字について：*

1. その文字の10進数値を（もしあれば）見つけます。
2. 値をその数値システムの固有のゼロ文字にマッピングします。*

このゼロ文字が複数ある場合、文字列は複数の10進数システムを含んでいます。*

このアルゴリズムの実際の実際の実装は最適化できます。通常どおり、仕様は結果のみに依存します。以下は、これをどのように行うかを示すICUを使用したJavaサンプルです：

    public UnicodeSet getNumberRepresentatives(String identifier) {        int cp;
        UnicodeSet numerics = new UnicodeSet();
        for (int i = 0; i < identifier.length(); i += Character.charCount(cp)) {
            cp = Character.codePointAt(identifier, i);
            // 各10進数桁の種類の比較のための代表文字を格納する
            switch (UCharacter.getType(cp)) {
            case UCharacterCategory.DECIMAL_DIGIT_NUMBER:
                // 比較のためにゼロ文字を代表として格納するだけ。
                // Unicodeはそれがcp - valueであることを保証する。
                numerics.add(cp - UCharacter.getNumericValue(cp));
                break;
            case UCharacterCategory.OTHER_NUMBER:
            case UCharacterCategory.LETTER_NUMBER:
                throw new IllegalArgumentException("Should not be in identifiers.");
            }
        }
         return numerics;
    }
...
    UnicodeSet numerics = getNumberRepresentatives(String identifier);
    if (numerics.size() > 1) reject(identifier, numerics);

5.4 オプション検出

なりすまし検出に役立つ可能性のある追加の機能がいくつかあります。たとえば：*

1. すべての文字がUnicode Common Locale Data Repository（CLDR）の少なくとも1つの言語の例示文字セットに含まれていることを確認する。
2. ありそうもない結合マークのシーケンスをチェックする：
   1. 同じ非スペースマーク（gc=Mnまたはgc=Me）のシーケンスを禁止する。
      （コア仕様の非スペースマークの定義を参照。）
   2. 4つ以上の非スペースマーク（gc=Mnまたはgc=Me）のシーケンスを禁止する。
   3. ベース文字+非スペースマークのシーケンスが、非スペースマークがベース文字の一部を覆っているため、ベース文字単独と同じ、または紛らわしいほど似ているように見えることを禁止する。例はU+0069 LOWERCASE LETTER I + U+0307 COMBINING DOT ABOVEです。
3. 2つの異なるシーケンスが同一の表現を持つことを検出するためのサポートを追加する。現在のデータファイルは、単一コードポイントが別のコードポイントまたはシーケンスと紛らわしいケースのみを処理します。shriのようなケースは処理しません。*

文字U+0BB6 TAMIL LETTER SHAとU+0BB8 TAMIL LETTER SAは、通常はかなり区別されます。しかし、どちらもタミル語のshriの表現に使用できます。一般的なプラットフォームでは、次のシーケンスがまったく同じ視覚的表示になります：*

U+0BB6

U+0BCD

U+0BB0

U+0BC0

SHA

VIRAMA

RA

II

ஶ

்

ர

◌ீ

= ஶ்ரீ

U+0BB8

U+0BCD

U+0BB0

U+0BC0

SA

VIRAMA

RA

II

ஸ

்

ர

◌ீ

= ஸ்ரீ

6 開発プロセス

Unicode技術レポート #36、「Unicodeセキュリティに関する考慮事項」（UTR36）で議論されているように、文字間の紛らわしさは正確な科学にはなり得ません。紛らわしさを程度の問題にする多くの要因があります：*

• 文字の形状は、それらを表現するために使用されるフォントによって大きく異なります。Unicode標準はコードチャートで代表的なグリフを使用しますが、フォントデザイナーは独自のグリフを作成する自由があります。任意のUnicodeコードポイントを表現するために任意のグリフを使用したフォントを簡単に作成できるため、任意のフォントとの文字の紛らわしさは決して回避できません。たとえば、「a」が「b」のように、「c」が「d」のように見えるフォントを作成できます。*
• 文脈形成を使用する書記体系（アラビア語や多くの南アジアのシステムなど）は、テキストレンダリングにさらに多くのバリエーションをもたらします。文字は孤立した抽象的な形状を持たず、単語、フレーズ、文を構成する文字クラスターの一部としてのみレンダリングされます。文脈によってのみ認識できる（あるいは認識できない）非常に異なる論理的な単語に対応する同じ視覚的なテキスト表現を見つけることは、かなり一般的な出来事です。*
• イタリック体のようなフォントスタイルバリアントは、他のスタイルには存在しない紛らわしさを導入する可能性があります。たとえば、キリル文字では、U+0442（ т ）CYRILLIC SMALL LETTER TEは、通常のスタイルでは小文字のラテン文字「T」のように見えますが、イタリック体では小文字のラテン文字「m」のように見えます。*

スクリプト内の紛らわしさは非常にユーザー依存です。たとえば、ラテン文字では、アクセント付きまたは付加物付きの文字は、特に特定の言語での意味に慣れていないユーザーにとって、装飾のない文字と似ているように見える場合があります。しかし、ほとんどのユーザーは、自分のスクリプトの文字の範囲について少なくとも最小限の理解を持っており、他のスクリプトを処理するための別のメカニズムがあります。これはUTR36で議論されています。*

他の場所で説明されているように、紛らわしいデータが期待どおりでない場合があります。これは、2つの文字または2つの文字列が一部のフォントでのみ紛らわしい場合があるためです。他の場合では、推移性のためです。たとえば、点のないIと点のあるIは同等と見なされます（ı ↔ i）。なぜなら、それらはアキュートのようなアクセントが適用されたときに同じように見えるからです。しかし、実用的な実装の観点からは、推移性は非常に重要であるため、いくつかの奇妙さが受け入れられています。*

データは、この仕様の将来のバージョンで強化される可能性があります。時間の経過に伴う変更の処理については、UTR36のセクション2.10.1、後方互換性を参照してください。*

6.1 紛らわしい文字データの収集

紛らわしいデータは、多数の候補となる紛らわしい文字を収集し、それらの紛らわしい文字を一般的なフォントのセットに従って検査し、結果を推移閉包のために処理することによって作成されました。*

主な目標は、表1、Identifier_Status と Identifier_TypeにあるIdentifier_Status=Allowedの文字を含めることです。NFKCバリアントのような他の文字は、データ収集の主な焦点ではありません。しかし、そのようなバリアントは確かにデータに含まれる可能性があります。*

候補となる紛らわしい文字は、多数の情報源から収集されました。Erik van der Poelは、多数のフォントに対してプログラムを実行して、フォント内で同一のグリフを共有する文字を検出することによって派生したリストを提供しました。Mark Davisも最近、WindowsおよびMacintoshのフォントに対して同様のことを行いました。Google、IBM、Microsoftなどの企業のボランティアが他の文字リストを収集しました。これらには、異なる文字体系を持つ言語のネイティブスピーカーが含まれていました。Unicode互換性マッピングも情報源として使用されました。視覚的な紛らわしい文字の収集プロセスは継続中です。Unicodeコンソーシアムは、追加のマッピングの提出を歓迎します。南アジアおよび東南アジアの複雑なスクリプトは特別な注意が必要です。焦点は、Identifier_Status=Allowedの文字にあります。なぜなら、それらが最も懸念されるからです。*

ユーザーインターフェースで使用されるフォントは重要な情報源です。なぜなら、それらは通常、IRI（国際化リソース識別子）とそのサブ要素（ドメイン名など）を使用する状況で、紛らわしさが重要な状況でユーザーに見られるからです。これらのフォントには、他にも関連する特性があります：*

• オペレーティングシステムやアプリケーションのアップデートでめったに変更されません。システムアップグレードによる変更は、ユーザビリティの中断を避けるために段階的になる傾向があります。
• ユーザーインターフェース要素は低解像度画面（EMあたりのピクセル数が少ないことを意味する）で読みやすくする必要があるため、これらのコンテキストで使用されるフォントはサンセリフスタイルで設計される傾向があり、これは紛らわしい文字の可能性を高める傾向があります。ただし、中国語のようにセリフスタイルが一般的に使用されている言語もあります。
• 厳密なバウンディングボックス要件は、比較的大きなアセンダーとディセンダーを使用するスクリプトに対してさらに制約を作成します。これにより、アクセントマークやトーンマークに割り当てられるスペースも制限され、紛らわしさの機会も増える可能性があります。*

候補となる紛らわしい文字のペアは、一般的なサイズで、フォント内およびフォント間で常に視覚的に区別できる場合、削除されました。データはその後、推移性に関して閉じられました。つまり、X≅YかつY≅Zならば、X≅Zとなります。さらに、データは部分文字列操作に関して閉じられました。つまり、X≅YならばAXB≅AYBとなります。その後、スクリプト内およびスクリプト間のデータが生成されるように処理されました。これにより、単一のデータテーブルを使用して、入力文字列を結果のスケルトンにマッピングできます。*

スケルトンは、文字列の紛らわしさをテストするための内部使用のみを目的としています。結果のテキストは、さまざまなスクリプトの寄せ集めのように見えるため、ユーザーに表示するのには適していません。特に、識別子のマッピングの結果が必ずしも識別子になるとは限りません。したがって、紛らわしいマッピングは、2つの識別子が紛らわしいかどうかをテストするために使用できます（スケルトンが同じ場合）。しかし、識別子の「正規化」として使用すべきではありません。*

6.2 識別子変更データ収集

idmodデータは次のように収集されます。基本的な割り当ては、UCD文字プロパティ、UAX31の情報、およびUnicode標準のコア仕様、コードチャートのアノテーション、CLDR例示文字に関する情報、外部フィードバックを含むさまざまな情報源からのキュレーションされた例外リストに基づいて導出されます。*

表1. Identifier_Status と Identifier_Typeの項目を上から順に照合したときに最初に一致する条件が使用されますが、いくつかの例外があります：*

1. 文字がUAX31の表3a、中間文字のオプションまたは表3b、継続文字のオプションにある場合、他のプロパティに関係なく、Identifier_Type=Inclusionが割り当てられます。*
2. 文字のScript_Extensionsプロパティ値に複数のScriptプロパティ値が含まれる場合、派生に使用されるScriptは次のリストの最初のものです：
   1. 表5、推奨スクリプト
   2. 表7、限定使用スクリプト
   3. 表4、除外スクリプト

表4、表5、および表7のスクリプト情報は、CLDRのscriptMetadata.txtに機械可読形式で含まれています。*

7 データファイル

以下のファイルは、この文書の推奨事項を実装するために使用されるデータを提供します。データは、この仕様の将来のバージョンで洗練される可能性があります。詳細については、UTR36のセクション2.10.1、後方互換性を参照してください。例示のために、このUTSはサンプルデータ値を示していますが、Unicodeの現在のバージョンに関する実際のデータについては、常にデータファイルを参照してください。*

Unicodeコンソーシアムは、追加の紛らわしい文字や識別子制限に関するフィードバックを歓迎します。

このバージョンのデータファイルは、https://www.unicode.org/Public/18.0.0/security/にあります。*

Unicode 17.0より前は、データファイルはhttps://www.unicode.org/Public/security/の下のバージョン管理されたディレクトリに投稿されていました。*

最新の承認済みバージョンのデータファイルもディレクトリにあります：

https://www.unicode.org/Public/security/latest

IdentifierStatus.txtの形式は、UCDデータファイルの通常の規則に従っており、そのファイルのヘッダーで説明されています。ファイルにリストされていないすべての文字は、デフォルトでIdentifier_Status=Restrictedとなります。したがって、ファイルにはIdentifier_Status=Allowedの文字のみがリストされます。たとえば：

002D..002E ; Allowed # 1.1 HYPHEN-MINUS..FULL STOP

IdentifierType.txtの形式は、UCDデータファイルの通常の規則に従っており、そのファイルのヘッダーで説明されています。値はスペースで区切られた要素のセットです。この形式はScriptExtensions.txtで使用される形式と同じです。これは、以前のバージョンとは異なり、除外の最も強い理由のみをリストしていました。この新しい規則により、値はより微妙なフィルタリングに使用できます。たとえば、実装がExclusionスクリプトを許可したい場合、そのスクリプト内のObsoleteおよびNot_XID文字を除外することができます。ファイルにリストされていないすべての文字は、デフォルトでIdentifier_Type=Not_Characterとなります。たとえば：

2460..24EA ; Technical Not_XID Not_NFKC # 1.1 CIRCLED DIGIT ONE..CIRCLED DIGIT ZERO

これらの両方のファイルには、多くのUCDファイルと同様に、デフォルトのプロパティ値の機械可読な# @missing行があります。この構文の詳細については、UAX44のセクション4.2.10、@missing規則を参照してください。*

表2. データファイルリスト

移行

バージョン6.3.0以降、この文書のバージョン番号は、データが基づいているUCDのバージョンを示すように変更されました。バージョン6.3.0以前およびそれ以降の場合、次の表はこの文書のバージョンとそれらが基づいていたUCDバージョンの対応を示しています。*

表3. バージョン対応

関連するUCDバージョン間のこの標準の更新バージョンが必要な場合、バージョン番号には3番目のフィールドに更新番号が含まれます。たとえば、この文書のバージョンとその関連データがUCD 6.3.0とUCD 7.0.0の間で必要な場合、バージョン6.3.1を使用できます。*

永続データの移行

実装は、この仕様の新しいバージョンからデータファイルを使用するように実装を更新するたびに、永続データストア（データベースインデックスなど）を移行する必要があります。*

安定性はバージョン間で保証されることはありませんが、可能な限り維持されます。特に、紛らわしいマッピングデータの更新バージョンでは、特定の文字のマッピングが以前のバージョンで使用されていたマッピングと異なる場合があります。したがって、バージョンNではX→Y、バージョンN+1ではX→Zとなる場合があります。ZはバージョンNでYにマッピングされていた場合も、されていなかった場合もあります。論理データがバージョン間で変更されていない場合でも、データファイル内の行の順序が変更されている可能性があります。*

Identifier_Statusには安定性の保証はありません（「一度文字がAllowedになると、将来のバージョンでRestrictedになることはない」など）。なぜなら、文字の使用に関する知識が増えるにつれてデータは変化しているからです。Identifier_Type値の一部（Not_XIDなど）は後方互換性がありますが、ほとんどは新しいデータが入手可能になると変更される可能性があります。識別子データは、スクリプトと一般カテゴリの観点から見ても、完全に一貫しているようには見えない場合があります。たとえば、スクリプト内の非スペースマークのセットのうち1つがRestrictedであり、他のものがそうでない可能性があります。しかし、それはその文字が廃止されており、他のものがそうでないという事実の単なる反映である可能性があります。*

識別子ルックアップの場合、データは疑わしい可能性のある文字をフラグ付けすることに重点を置いており、したがって、ユーザーに何らかの方法で通知するかどうかを決定する際の1つの要因（「セーフブラウジング」サービスの使用など、おそらく多くの要因のうちの1つ）として機能します。登録の場合、フラグ付けされた文字は「ソフト却下」につながる可能性があります。つまり、ユーザーは追加情報で却下に対して異議を申し立てる必要があります。*

ステータスがRestrictedに変更された文字を処理するために、実装は後方互換性を維持するためにIdentifier_Type値を以前のAllowed値にオーバーライドできます。*

したがって、実装は、紛らわしいマッピングデータまたはその他のデータファイルを使用する永続データストア（データベースインデックスなど）を移行するための戦略を持つべきです。*

バージョン13.0移行

Unicode 13.0以降、Identifier_StatusとIdentifier_Typeは一貫してアンダースコアで記述されています。これは、プロパティ名の照合に関するUnicode規則に従わないパーサーの誤動作を引き起こす可能性があります。*

バージョン10.0移行

Unicode 10.0以降、Identifier_Type=Aspirationalは空になりました。詳細については、UAX31を参照してください。*

バージョン9.0移行

バージョン8.0と9.0の間には重要なデータ形式の変更があります。特に、バージョン8.0のxidmodifications.txtファイルは、バージョン9.0では2つのファイルに分割されました：IdentifierStatus.txtとIdentifierType.txt。*

IdentifierType.txtのフィールド1には複数の値がリストされています。古いxidmodifications.txt形式に変換するには、フィールドの最後の値を使用します。たとえば、次の値が対応します：*

バージョン8.0移行

バージョン8.0では、Identifier_StatusとIdentifier_Typeに以下の変更が加えられました：*

• 標準UCDフォーマットに変更されました。たとえば、limited-use → Limited_Use。
  • 通常は単に大文字とハイフンを変更しましたが、not-charsはNot_Characterに変更されました。
• Identifier_TypeをUAX 31およびUnicodeプロパティにより良く整合させました。
  • historic
    • → Exclusion（表4、識別子からの除外候補文字から）
    • → Obsolete（それ以外の場合）
  • limited-use
    • → Limited_Use（表7、限定使用スクリプトから）
    • → Aspirational（表6、希望使用スクリプトから）（バージョン10.0でLimited_Useに統合）
    • → Uncommon_Use（それ以外の場合）
  • obsolete
    • → Deprecated（Unicodeプロパティと一致する場合）*

バージョン7.0移行

製造上の問題により、7.0より前の紛らわしいマッピングテーブルのバージョンでは、すべてのケースで冪等性が維持されていなかったため、バージョン8.0への更新を強く推奨します。*

スケルトンマッピングを使用するユーザーは、データベースインデックスなどのスケルトンの永続的な使用をすべて再構築する必要があります。*

7.0のSL、SA、MLマッピングは、冪等性の問題を解決するために大幅に変更されました。しかし、SL、SA、MLテーブルは依然として問題があり、7.0での使用は推奨されませんでした。したがって、それらはバージョン8.0から削除されました。*

削除されたテーブルを実装が再作成するために必要なすべてのデータは、残りのデータ（MA）とUnicode文字データベースプロパティ（スクリプト、大文字小文字など）で利用可能です。そのような再作成では、MAデータの各同値クラスを検査し、制約（スクリプトまたは大文字小文字）に適合しないインスタンスをフィルタリングします。ターゲット文字については、最も中立的な文字、通常はシンボルを選択します。しかし、それらを廃止した理由は依然として有効であるため、実装がそれらを再作成することは推奨されません。*

また、Script_Extensionsデータがより完全になるにつれて、全体スクリプトの紛らわしい文字ファイル内の文字が一致しなくなる可能性があることに注意してください。詳細については、セクション4、紛らわしい文字の検出を参照してください。*

謝辞

Mark DavisとMichel Suignardが、Unicode技術委員会の指示の下、大部分のテキストを執筆し、バージョン18.0.0まで仕様のエディターを務めました。ICUチームのSteven Loomisやその他の人々は、この技術レポートの元の提案の開発に非常に役立ちました。Shane Carrはアルゴリズムを分析し、バージョン10.0でのセクション4と5の書き直しのためのソーステキストを提供しました。*

バージョン15.0および15.1で大幅な変更が行われたソースコードワーキンググループ会議の参加者が支援しました：Peter Constable、Elnar Dakeshov、Mark Davis、Barry Dorrans、Steve Dower、Michael Fanning、Asmus Freytag、Dante Gagne、Rich Gillam、Manish Goregaokar、Tom Honermann、Jan Lahoda、Nathan Lawrence、Robin Leroy、Chris Ries、Markus Scherer、Richard Smith。*

この文書またはその以前のバージョン、あるいは紛らわしい文字やidmodのソースデータへのフィードバックや貢献をしてくれた以下の人々にも感謝します：Julie Allen、Andrew Arnold、Shane Carr、Vernon Cole、David Corbett（多くの貢献に特別な感謝）、Douglas Davidson、Rob Dawson、Alex Dejarnatt、Om Doiphode、Chris Fynn、Martin Dürst、Asmus Freytag、Deborah Goldsmith、Manish Goregaokar、Josh Hadley、Paul Hoffman、Ned Holbrook、Denis Jacquerye、Cibu Johny、Patrick L. Jones、Peter Karlsson、Robin Leroy、Mike Kaplinskiy、Gervase Markham、Eric Muller、David Patterson、Erik van der Poel、Roozbeh Pournader、Michael van Riper、Marcos Sanz、Alexander Savenkov、Markus Scherer、Dominikus Scherkl、Manuel Strehl、Chris Weber、Ken Whistler、およびWaïl Yahyaoui。フォントの紛らわしい文字に関する支援をしてくれたPeter Pengに感謝します。*

参考文献

[CLDR]

Unicodeロケールプロジェクト（Unicode Common Locale Data Repository）
https://cldr.unicode.org/

[DCore]

派生コアプロパティ
https://www.unicode.org/Public/UCD/latest/ucd/DerivedCoreProperties.txt

[DemoConf]

https://util.unicode.org/UnicodeJsps/confusables.jsp

[DemoIDN]

https://util.unicode.org/UnicodeJsps/idna.jsp

[DemoIDNChars]

https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5C%p{age%3D3.2}-\p{cn}-\p{cs}-\p{co}&abb=on&g=uts46+idna+idna2008

[EAI]

https://www.rfc-editor.org/info/rfc6531

[FAQSec]

Unicode FAQ on Security Issues
https://www.unicode.org/faq/security.html

[Feedback]

紛らわしい文字または識別子制限データへの追加または変更を提案する場合、またはテキストの問題については、以下を参照してください：
Report Error in Publication/Datahttps://www.unicode.org/reporting.html

[ICANN]

ICANN文書：
Internationalized Domain Names
https://www.icann.org/en/topics/idn/
The IDN Variant Issues Project
https://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-en.pdf
Root Zone Label Generation Rules project page
https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en
Maximal Starting Repertoire project page
https://www.icann.org/resources/pages/msr-2015-06-21-en
Maximal Starting Repertoire Version 5 (MSR-5)
https://www.icann.org/en/system/files/files/msr-5-overview-24jun21-en.pdf

[ICU]

International Components for Unicode
https://icu.unicode.org/

[IDNA2003]

IDNA2003仕様は、IETF RFCのクラスターによって定義されています：

• IDNA（RFC3490）
• Nameprep（RFC3491）
• Punycode（RFC3492）
• Stringprep（RFC3454）。

[IDNA2008]

IDNA2008仕様は、IETF RFCのクラスターによって定義されています：

• Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
  https://www.rfc-editor.org/info/rfc5890
• Internationalized Domain Names in Applications (IDNA) Protocol
  https://www.rfc-editor.org/info/rfc5891
• The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
  https://www.rfc-editor.org/info/rfc5892
• Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
  https://www.rfc-editor.org/info/rfc5893

また、情報提供文書もあります：

• Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale
  https://www.rfc-editor.org/info/rfc5894
• The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0
  https://www.rfc-editor.org/info/rfc6452

[IDN-FAQ]

https://www.unicode.org/faq/idn.html

[Reports]

Unicode技術レポート
https://www.unicode.org/reports/
技術レポートのステータスと開発プロセス、および技術レポートのリストについては。

[RFC3454]

P. Hoffman, M. Blanchet. "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
https://www.rfc-editor.org/info/rfc3454

[RFC3490]

Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
https://www.rfc-editor.org/info/rfc3490

[RFC3491]

Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
https://www.rfc-editor.org/info/rfc3491

[RFC3492]

Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
https://www.rfc-editor.org/info/rfc3492

[RZLGR5]

Integration Panel, “Integration Panel: Root Zone Label Generation Rules — LGR-5”, 22 May 2022
https://www.icann.org/sites/default/files/lgr/rz-lgr-5-overview-26may22-en.pdf

[Security-FAQ]

https://www.unicode.org/faq/security.html

[UCD]

Unicode Character Database.
https://www.unicode.org/ucd/
Unicode Character Databaseの概要と関連ファイルリストについては。

[UCDFormat]

UCDファイル形式
https://www.unicode.org/reports/tr44/#Format_Conventions

[UAX9]

UAX #9: Unicode Bidirectional Algorithm
https://www.unicode.org/reports/tr9/

[UAX15]

UAX #15: Unicode Normalization Forms
https://www.unicode.org/reports/tr15/

[UAX24]

UAX #24: Unicode Script Property
https://www.unicode.org/reports/tr24/

[UAX29]

UAX #29: Unicode Text Segmentation
https://www.unicode.org/reports/tr29/

[UAX31]

UAX #31: Unicode Identifiers and Syntax
https://www.unicode.org/reports/tr31/

[UAX44]

UAX #44: Unicode Character Database
https://www.unicode.org/reports/tr44/

[Unicode]

The Unicode Standard*
最新バージョンについては、以下を参照してください：
*https://www.unicode.org/versions/latest/

[UTR23]

UTR #23: The Unicode Character Property Model
https://www.unicode.org/reports/tr23/

[UTR36]

UTR #36: Unicode Security Considerations
https://www.unicode.org/reports/tr36/

[UTS18]

UTS #18: Unicode Regular Expressions
https://www.unicode.org/reports/tr18/

[UTS39]

UTS #39: Unicode Security Mechanisms
https://www.unicode.org/reports/tr39/

[UTS46]

Unicode IDNA Compatibility Processing
https://www.unicode.org/reports/tr46/

[UTS55]

Unicode Source Code Handling
https://www.unicode.org/reports/tr55/

[Versions]

Unicode標準のバージョン
https://www.unicode.org/standard/versions/
バージョン番号付け、およびUnicode標準、Unicode文字データベース、Unicode技術レポートの引用と参照に関する情報については。

改訂

以下は、この文書の以前の公開バージョンからの変更点の概要です。*

改訂 34

• Unicode 18.0.0のために再発行されました。
• ISO 15924スクリプトコードHntlのサポートが追加されました。
• 記録上のエディターがMark DavisとMichel SuignardからJosh HadleyとRoozbeh Pournaderに変更されました。
• セクション3.1.1.1、結合制御文字の限定されたコンテキストで、A1のコンテキストルールを、ZWNJの後に透明文字を許可しないように変更しました。また、CONTEXTJとの違いを説明することで、最後の注を拡張しました。（188-A55および188-A57）
• セクション4、紛らわしい文字の検出で、ゲートキーパー紛らわしい文字列に関する段落を削除し、UTR #36への参照を削除しました。（185-A103）
• セクション4、紛らわしい文字の検出で、セキュリティリスクを軽減するために大文字小文字を区別しない形式を使用することに関する段落を削除しました。（187-A142）
• セクション5.4、オプション検出で、「非スペースマーク」にはgc=Mnとgc=Meの両方が含まれることを明確にしました。これはコア仕様と同様です。（187-A143）

以前のバージョンからの変更点は、それぞれのバージョンにリストされています。*

---

© 2006–2026 Unicode, Inc. この出版物は著作権で保護されており、利用規約で許可されていないいかなる複製、改変、その他の使用の前にもUnicode, Inc.からの許可を得る必要があります。特に、この出版物のコピーを作成したり、個人的または内部的なビジネス目的のみで、公共の配布を許可しないように注釈を付けたり翻訳したりできます。ただし、許可されたそのようなコピーおよび改変は、元の出版物に含まれるすべての著作権およびその他の法的通知を完全に再現するものとします。Unicodeの明示的な書面による許可なしに、この出版物のコピーまたは改変を公共の配布目的で行ったり、製品または出版物に全体または一部を組み込んだりすることはできません。*

この出版物を含むすべてのUnicode製品の使用は、Unicode 利用規約によって管理されます。著者、貢献者、および出版社は、この出版物の作成に注意を払っていますが、明示的または黙示的な表明または保証を行わず、エラーまたは脱落、またはそれに起因する結果的または偶発的な損害に対して責任または義務を負いません。この出版物は、ユーザーの便宜のために、無償で「現状有姿」で提供されます。*

UnicodeおよびUnicodeロゴは、米国およびその他の国におけるUnicode, Inc.の登録商標です。*