ユニコード技術規格 #39 Ver18.0.0: アイデンティファイヤーおよびセキュリティプロファイル

編集者: Josh Hadley, Roozbeh Pournader
日付: 2026-08-27

リンク

• このバージョン: https://www.unicode.org/reports/tr39/tr39-34.html
• 前バージョン: https://www.unicode.org/reports/tr39/tr39-32.html
• 最新バージョン: https://www.unicode.org/reports/tr39/
• 最新の提案されたアップデート: https://www.unicode.org/reports/tr39/proposed.html

ステータスと概要

文書の地位

• 承認状態: ユニコードメンバーおよび関係者による審査済み。ユニコードコンソーシアムから出版の承認を得ている。
• 安定性: 安定した文書であり、他の仕様の規範的な参照として使用または引用が可能。
• 独立仕様: ユニコード標準への適合は、特定の UTS（ユニコード技術仕様）への適合を意味しない。
• フィードバック: 訂正や意見はオンライン報告フォーム ([フィードバック]) に提出可能。

背景と目的

• セキュリティリスク: ユニコードの多様な書記体系の存在により、誤った使用法がシステムをセキュリティ攻撃にさらす可能性が生じる。
• 参照規格: UTR36「ユニコードセキュリティ考慮事項」 のガイドラインに基づき、具体的なメカニズムを規定。
• ID と構文: ユニコード標準アネックス #31（UAX31）の推奨方法を基に ID 定義を拡張。

2. 適合性（コンフォーマンス）

実装が「適合した」と主張する場合は、以下の条項に従う必要がある。

アイデンティファイヤー用一般プロファイル (UTS-39-C1)

• C1-1: 第 3.1 節の仕様を完全に従う。
• C1-2: プロファイルの変更（追加/削除文字）に伴う正確なリストを提供する（それ以外は C1-1 を準拠）。

アイデンティファイヤー用 IDN セキュリティプロファイル (UTS-39-C1.1)

• C1.1-1: 第 3.2 節の仕様を完全に従う。
• C1.1-2: プロファイルの変更（追加/削除文字）に伴う正確なリストを提供する。

アイデンティファイヤー用メールセキュリティプロファイル (UTS-39-C1.2)

• C1.2-1: 第 3.3 節の仕様を完全に従う。
• C1.2-2: プロファイルの変更（追加/削除文字）に伴う正確なリストを提供する。

その他機能適合性

• 混同検出 (UTS-39-C2): 第 4 節機能またはマッピング変更のリスト提供。
• スクリプト混合検出 (UTS-39-C3): 第 5.1 節機能または振る舞い変化の説明提供。
• レベルごとの制限検出 (UTS-39-C4): 第 5.2 節機能または振る舞い変化の説明提供。
• 数値体系の混合検出 (UTS-39-C5): 第 5.3 節機能または振る舞い変化の説明提供。

3. アイデンティファイヤー文字（ID Characters）

定義とセキュリティ要件

• ID (Identifier): 特定の実体（例：URL、ドメイン名）を一意に参照する文字列。1 つの ID は最大 1 つの実体のみをマッピング。
• セキュリティ課題: 機械は異なる文字列を容易に区別できるが、人間にとって区別が困難な文字列の潜在的な曖昧性は重大なリスク。
• 制限原則: ID に使用可能な文字を意図的に制限することが重要。一般的なテキストでのこれらの文字の使用には影響しない。

プロファイル構成要素

データファイル（UCD 形式）に基づく以下の特性を使用：

• XID_Start / XID_Continue: デフォルトのユニコード ID 資格。
• toCasefold(X): 小文字化操作。
• NFKC / NFKD: ノーマライゼーション。

制限される文字（Identifier_Status = Restricted）

特定の環境で視覚的な混同を避けるため、以下のような文字の使用が制限または禁止されます。

• 現代の使用に存在しない文字 (

  Obsolete

  )
• 専門分野のみで使用される文字: 儀礼的字符、音声記号、数学記号など (

  Technical

  )
• 極めて小規模なコミュニティでのみ使用される文字 (

  Uncommon_Use

  ,

  Limited_Use

  )
• 除外スクリプトの文字 ([UAX31] 表 4)

許可された文字（Identifier_Status = Allowed）

• 推奨スクリプト: [UAX31] 表 5 に記載の「Common」または「Inherited」を持つスクリプト。
• 例外:

  Restricted

  に指定された特定の文字を除く、[IDNA2008] やメディア用オプション文字など。

処理ロジック

実装は通常、セット $C$（ID 構文でサポート）に対してフィルタを適用し、新しいセット $C'$ を生成します：

$$ C' = (C \cap {Identifier_Status=Allowed}) \cup Exception $$

• 例外（Exception）: 実装が定義する文字（例：

  $

  ,

  -

  ,

  .

  など）。
• 警告:

  Restricted

  文字の使用は、十分な理由がない限り禁止すべき。

  Allowed

  セットも必ずしもそのまま使用するわけではない。

Identifier_Type 値の選択と特性

以下の分類を組み合わせることができます（複数可能）：

·

注記: ユニコード 15.0 で、ZWJ/ZWNJ は

Identifier_Type=Inclusion

から除外され、代わりに

Default_Ignorable

および

Restricted

として扱われます。プログラミング ID プロファイルへの含めることは使いやすさとセキュリティに影響します。

ZWJ と ZWNJ の維持

• 一般 ID プロファイルで維持したい場合は、第 2 節に規定されたプロファイル変更の使用を宣言する必要があります。
• 制限: A1, A2, B（後述）の条件を満たす限りのみ許可。

3.1.1 ジョイニングコントロール（結合制御字）

必要性と制限の目的

• 背景: 「現代的な慣用的使用」（新聞、出版物、標識など）では、ZWJ/ZWNJ を含む ID は必要だが、視覚的な区別を生じないケースでの排除はセキュリティリスクとなる。
• 目標:
  • 通常のテキストでの使用を許可する。
  • 視覚的な混同が生じないケースのみを許可する。
  • 標準的なメカニズム（正規表現）で実装可能にすること。

A1. ZWNJ の許可条件（カリグラフィ接続の断絶）

文脈:

Left-Joining

Dual-Joining

Right-Joining

Dual-Joining

• 正規表現例:

  /$LJ $T* ZWNJ $RJ/

• グローバル条件:
  • スクリプト制限: 単一のスクリプトからのみ（Common/Inherited を無視）。
  • 正規化: NFC 形式であること。
• 具体例: ペルシャ語で「名前」から「文字」へ意味を変えたい場合（Heh と Alef の間に置く）に有効。

A2. ZWNJ の許可条件（接合文脈内）

文脈:

Letter

Virama

Letter

• 正規表現例:

  /$L $M* $V $M₁* ZWNJ $M₁* $L/

  • $L

    : Letter

  • $V

    : Virama

  • $M

    : Mn (非間隔記号)

  • $M1

    : CCC≠0 の非間隔記号
• 具体例: マライヤム語の「目撃者」単語で誤りを防ぐ。

B. ZWJ の許可条件（接合文脈内）

文脈:

Letter

Virama

• 正規表現例:

  /$L $M* $V $M₁* ZWJ (?!$D)/

  • $D

    : Indic_Syllabic_Category=Vowel_Dependent
• 具体例: スィンハラ語で「スリランカ国」のレンダリングを維持する。

注記: A1/A2/B の制限は IDNA2008 の CONTEXTJ ルールよりも厳格です。これらを満たすなら、IDN における結合制御字へのルールも満たしていることになります。

3.2 IDN セキュリティプロファイル用アイデンティファイヤー

• 沿革: Ver1 は [IDNA2003] に適用。現在は [IDNA2008] および [UTS46] が主流。
• ラベル生成規則 (LGR): RFC7940 規定の機械可読形式。
  • スクリプトや言語ごとに定義可能（例：アラビア語、中国語）。
  • メカニズム:
    • 文字選択（IDNA2008 許可値との交点）。
    • 重音記号の文脈制限。
    • コンテキストルールの提供（正規表現による禁止/必須）。
    • 「ブロック」バリアントの定義（一方のみ許可）。
    • 全体ラベル評価 (WLE) ルールによる検証。

3.3 メールセキュリティプロファイル用アイデンティファイヤー

SMTP EAI ([EAI]) は仕様を持つが、セキュリティ検出用のプロファイルはないため、本規格で補完する。

適用目的

• 登録時: プロファイル適合性をチェックし、非適合の場合は禁止または不服申立プロセスを許可。
• リンク化時: プロファイル適合していない場合はリンク化しない。
• 表示時: 非適合の場合は波線付きアンダーラインで警告。

ドメイン部分

• [UTS46] および IDN セキュリティプロファイル（第 3.2 節）に従うこと。

ローカル部分

以下のすべての条件を満たす必要がある：

1. NFC 形式。
2. 制限レベル: <制限レベル> またはそれ以下（第 5.2 節参照）。
3. 数値体系: 混合なし（Mixed_Number_Detection を通る）。
4. atext 拡張要件 (RFC 5322 §3.2.3):

   • C ≤ U+007F

     : RFC 5322 の定義に従う。

   • C > U+007F

     :

     • Identifier_Status=Allowed

       を持つこと。
     • 最初の文字の場合、

       XID_Start

       でなければならない。

引用文字列部分

• NFC であること。
• 双方向制御文字: LRM, RLM, ALM を除く（他の

  [:bidicontrol:]

  は許可）。
• 連続する非間隔記号: 4 つ以下、かつ同一シーケンスは禁止。
• スクリプト: 混合やイモジを含むことも可能。

その他の対策

• 双方向アイソレイターを使用し、各部分の混在を防ぐ。
• Safe Browsing など他のチェックも推奨。

実践的な問題: クライアントはサーバー側のアイデンティティ規則（大文字小文字感度等）を知ることができないため、ホワイトリストなどで対策が必要。

4. 混同検出

データファイル形式

• 形式:

  ソース ; ターゲット ; MA

  • 例：

    0441 ; 0063 ; MA

    (с → c)
• 推移性:

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

  は成り立たない可能性がある（Ver 7.0 以前）。
• 計算プロセス (

  bidiSkeleton(d, X)

  ):
  1. NFD 変換。

  2. Default_Ignorable_Code_Point

     の削除。
  3. プロトタイプ連結。
  4. NFD 再適用。
  5. 双方向アルゴリズム（再順序付け、ミラーリング）。

混同物の分類

• 単一スクリプト: 解決済みスクリプトセットが共通する要素を持つ。
• スクリプト混合: 解決済みスクリプトセットに共通要素を持たない。
• スクリプト全体: スクリプト混合かつ、各文字列が単一スクリプト（または解像後の単一性）。

5. 検出メカニズム

5.1 スクリプト混合検出

[UAX24] と UCD データに基づき、以下の拡張ルールを適用：

• Hani/Hira/Kana: {Latn, Hntl} など、追加スクリプトを含める。
• Zyyy/Zinh:

  ALL

  (すべてのスクリプト値) として扱う。

判定基準:

• 単一スクリプト: 解決済みスクリプトセットが非空かつ一意（共通集合）。
• スクリプト混合: 解決済みスクリプトセットが空の場合。

5.2 レベルごとの制限検出

ID の適正形成基準と ID プロファイルに基づき、以下を判定：

• ASCII-Only: すべての文字が ASCII レンジ。
• Single Script: ASCII または単一スクリプト（拡張ルール適用後）。
• Highly Restrictive:

  Latn + Han + Hiragana/Katakana

  などの特定組み合わせのみ。
• Moderately Restrictive: ラテンおよび推奨スクリプトのみ（西里ル語、ギリシャ語除く）。
• Minimally Restrictive: スクリプトに制限なし（ただし ID プロファイル準拠）。
• Unrestricted: 検出 API の戻り値用。

5.3 数値体系の混合検出

• 基準:

  General_Category = Decimal_Number (Nd)

  のみ許可。
• リスク: 異なる数字システム（アラビア＝インディカ、ベンガリ等）の混同防止。
• 判定: 各文字の数値値と、その数値システム固有の「ゼロ」をマッピングして不一致を検出。

7. データファイル

UCD ファイル形式

• セミコロン区切りのフィールド。
• 番号参照によるアクセス。
• 表 2: データファイル一覧（[UTS46] など参照）。

移行と安定性

• 永続データ: バージョン間でのデータ変更管理について「永続データの移行」セクションを参照。
• Ver8.0/Ver7.0: 過去のバージョンへの移行ルールを参照。