Unicode Technical Standard #46 16 から 17 読みたいところ適当訳
UNICODE IDNA 互換処理
UNICODE IDNA COMPATIBILITY PROCESSING
table:Version
Version 16.0.0
編集者 Mark Davis (mark@unicode.org), Markus Scherer (markus.icu@gmail.com)
日付 2025-09-04
改訂 35
概要 Summary
ブラウザやメールソフトなどのクライアントソフトウェアは、2003年に承認された国際化ドメイン名のバージョン（IDNA2003）から2010年に承認された改訂版（IDNA2008）への移行において困難な状況に直面しました。本仕様書は、クライアントソフトウェアがどちらのシステムでも有効なドメインにアクセスできるように、この移行の影響を最小限に抑えるメカニズムを提供しています。
本仕様書は、主に2つの機能を提供します。1つは、ドメイン名の大文字と小文字の区別やその他のバリエーションに関する現在のユーザーの期待に応える包括的なマッピングです。このようなマッピングはIDNA2008で可能になりました。2つ目は、IDNA2003で許可されていた既存のドメイン名をサポートする互換性メカニズムです。この2つ目の機能は、移行期間中のクライアントの動作を改善することを目的としていました。
状態 Status
この文書は、Unicodeメンバーおよびその他の関係者によるレビューを経て、Unicodeコンソーシアムによって公開が承認されました。この文書は安定したものであり、参考資料として使用したり、他の仕様書で規範的な参照として引用したりすることができます。
Unicode技術標準（UTS） は独立した仕様です。Unicode標準への準拠は、UTSへの準拠を意味するものではありません。
(訳注:原文の)訂正やその他のご意見は、オンライン報告フォームフィードバックからご提出ください。この文書を理解する上で役立つ関連情報は、参考文献に記載されています。Unicode標準の最新版については、Unicodeをご覧ください。最新のUnicode技術レポートの一覧については、レポートをご覧ください。Unicode標準のバージョンに関する詳細は、バージョンをご覧ください。 目次
1 はじめに
1.1 IDNA2003
1.2 IDNA2008
1.3 移行に関する考慮事項
1.3.1 マッピング
1.3.2 逸脱
表1. 逸脱文字
2 Unicode IDNA互換処理
2.1 国際化ドメイン名の表示
2.2 レジストリ
2.3 表記法
3 準拠
3.1 STD3規則
4 処理
4.1 有効性基準
4.1.1 UseSTD3ASCIIRules
4.1.2 右から左に書くスクリプト
4.2 ToASCII
4.3 ToUnicode
4.4 IDNA2008の前処理
4.5 実装上の注意
表2. 処理例
5 IDNAマッピング表
表2b.データファイルフィールド
6 マッピングテーブルの導出
ステップ1：ベースマッピングの定義
ステップ2：ベース有効セットの指定
表3. ベース有効セット
ステップ3：ベース除外セットの指定
ステップ4：逸脱セットの指定
ステップ5：後方互換性のための変更の指定
ステップ6：初期ステータス値とマッピング値の生成
ステップ7：最終ステータス値とマッピング値の生成
7 IDNAの比較
8 適合性テスト
8.1 フォーマット
8.2 適合性テスト
8.3 移行
9 IDNA導出プロパティ
謝辞
参考文献
変更点
1 はじめに Introduction
ドメイン名の大きな強みの一つは、普遍性です。URL https://Apple.com は、世界中のどこからでも、どのブラウザを使ってもAppleのウェブサイトにアクセスできます。メールアドレス mark@unicode.org は、世界中のどこからでも、どのメーラーを使っても、この仕様の編集者にメールを送信できます。 当初、ドメイン名はASCII文字に制限されていました。これは、他の文字を使用する人にとって大きな負担でした。例えば、ドメイン名システムがギリシャ人によって発明され、URLにギリシャ文字しか使えなかったとしましょう。apple.comではなく、αππλε.κομのように書かなければなりません。英語を話す人は、ギリシャ文字に精通しているだけでなく、目的の英語の文字に対応するギリシャ文字を選ぶ必要もあります。文字体系が完全に一致するわけではないため、特定の単語のスペルを推測する必要がありました。
世界の人口の大部分は、最近まで、彼らの言語が非ASCII文字を使用しているため、このような状況に直面していました。 2003年に国際化ドメイン名（IDN）のためのシステムが導入されました。このシステムは、アプリケーション向け国際化ドメイン名（Internationalizing Domain Names for Applications、略してIDNA2003）と呼ばれています。このメカニズムは、クライアントソフトウェアをPunycodeと呼ばれる形式に変換することでIDNをサポートします。IDNAの改訂版（IDNA2008）は2010年に承認されました。この改訂版には、IDNA2003との非互換性がいくつか存在します。
これらの非互換性により、ブラウザやメールソフトなどのクライアントソフトウェアの実装者は、レジストリがIDNA2003からIDNA2008に移行する移行期間中に難しい選択を迫られました。この文書では、クライアントソフトウェアへのこの移行の影響を最小限に抑え、クライアントソフトウェアがどちらのシステムでも有効なドメインにアクセスできるようにするメカニズムを規定します。
この仕様は主に2つの機能を提供します。1つ目は、ドメイン名の大文字と小文字の区別やその他のバリエーションに関する現在のユーザーの期待に応えるための包括的なマッピングです。このようなマッピングはIDNA2008によって可能になります。 2つ目の機能は、IDNA2003で許可されていた既存のドメイン名をサポートする互換性メカニズムです。この2つ目の機能は、移行期間中のクライアントの動作を改善することを目的としていました。移行は完了しており、移行処理は非推奨となっていますが、本仕様で定義されているマッピングと処理、そして最新バージョンのUnicodeに基づく検証は依然として価値があり、広く使用されています。
本仕様には、規範的要素と参考的要素の両方が含まれています。適合性に関する条項と、それらが直接的または間接的に参照するテキストのみが規範的要素とみなされます。
1.1 IDNA2003
IDNA2003 IDNA2003 として総称される一連のRFCは、ドメイン名に非ASCII Unicode文字を含めることを許可しています。これには、英語以外のラテン文字言語（Å、Ħ、Þなど）に必要な文字だけでなく、ギリシャ文字、キリル文字、タミル文字、韓国語などの文字も含まれます。Bücher.de のような国際化ドメイン名は、http://Bücher.de#titel のような IRI と呼ばれる「国際化」URL で使用できます。 ドメイン名に非ASCII Unicode文字を含めるための IDNA のメカニズムは、ドメイン名内の Unicode 文字を含む各ラベルに対して、以下の手順を適用することで実現されます。
1. Unicode 文字列を変換（マッピング）し、大文字と小文字などの差異を除去します。
2. 特定の規則に従って、結果の文字列の妥当性を確認します。
例えば、最新のブラウザのアドレスバーにIRI http://Bücher.deと入力すると、「ü」はASCII文字ではありませんが、対応するサイトにアクセスします。これは、IRI内のIDNが、DNSによってそのサイトの実際の保存先であるPunycode文字列に解決されるためです。同様に、ブラウザが<a href="http://Bücher.de">のようなリンクを含むウェブページを解釈すると、適切なサイトにアクセスします。（この文書では、「ブラウザが解釈する」などの表現は、アドレスバーに入力されたIRIから解析されたドメイン名だけでなく、HTMLテキスト内のリンクに含まれるドメイン名も指します。） IDN Bücher.deの場合、実際にネットワーク上でドメイン名に使用されるPunycode値はxn--bcher-kva.deです。Punycodeバージョンは通常、表示のためにUnicode形式に変換されます。結果として得られる表示文字列は、IDNA2003 規則に従って既にマッピングされている文字列になります。この例では、IRI が小文字に変換された表示文字列が生成されます。
IDNA2003 の主な制限は、Unicode 3.2 の文字レパートリーに制限されていることです。そのため、一部の現代言語はサポートされていないか、完全にはサポートされていません。さらに、IDNA2003 の制約下では、レパートリーを拡張する簡単な方法はありません。また、IDNA2003 では、レジストリのユーザーに対して、ドメイン名（例えば Bücher.de と bücher.de の間）のどの文字列を登録しているのかが明確に示されていません。
1.2 IDNA2008
2010年初頭、IDNAの新バージョンが承認されました。IDNA2003と同様に、このバージョンはRFCの集合で構成され、IDNA2008 IDNA2008 と呼ばれています。IDNA2008は、IDNA2003の主要な問題を解決することを目的としています。ドメイン名の有効な文字レパートリーを拡張し、Unicode標準の将来のバージョンへの自動更新プロセスを確立します。さらに、有効なドメイン名の概念を明確に定義することで、登録者は登録されているドメイン名文字列を正確に理解できます。 IDNA2008の処理は、多くの一般的なドメイン名についてIDNA2003と同一です。IDNA2003とIDNA2008はどちらも、IRI形式のUnicodeドメイン名（http://öbb.atなど）をPunycode形式（http://xn--bb-eka.atなど）に変換します。ただし、IDNA2008はIDNA2003との厳密な後方互換性を維持していません。主な違いは以下のとおりです。 追加 一部のIDNはIDNA2003では無効ですが、IDNA2008では有効です。
減算 一部のIDNはIDNA2003では有効ですが、IDNA2008では無効です。
逸脱 一部のIDNは両方で有効ですが、異なる宛先に解決されます。
1.3 移行に関する考慮事項 Transition Considerations
IDNA2008とIDNA2003の違いは、相互運用性およびセキュリティ上の問題を引き起こす可能性があります。これらの違いは、すべての大文字、すべての半角または全角文字（日本、中国、韓国で一般的に使用される）、そしてドイツ語のエスツェット（U+00DF ß ラテン小文字シャープS）やギリシャ語の末尾のシグマ（U+03C2 ς ギリシャ小文字末尾シグマ）といった特定の文字など、非常に一般的な文字に影響します。シャープsやシグマなどの「逸脱」文字については、業界はIDNA2008の動作に完全に移行しており、移行処理は非推奨となっています。
1.3.1 マッピング Mapping
IDNA2003では、例えばÖBB.atをöbb.atにマッピングするマッピングフェーズが必要です。マッピングでは通常、大文字を小文字のペアにマッピングしますが、日本語の半角カタカナを通常のカタカナにマッピングするなど、同等の文字間の他の種類のマッピングも含まれます。IDNA2003のマッピングフェーズは、ASCIIドメイン名の大文字と小文字を区別しないという仕様に対応するために追加されました。ユーザーはCNN.comとcnn.comがどちらも同じように動作することに慣れています。アクセント付きのドメイン名の大文字と小文字の区別も同様に行われることを期待しており、ÖBB.atはöbb.atと同じです。他の文字体系における大文字と小文字の違いと同様のバリエーションがあります。IDNA2003のマッピングは、Unicode標準バージョン3.2で規定されたデータに基づいています。このマッピングは後にUnicodeプロパティNFKC_Casefoldとして公式化されました。 大文字と小文字の折り返しによって、機能的な大文字と小文字の違いが消去された安定した形式の文字列が生成されることに注意してください。これは小文字化とは異なります。特に、Unicode バージョン 8.0 で追加された小文字のチェロキー文字は、大文字に変換されます。
IDNA2008 ではマッピングフェーズは必須ではありませんが、許可されています（「ローカルマッピング」または「カスタムマッピング」と呼ばれます）。許可されているマッピングの詳細については、IDNA2008 のプロトコル文書のセクション 4.2「許可された文字とラベルの検証」およびセクション 5.2「Unicode への変換」を参照してください。 UTS #46 仕様は、IDNA2008 プロトコルの規範的要件に準拠し、IDNA2003 とほぼ互換性のあるマッピングを定義しています。クライアントソフトウェアにとって、これはドメイン名と既存データの処理に関するユーザーの期待に最も合致した動作、つまりドメイン名が大文字と小文字を区別しない動作を提供します。 1.3.2 逸脱 Deviations
互換性マッピングなしでIDNA2008を使用すると、レジストリまたは登録者が特別な措置を講じない限り、IDNがIDNA2003とは異なるIPアドレスに解決される状況がいくつかあります。影響を受ける文字はごくわずかですが、これらの文字は特定の言語で非常によく使用されるため、それらの言語のドメイン名のかなりの数が影響を受けます。この文字セットは「逸脱」Deviationsと呼ばれ、表1「逸脱文字」にIRIのコンテキストで示されています。
table:表1 逸脱文字
文字 例 IDNA2003の結果 IDNA2008の結果
IDNA2008 におけるこれらの逸脱の発生理由の詳細については、IDN FAQ を参照してください。 アリスはフィッシングサイトにアクセスし、銀行のパスワードを入力し、金銭を盗まれます。.DEレジストリ（DENIC）は、ßのすべての変種をまとめて（所有者を同じにするため）管理するポリシーを持っているかもしれませんが、レジストリにはそれが義務付けられていません。すべてのレジストリが、このようなすべてのケースにおいて、このような管理ポリシーを策定し、適用する可能性は低いでしょう。
特に懸念される逸脱が2つあります。IDNA2008では、ラベルに結合文字（ZWJおよびZWNJ）を使用できます。一方、IDNA2003では、これらの文字はマッピングによって削除されます。特定のスクリプトにおいて、意図されたコンテキストで使用されると、結合文字は表示されるテキストに顕著な変化をもたらします。しかし、それらのスクリプト内、あるいは他のスクリプト内で、他の文字の間に使用されると、結合文字は見えなくなります。例えば、ラテン文字の「a」と「b」の間に使用される場合、見た目の違いは見分けられません。つまり、「a<ZWJ>b」という並びは「ab」と全く同じように見えます。
結合文字によって視覚的に混同が生じる可能性があるため、IDNA2008ではCONTEXTJという特別なカテゴリを設け、CONTEXTJ文字は限られたコンテキスト（アラビア語またはインド語の特定の並び）でのみ使用できます。ただし、IDNA2008ルックアップを実行するアプリケーションはこれらのコンテキストをチェックする必要がないため、全体的なセキュリティはレジストリの正しい実装に依存します。さらに、IDNA2008のコンテキスト制限では、異なるドメイン名がZWJやZWNJによって視覚的に混同されるような外観を持つケースのほとんどを捕捉できません。
これらの「逸脱」については、業界はIDNA2008の動作に完全に移行しており、移行処理は非推奨となっていることに注意してください。
2 Unicode IDNA互換処理
マッピングに関するユーザーの期待に応え、また（本来は）IDNA2003との互換性を確保するために、本文書ではIDNA2008で使用するマッピングを規定します。さらに、本文書では、IDNA2003とIDNA2008の相違点に起因するセキュリティおよび相互運用性の問題を、準拠実装が最小限に抑えられるよう、標準化された処理のためのUnicodeアルゴリズムを提供します。このUnicode IDNA互換処理は、IDNA2003の原則に従って構成されていますが、その原則をUnicode 5.2以降に拡張しています。また、IDNA2008が提供するレパートリー拡張も組み込んでいます。
UTS #46 は、適合性条項C3への適合を明示的に主張することにより、IDNA2008の前処理（ローカルマッピング）としてのみ使用できます。 この互換処理を使用することで、ÖBB.atのようなドメイン名は有効なドメイン名öbb.atにマッピングされ、ドメイン名における大文字と小文字の区別に関するユーザーの期待に応えます。移行的な用途として、互換性処理では、√.com（関連ウェブページあり）など、IDNA2003で有効だった記号や句読点を含むドメイン名も許可されます。このような記号を含むドメイン名は、レジストリがIDNA2008に移行するにつれて徐々に廃止されます。
実装によっては、記号や句読点を含むドメイン名を制限したり、UIでフラグ付けしたりすることもできます。詳細については、Unicode技術レポート#36「Unicodeセキュリティに関する考慮事項」UTR36を参照してください。 Unicode IDNA互換性処理を使用してIDNをDNSルックアップに適した形式に変換することは、「IDNA2008を試してからIDNA2003を試す」という戦略に似ています。しかし、このアプローチは、問題が発生する可能性のある二重ルックアップを回避します。ブラウザや検索エンジンなどのクライアントは、2つの異なる実装と複数のテーブルを維持する負担なしに、単一の処理ステップで済みます。問題を引き起こす可能性のある多くのエッジケースを考慮し、予測可能な結果をもたらす安定した定義を提供します。
Unicode IDNA互換処理は、逸脱文字の代替マッピングも提供します。これにより、IDNA2003からIDNA2008への移行が容易になります。レジストリは、サポートする逸脱文字をバンドルするかブロックするかなど、移行をどのように処理するかを決定します。実際には、逸脱文字については移行は完了しています。主要な実装はすべて、4つの逸脱文字を非移行処理に切り替えています。
「レジストリ」という用語には、.deや.comなどのトップレベルレジストリよりもはるかに多くのものが含まれます。例えば、.blogspot.comは、ほとんどのトップレベルレジストリよりも多くのドメイン名を登録しています。レジストリとそのサブレジストリには、異なるポリシーが適用される場合があります。したがって、移行戦略においては、数百ではなく数百万のレジストリを考慮する必要があります。
ルックアップソフトウェアでは、移行はきめ細かく行われる場合があります。例えば、ある時点で .subdomain.com の逸脱(Deviations) に関する IDNA2008 ルールに移行できるものの、.com では移行できない、あるいはその逆の場合があります。.tld が 逸脱(Deviations) 文字をバンドルまたはブロックする場合、クライアントは .tld の 逸脱(Deviations) に移行できますが、（例えば）.subdomain.tld の 逸脱(Deviations) は移行できません。さらに、ブラウザのアドレスバーのような UI を備えたクライアントソフトウェアは、移行のためのより多くのオプションを提供できます。このような移行戦略に関する詳細な議論は、このドキュメントの範囲外です。
移行期間中、HTML ドキュメントなどのドキュメントの作成者は、ドメイン名ラベルの Punycode 形式を明示的に使用することで、IDNA2008 の文字解釈を明確に参照できます。
ドメイン名には、移行中と移行後に、わずかに異なる 2 つの互換性メカニズムがあります。 UTS #46 では、2種類の処理、すなわち移行処理（適合条項 C1）と非移行処理（適合条項 C2）を規定しています。これらの処理の唯一の違いは、4つの逸脱文字の処理です。 簡単にまとめると、UTS #46 は IDNA2008 を次の3つの領域で基盤としています。 マッピング UTS #46 のマッピングは、最大限の互換性を維持し、ユーザーの期待に応えるために使用されます。これは、マッピング入力が可能な IDNA2008 に準拠しています。 記号と句読点 UTS #46 は記号と句読点の処理をサポートしています。IDNA2008 を実装するレジストリは、記号を含む IDN の DNS ルックアップを拒否します。 逸脱（非推奨） UTS #46 は、移行をサポートするために、これらを処理する2つの方法を提供しています。移行処理（非推奨）は、レジストリがバンドルまたはブロッキングの戦略を保証しない状況において、DNS ルックアップの直前に使用することが推奨されていました。 IDNA2008と完全に互換性のある非移行処理を、常に使用する必要があります。 IDNA2003、IDNA2008、およびUnicode IDNA互換処理の違いについては、DemoIDNを参照してください。 UTS #46 は、AラベルやUラベルなど、IDNA2008で定義されている用語を変更するものではありません。 Unicode IDNA互換性処理もIDNA2008も、混同しやすい文字に関連するセキュリティ問題（いわゆる「paypal.com問題」）には対処していません。IDNA2008は、スラッシュ文字（「/」）の偽装など、なりすましに使用可能な特定の記号や句読点を禁止しています。しかし、これらはなりすましに用いられる混同しやすい文字のごく一部です。さらに、混同しやすい文字自体がフィッシング問題に占める割合は小さく、そのほとんどは「secure-wellsfargo.com」のようなケースです。詳細については、BortzmeyerおよびIDN FAQを参照してください。クライアントソフトウェアとレジストリの両方において、混同しやすい単語への対処方法については、Unicode技術レポート#36「Unicodeセキュリティに関する考慮事項」UTR36およびUnicode技術標準#39「Unicodeセキュリティメカニズム」UTS39を参照することを強くお勧めします。特にUTS39は、国際化ドメイン名を扱う際に、IDNA2008よりもはるかに大幅に混同しやすい単語の数を削減するための情報を提供しています。DemoConfも参照してください。 2.1 国際化ドメイン名の表示
2.2 レジストリ
この仕様は主にIDNの検索を行うアプリケーションを対象としています。ただし、レジストリに対しては、非遷移処理（Nontransitional Processing）に基づいて無効と判断されるラベルの登録を許可しないこと、そして混同しやすい文字を含むラベルについては、必ずバンドル化またはブロッキングを行うことを強く推奨します。
これらの戦略は以下のように説明できます。
バンドル化：2つ以上のラベルが異なるものの混同しやすく、かつ複数登録されている場合、それぞれの登録者は同一である必要があります。
ブロッキング：2つ以上のラベルが異なるものの混同しやすい場合、1つのラベルのみの登録を許可し、残りはブロックします。逸脱文字を一切許可しないレジストリは、ブロッキングとみなされます。
注：Unicode以外の実装では、これらの戦略に異なる用語が使用されています。特に、ICANNルートゾーンラベル生成規則（RZLGR5）では、Xとバンドル可能なラベルには「Xの割り当て可能バリアント」という用語が使用され、相互に排他的なラベルには「ブロックされたバリアント」という用語が使用されます。
実際に登録され、レジストリに挿入されるラベルは、常に処理済み(processed)です。例えば、xn--bcher-kva は bücher に対応します。しかし、レジストリが登録者の意図を把握するために、登録プロセスの一環として、Bücher のような「未処理(unprocessed)」ラベルも要求することが有用な場合があります。ただし、このような未処理ラベルは慎重に扱う必要があります。
未処理(unprocessed)ラベルを、登録者が実際に申請したかった文字列として保存する。
未処理(unprocessed)ラベルを処理し、処理済みのラベルを登録者に確認のために表示する。
処理済み(processed)のラベルのみを使用して、通常の登録プロセスを進める。
2.3 表記法 Notation
コードポイントの集合は、Unicode技術標準(Unicode Technical Standard) #18 、Unicode正規表現(Unicode Regular Expressions)UTS18のプロパティと構文を用いて定義されます。例えば、結合記号の集合は \p{gc=M} という構文で表されます。また、分かりやすくするために、「+」は集合への要素の追加を示します。 この文書では、ラベルとはドメイン名の部分文字列を指します。この部分文字列の両端は、文字列の先頭または末尾、あるいはラベル区切り文字と呼ばれる以下のいずれかの文字で区切られます。
U+002E ( . ) ピリオド
U+FF0E ( ． ) 全角ピリオド
U+3002 ( 。 ) 漢字ピリオド
U+FF61 ( ｡ ) 半角漢字ピリオド
多くの人が「ドメイン名」と「ホスト名」という用語を同じ意味で使用しています。この文書では、「ドメイン名」という用語の使用に関してRFC3490に準拠しています。 Bidiドメイン名とは、Bidi_ClassがR、AL、またはANである文字を少なくとも1つ含むドメイン名です。IDNA2008 RFC 5893、セクション1.4を参照してください。 3 準拠 Conformance
Unicode IDNA互換処理アルゴリズムの実装における適合性要件は、以下の条項に規定されています。実装は、これらの条項のいずれか、またはすべてに独立して適合性を主張することができます。
C1（非推奨） UnicodeのバージョンとUnicode文字列が与えられた場合、適合する遷移処理の実装は、第4節「処理」で規定される遷移処理アルゴリズムを適用した結果を再現しなければなりません。
C2 UnicodeのバージョンとUnicode文字列が与えられた場合、適合する非遷移処理の実装は、第4節「処理」で規定される非遷移処理アルゴリズムを適用した結果を再現しなければなりません。
C3 UnicodeのバージョンとUnicode文字列が与えられた場合、適合するIDNA2008用前処理の実装は、第4.4節「IDNA2008用前処理」で規定される結果を再現しなければなりません。
これらの仕様は論理的なものであり、記述しやすいように設計されています。実際の実装では、結果が論理アルゴリズムで規定される結果と同じである限り、異なる手法を自由に使用できます。
適合実装は、セクション4.1「妥当性基準」で規定されているものよりも厳しい妥当性基準を持つ場合もあります。例えば、アプリケーションは、次のような特定の特性を持つドメイン名ラベルを禁止または警告することができます。
特定のスクリプトの組み合わせを含むラベル (Safari)
ユーザーが指定した言語以外の文字を含むラベル (IE)
特定の混同しやすい文字を含むラベル (Firefox)
IDNA2008 の妥当性要件を満たさないラベル
toUnicode によって生成されたラベルで、toASCII を実行した場合にはラベルの妥当性要件を満たさないもの
Unicode技術標準#39「Unicodeセキュリティメカニズム」UTS39の「識別子の一般セキュリティプロファイル」に含まれない文字を含むラベル Unicode技術標準#39「Unicodeセキュリティメカニズム」UTS39の「制限レベル4（中程度の制限）」を満たさないラベル 詳細については、「Unicode技術レポート#36「Unicodeセキュリティに関する考慮事項」UTR36」および「Unicode技術標準#39「Unicodeセキュリティメカニズム」UTS39」を参照してください。 3.1 STD3ルール
IDNA2003は、実装がSTD3のルールに従うかどうかを選択できるフラグUseSTD3ASCIIRulesを提供しています。これらのルールは、A-Z、a-z、0-9、およびU+002D (-) HYPHEN-MINUS以外のASCII文字を除外します。例えば、一部のブラウザでは、ドメイン名にU+005F (_) LOW LINE (アンダーバー)などの文字も許可しており、妥当性基準のチェック時に有効なASCII文字のカスタムセットを使用します。 4 処理
Unicode IDNA互換処理への入力は、Unicodeで表現されたドメイン名候補文字列と、Transitional(移行期)処理またはNontransitional(非移行期)処理のいずれかです。ドメイン名は、「Bücher.de」のように、ドット区切りのラベルの列で構成されます。URLの構成に関する詳細は、STD13のセクション3.5を参照してください。 主な処理手順
以下の手順は、順に実行され、入力されたドメイン名文字列を順次変更し、変換されたUnicode文字列と、エラーの有無を示すフラグを出力します。エラーが発生した場合でも、文字列の変換は可能な限り実行されます。
入力
Unicodeコードポイントのシーケンスで表現された、ドメイン名候補
booleanフラグ: UseSTD3ASCIIRules
booleanフラグ: CheckHyphens
booleanフラグ: CheckBidi
booleanフラグ: CheckJoiners
booleanフラグ: Transitional_Processing（非推奨）
booleanフラグ: IgnoreInvalidPunycode
処理
1. Map マッピング。domain_name文字列内の各コードポイントについて、セクション5「IDNAマッピングテーブル」のステータス値を参照し、以下のアクションを実行します。
disallowed 不許可: 文字列内のコードポイントを変更せずにそのまま残します。注: 以下の変換/検証手順では、マッピングと正規化の後に、許可されていない文字がないか確認します。
ignored 無視された: 文字列からコードポイントを削除します。これは、コードポイントを空の文字列にマッピングすることと同じです。
mapped マッピングされた: Transitional_Processing（非推奨）で、コードポイントがU+1E9Eの大文字シャープs（ẞ）の場合、文字列内のコードポイントを「ss」に置き換えます。それ以外の場合:
文字列内のコードポイントを、セクション5「IDNAマッピングテーブル」のマッピングの値に置き換えます。
deviation 逸脱:
Transitional_Processing（非推奨）の場合、文字列内のコードポイントを、セクション5「IDNAマッピングテーブル」のマッピングの値に置き換えます。
それ以外の場合、文字列内のコードポイントを変更せずにそのまま残します。
valid 有効: 文字列内のコード ポイントを変更せずにそのままにします。
2. Normalize 正規化: ドメイン名文字列をUnicode正規化形式Cに正規化します。
3. Break 分割: 文字列をU+002E ( . ) ピリオドでラベルに分割します。
4. Convert/Validate 変換/検証: ドメイン名文字列内の各ラベルについて、以下の処理を行います。
ラベルが「xn--」で始まる場合:
1. ラベルに非ASCIIコードポイント（U+007Fより大きいコードポイント）が含まれている場合、エラーが発生したことを記録し、次のラベルに進みます。
2. ラベルの残りの部分をPunycode RFC3492に従ってUnicodeに変換しようとします。変換が失敗し、IgnoreInvalidPunycodeでない場合は、エラーが発生したことを記録し、次のラベルに進みます。それ以外の場合は、文字列内の元のラベルを変換結果で置き換えます。 3. ラベルが空の場合、またはラベルにASCIIコードポイントのみが含まれている場合は、エラーが発生したことを記録します。
4. ラベルがセクション4.1「非移行的処理の妥当性基準」の妥当性基準を満たしていることを確認してください。妥当性基準のいずれかが満たされていない場合は、エラーがあったと記録してください。
ラベルが「xn--」で始まっていない場合：
ラベルがセクション4.1「入力処理の選択肢（移行的または非移行的）の妥当性基準」の妥当性基準を満たしていることを確認してください。妥当性基準のいずれかが満たされていない場合は、エラーがあったと記録してください。
エラーが記録されない入力ドメイン名文字列は、この仕様に従って正常に処理されたことになります。逆に、入力ドメイン名文字列がエラーを引き起こした場合、その入力ドメイン名文字列の処理は失敗します。エラー入力の処理方法は呼び出し元が決定するものであり、この文書の範囲外です。処理はべき等であり、出力に処理を再適用してもそれ以上の変更は行われません。例については、表2「遷移処理の例」を参照してください。
実装は、結果のUnicode文字列をユーザーに表示する際に、さらに変更を加える場合があります。例えば、禁止文字はU+FFFDに置き換えてユーザーに認識させることが推奨されます。同様に、ステップ4で処理に失敗したラベルは、U+FFFDなどの視覚的なデバイスを挿入することでマークすることができます。
遷移処理または非遷移処理のいずれの場合でも、既にPunycodeで記述されているソースは、マッピングなしで検証されます。特に、href="xn--fu-hia.de"（fuß.de）のような、デビエーション文字を含むPunycodeは再マッピングされません。これにより、移行期間中であってもデビエーション文字を明示的に使用できるメカニズムが提供されます。
4.1 妥当性基準
空でないラベルは、以下の各基準を満たす必要があります。
1. ラベルはUnicode正規化形式NFCで記述されている必要があります。
2. CheckHyphensを使用する場合、ラベルの3番目と4番目の位置の両方にU+002D HYPHEN-MINUS文字を含んではなりません。
3. CheckHyphensを使用する場合、ラベルの先頭と末尾にU+002D HYPHEN-MINUS文字を使用してはなりません。
4. CheckHyphensを使用しない場合、ラベルは「xn--」で始まってはなりません。
5. ラベルにU+002E ( . ) ピリオドを含んではなりません。
6. ラベルは結合記号（General_Category=Mark）で始まってはなりません。
7. ラベル内の各コードポイントは、セクション5のIDNAマッピングテーブルに従って、特定のステータス値のみを持つ必要があります。
1. Transitional Processing（遷移処理 非推奨）の場合、各値はvalid(有効)である必要があります。
2. Nontransitional Processing (非遷移処理)の場合、各値は有効または偏差のいずれかである必要があります。
3. さらに、UseSTD3ASCIIRules=true で、コードポイントが ASCII コードポイント (U+0000..U+007F) の場合、小文字 (a-z)、数字 (0-9)、またはハイフン-マイナス (U+002D) である必要があります。(注: これは、UTS #46 でマッピングされ、IDNA2008 では許可されていない大文字の ASCII A-Z を除きます。) 8. CheckJoiners の場合、ラベルは『The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)』IDNA2008 の付録 A に記載されている ContextJ 規則を満たす必要があります。 9. CheckBidi であり、ドメイン名が Bidi ドメイン名である場合、ラベルは IDNA2008 RFC 5893 セクション 2 の番号付き条件 6 つすべてを満たす必要があります。 最初の 6 つの基準は IDNA2008 に由来しますが、4 番目の基準は除きます。特に基準 2 は、IDNA の将来のバージョンなど、xn-- 以外のラベル拡張を将来的に許容することを目的としています。一部の実装では、このような拡張は考えにくいため、「r3---sn-apo3qvuoxuxbt-j5pe」のようなラベルを許容しているようです。 セクション 3「適合性」で説明されているように、特定のアプリケーションではより厳しい妥当性基準が適用される場合があります。
4.1.1 UseSTD3ASCIIRules
Unicode 16.0以降、UseSTD3ASCIIRules=trueは妥当性基準でのみ処理されます。実装では追加のASCII文字を許可するように選択できますが、ASCII小文字、数字、およびハイフン-マイナス記号(\u002Da-z0-9)は常に有効とみなす必要があります。 注: ASCII文字はマッピングの結果である可能性があります。例えば、U+005F (_) LOW LINE (アンダーバー) は、元々はU+FF3F (＿) FULLWIDTH LOW LINEであった可能性があります。
4.1.2 右から左に書く文字
さらに、ラベルは、IDNA2008の右から左に書く文字に関する文書で規定されている右から左に書く文字の要件、およびIDNA2008のプロトコル文書で規定されているCONTEXTJ要件を満たす必要があります。混同しやすい文字の扱い方や識別子から除外すべき文字については、Unicode技術報告書#36「Unicodeセキュリティに関する考慮事項」UTR36およびUnicode技術標準#39「Unicodeセキュリティメカニズム」UTS39を参照することを強く推奨します。推奨される除外文字は、IDNA2008の除外文字のスーパーセットであることに注意してください。 4.2 ToASCII
RFC3490 の ToASCII に相当する操作は、以下の手順で定義されます。 入力
Unicode コードポイントのシーケンスとして表現された、想定されるdomain_name
booleanフラグ: CheckHyphens
booleanフラグ: CheckBidi
booleanフラグ: CheckJoiners
booleanフラグ: UseSTD3ASCIIRules
booleanフラグ: Transitional_Processing (非推奨)
booleanフラグ: VerifyDnsLength
booleanフラグ: IgnoreInvalidPunycode
処理
1. 入力ドメイン名に対して、セクション4「処理」の処理手順を適用します。この処理手順では、入力ブールフラグ Transitional_Processing、CheckHyphens、CheckBidi、CheckJoiners、および UseSTD3ASCIIRules を使用します。この処理によりエラーが記録される可能性があります。
2. 結果を U+002E FULL STOP でラベルに分割します。
3. 非ASCII文字を含む各ラベルをPunycode RFC3492 に変換し、先頭に「xn--」を付けます。この処理によりエラーが記録される可能性があります。 4. VerifyDnsLength フラグが true の場合、DNS の長さ制限を検証します。この処理によりエラーが記録される可能性があります。詳細については、STD13 および STD3 を参照してください。 1. ドメイン名の長さ（ルートラベルとそのドットを除く）は、1～253です。
2. 各ラベルの長さは1～63です。
注：技術的には、完全なドメイン名はDNSルートの空ラベルで終わります（STD13 RFC1034 セクション3を参照）。この空ラベルと末尾のドットは、ほとんどの場合省略されます。 VerifyDnsLengthがfalseの場合、空のルートラベルはそのまま通過します。
VerifyDnsLengthがtrueの場合、空のルートラベルは許可されません。これは、RFC1034 セクション3.5「優先名構文」の構文に対応しており、ラベル長の制限も定義されています。 5. 手順1～4でエラーが記録された場合、操作は失敗し、失敗値が返されます。DNSルックアップは実行されません。
6. それ以外の場合は、U+002E FULL STOPを区切り文字としてラベルを結合し、結果を返します。
実装においては、これらのラベルに対して、Unicode技術レポート#36「Unicodeセキュリティに関する考慮事項」UTR36およびUnicode技術標準#39「Unicodeセキュリティメカニズム」UTS39に記載されているような追加テストを適用し、適切な措置を講じることが推奨されます。例えば、混在した文字や混同しやすい文字を含むラベルは、UIで警告される場合があります。ただし、UTR36に記載されているように、Punycodeを使用して問題を通知することは逆効果になる可能性があることに注意してください。 4.3 ToUnicode
RFC3490 の ToUnicode に相当する操作は、以下の手順で定義されます。 入力
Unicode コードポイントのシーケンスとして表現された、想定される domain_name
booleanフラグ: CheckHyphens
booleanフラグ: CheckBidi
booleanフラグ: CheckJoiners
booleanフラグ: UseSTD3ASCIIRules
booleanフラグ: Transitional_Processing (非推奨)
booleanフラグ: IgnoreInvalidPunycode
処理
1. 入力domain_nameに対して、セクション4「処理」の処理手順を適用します。この処理では、入力booleanフラグ Transitional_Processing、CheckHyphens、CheckBidi、CheckJoiners、および UseSTD3ASCIIRules を使用します。これによりエラーが記録される場合があります。
RFC3490 と同様に、これは常に変換された Unicode 文字列を生成します。RFC3490 の ToASCII とは異なり、これは常にエラーの有無を通知します。 実装では、これらのラベルに対して、Unicode 技術レポート #36「Unicode セキュリティに関する考慮事項」UTR36 および Unicode 技術標準 #39「Unicode セキュリティメカニズム」UTS39 に記載されているような追加テストを適用し、適切な措置を講じることが推奨されます。例えば、混在スクリプトや混同しやすい文字を含むラベルは、UI で警告される場合があります。UTR36 に記載されているように、Punycode を使用して問題を通知することは逆効果になる可能性があることに注意してください。 4.4 IDNA2008の前処理
セクション5「IDNAマッピングテーブル」で指定されたテーブルは、IDNA2008の純粋な前処理ステップにも使用できます。このステップでは、入力されたUnicode文字列をIDNA2008で指定されたアルゴリズムに直接マッピングします。
IDNA2008の前処理は、以下のように規定されます。
セクション4.3「ToUnicode」処理をUnicode文字列に適用します。
この前処理では、IDNA2008では無効な文字も許可されます。ただし、IDNA2008の処理では、これらの文字も検出されます。例えば、U+2665 (♥) BLACK HEART SUITのように、IDNA2008でDISALLOWED（許可されない文字）とされている文字を含むUnicode文字列は、前処理ステップではエラーなしで通過しますが、その後にIDNA2008処理を適用すると、文字列がIDNA2008では有効なIDNではないことを示すエラーが発生し、失敗します。
4.5 実装上の注意
Unicode IDNA互換処理には、様々な最適化を適用できます。これらの最適化により、パフォーマンスの向上、テーブルサイズの削減、既存のNFKC変換メカニズムの利用などが実現します。例えば、以下のようになります。
セクション4.1「妥当性基準」にはNFCチェックがありますが、これはステップ3でPunycodeからUnicodeに変換されたラベルにのみ適用する必要があります。
セクション4.1「妥当性基準」の妥当性チェックの大部分を行う簡単な方法は、ステップ1と2を再適用し、結果が変わらないことを確認することです。
ステップ1で4つのラベル区切り文字はすべてU+002E ( . ) FULL STOPにマッピングされているため、ステップ3と4でのラベル解析ではU+002E ( . ) FULL STOPのみを検出すればよく、IDNA RFC3490で定義されている他のラベル区切り文字は検出する必要はありません。 Unicode IDNA互換性処理の入力ドメイン名文字列では、エスケープされたすべてのUnicodeコードポイントがUnicodeコードポイントに変換されている必要があることに注意してください。例えば、U+5341 ( 十 ) CJK UNIFIED IDEOGRAPH-5341 は、次のいずれかの方法でエスケープできます。
十 HTML数値文字参照 (NCR)
\u5341 a Javascriptエスケープ
%E5%8D%81 a URI/IRI %エスケープ
例は表2「処理例」に示されています。
table:表2 処理の例
Input Map Normalize Convert Validate Comment
入力 マップ 正規化 変換 検証 コメント
Bloß.de bloss.de = n/a ok 遷移（非推奨）：大文字とシャープのsをマッピングします
bloß.de = n/a ok 非遷移: 大文字をマップする
BLOẞ.de bloß.de = n/a ok 大文字でマップします
xn--blo-7ka.de = = bloß.de ok Punycode はマッピングされていないため、ß は変更されません (移行的であるかどうかに関係なく)。
u¨.com = ü.com n/a ok u + ウムラウトを ü に正規化します。
xn--tda.com = = ü.com ok Punycode の xn--tda が ü に変更される
xn--u-ccb.com = = u¨.com error Punycodeはマッピングされていませんが、検証済みです。u + ウムラウトはNFCではないため、失敗します。
a⒈com error error error error 文字「⒈」はマッピング時にドットが生成されるため、使用できません。
xn--a-ecp.ru xn--a-ecp.ru = a⒈.ru error Punycode xn--a-ecp = a⒈ は検証に失敗します。
xn--0.pt xn--0.pt = error error Punycode xn--0 は無効です。
日本語。ＪＰ 日本語.jp = n/a ok 。を含む全角文字が再マップされます。
☕.us = = n/a ok Unicode 3.2 以降の文字が許可されます。
5. IDNAマッピングテーブル
Unicodeの各コードポイントについて、IDNAマッピングテーブルは以下のいずれかのステータス値を提供します。
valid：コードポイントは有効であり、変更されません。
ignored：コードポイントは削除されます。これは、コードポイントを空の文字列にマッピングすることと同じです。
mapped：文字列内のコードポイントは、マッピングされた値に置き換えられます。
deviation：処理が移行処理であるか否かによって、コードポイントはマッピングされるか有効になります。
disallowed：コードポイントは許可されません。
このステータス値がmappedまたはdeviationの場合、テーブルにはそのコードポイントのマッピング値も提供されます。
Unicode 5.1以降の各バージョンのUnicodeに対応したテーブルが、IDNA-Tableディレクトリ内のバージョン管理されたディレクトリに用意されています。 Unicode規格の各バージョンに対応するテーブルは、常に以前のバージョンとの下位互換性を維持します。ステータス値が許可されていない文字のみが、ステータス値またはマッピング値を変更できる場合があります。ただし、以下の例外があります。 移行処理の廃止に伴い、Unicode 15.1では以下の例外的な変更が行われました。
Unicode 15.1より前は、U+1E9Eの大文字シャープs（ẞ）は、U+00DFの小文字シャープs（ß）も「ss」にマッピングされる移行処理と同様に、無条件に「ss」にマッピングされていました。
Unicode 15.1以降、非移行処理を使用する場合、大文字シャープsは小文字シャープsにマッピングされ、非移行処理では有効な文字として扱われます。これがテーブルにおける新しいマッピング値です。
移行処理（非推奨）を使用する場合、U+1E9Eの大文字シャープs（ẞ）は、U+00DFの小文字シャープs（ß）の偏差マッピングと同様に、引き続き「ss」にマッピングされます。これは処理中に処理されます。
IDNA2008テーブルとは異なり、このテーブルは個々のラベルだけでなく、ドメイン名全体に適用されるように設計されています。この設計により、IDNA2003におけるラベル区切り文字の処理が可能になります。特に、このテーブルは、U+2488 (⒈) のような問題のある文字（分解結果に「ドット」が含まれる）を排除するように構築されています。
Unicode IDNA互換性処理は、Unicode文字マッピングプロパティNFKC_Casefoldに基づいています。セクション6「マッピングテーブルの導出」では、これらのテーブルの導出について説明しています。Unicode文字データベースの導出プロパティと同様に、導出の説明は参考情報です。この仕様の適用において規範となるのは、IDNAマッピングテーブルのデータのみです。 ファイルは、Unicode文字データベースUAX44と同様のセミコロン区切り形式を使用します。フィールド値は、表2b「データファイルフィールド」に記載されています。 table:2b データファイルフィールド
数 Field 説明
0 Code point(s) 16進数値または値の範囲。
1 Status valid(有効)、ignored(無視)、mapped(マッピング済み)、deviation(逸脱)、
またはdisallowed(不許可)
2 Mapping 16進数値。ステータスがignored(無視)、mapped(マッピング)、または
deviation(逸脱)の場合にのみ存在します。
3 IDNA2008 Status 値はNV8とXV8の2種類です。NV8は、ステータスが有効であるものの、
IDNA2008によってUnicodeのすべてのバージョンにおけるすべてのドメ
イン名から文字が除外されている場合にのみ存在します。XV8は、
IDNA2008によってUnicodeの現行バージョンにおいて文字が除外されて
いる場合に存在します。これらは規範的な値ではありません。
6 マッピングテーブルの導出
以下では、マッピングテーブルの導出について説明します。この説明は、第4章「処理」におけるラベルの実際のマッピングとは直接関係ありません。むしろ、この章では、第5章「IDNAマッピングテーブル」のテーブル導出について説明します。このテーブルは、第4章「処理」におけるマッピングに規範的に使用されます。
導出は一連の手順として記述されます。手順1では基本マッピングを定義します。手順2、3、4では3つの文字セットを定義します。手順5では、後方互換性を維持するために、必要に応じて基本マッピングまたは文字セットを変更します。手順6では、マッピングと文字セットすべてを使用して、テーブルのマッピング値とステータス値を生成します。手順7では、マッピングに無効な文字が含まれている文字を削除します。各手順にはサブステップが含まれる場合があります。例えば、手順1は手順1.1から1.2で構成されます。
将来のバージョンでUnicodeプロパティが変更され、下位互換性に影響が出る場合は、互換性を維持するために、対応する条項がステップ5に追加されます。互換性の詳細については、セクション5「IDNAマッピングテーブル」を参照してください。
Step 1：ベースマッピングを定義する
このステップでは、各Unicodeコードポイントから0個以上のコードポイントのシーケンスへのマッピングであるベースマッピングを指定します。特定のコードポイント C をマッピングした結果得られる値を、C の基本マッピング値と呼びます。C の基本マッピング値は、C そのものと同じになる場合があります。
1. 以下の例外文字をマッピングします。
a. ラベル区切り文字を U+002E ( . ) ピリオドにマッピングします。
U+FF0E ( ． ) 全角ピリオド
U+3002 ( 。 ) 等角ピリオド
U+FF61 ( ｡ ) 半角等角ピリオド
b. すべてのBidi_Control (双方向制御)文字を自身にマッピングします。
c. U+1E9E (ẞ) ラテン大文字シャープ S を U+00DF (ß) ラテン小文字シャープ S にマッピングします。
Unicode 6.3 では、Unicode 3.2 には存在しなかったBidi_Control(双方向制御)文字が追加されました。双方向制御文字を無視するのではなく、IDNA2003の意図である双方向制御文字の使用を禁止するために、ステップ1.1.bが追加されました。このステップにより、ステップ6.3で全ての双方向制御文字が禁止されます。
ステップ1.1.bは、Unicode 6.3で追加された5つの新しい文字のみに影響します。また、将来のバージョンで追加される双方向制御文字にも影響します。
ステップ1.1.c（Unicode 15.1で追加）では、大文字のシャープs（ẞ）を小文字のシャープs（ß）にマッピングします。これは、主要な実装全てが非遷移処理を採用しており、NFKC_Casefoldのようにßをssにマッピングしないためです。
Step 2：基本有効文字セットの指定
基本有効文字セット(base valid set)は、表3「基本有効文字セット」に示されている加算と減算の順序によって定義されます。この定義はIDNA2003の原則に基づいています。Unicode 3.2文字セットに適用すると、IDNA2003に非常に近い文字セットが生成されます。
table: 3. Base Valid Set
正式な集合表記 説明
\P{Changes_When_NFKC_Casefolded} まず、NFKC_Casefold の値と一致する文字から始めます。 この基準では、例えば大文字や、NFKC 正規化で不安定に
なる文字、およびデフォルトで無視されるコードポイント
は除外されます。
Perl/Java の構文では、\P は \p の逆を意味するため、
ングしても変化しません。
+ \u00DF LATIN_SMALL_LETTER_SHARP_S(ß)を追加します。
- \p{c} - \p{z} 未割り当て、コントロール、プライベート使用、
フォーマット、サロゲート、および空白を削除します。
- \p{IDS_Unary_Operator} 表意文字による記述を削除する。
- \p{IDS_Binary_Operator}
- \p{IDS_Trinary_Operator}
+ \p{ascii} - \u002E '.'以外のすべてのASCII文字を追加します。 Step 3：基本除外セットの指定
基本除外セットは、以下のコードポイントで構成されます。
U+FFFC オブジェクト置換文字
U+FFFD 置換文字
U+E0001～U+E007F タグ文字（未割り当てのコードポイントを含む）
Step 4：偏差セットの指定
これは、IDNA2003とIDNA2008の間で異なる文字のセットです。
U+200C ゼロ幅非結合子
U+200D ゼロ幅結合子
U+00DF (ß) ラテン小文字シャープS
U+03C2 (ς) ギリシャ小文字末尾シグマ
Step 5：下位互換性のための変更の指定
このセットは現在空です。上記のセットまたは基本マッピングに対する調整は、将来のバージョンのUnicodeにおいて既存の文字の状態またはマッピングが変更される可能性がある場合に、後方互換性を維持するためにこのセクションで行われます。
Step 6：初期ステータス値とマッピング値を生成する
各コードポイントについて：
1. コードポイントが偏差セットに含まれる場合
ステータスは偏差となり、マッピング値はそのコードポイントの基本マッピング値となります。
2. それ以外の場合、コードポイントが基本除外セットに含まれるか、または未割り当ての場合
ステータスは不許可となり、テーブルにマッピング値は存在しません。
3. それ以外の場合、コードポイントがラベル区切り文字ではなく、かつその基本マッピング値に含まれるコードポイントが基本有効セットに含まれていない場合
ステータスは不許可となり、テーブルにマッピング値は存在しません。
4. それ以外の場合、基本マッピング値が空文字列の場合
ステータスは無視され、テーブルにマッピング値は存在しません。
5. それ以外の場合、基本マッピング値がコードポイントと同じ場合
ステータスは有効となり、テーブルにマッピング値は存在しません。
6. それ以外の場合、
ステータスはマッピング済みとなり、マッピング値はそのコードポイントの基本マッピング値となります。
Step 7：最終的なステータス値とマッピング値を生成する
前のステップで全てのコードポイントを処理した後：
1. ステータスが「マッピング済み」の文字セットを順に処理します。マッピング値が有効な文字セットと例外的な文字セットの和集合に完全に含まれない文字は、使用不可とします。
2. ステータスの変更がなくなるまで、これらの処理を再帰的に適用します。
例えば、Unicode 15.1の場合、ステップ7で使用不可とされる文字セットは以下のとおりです。
U+FE12 ( ︒ ) 縦一文字のピリオドの表示形式
注：U+2488 ( ⒈ ) 数字の1のピリオドなどの文字は、ステップ6.3で使用不可とされています。
7. IDNAの比較
Unicode 15.1までは、このセクションではIDNA2003、UTS #46 、およびIDNA2008の違いについて詳細な比較を行っていました。移行期間が終了したため、Unicode 16.0以降、マッピングテーブルの導出ではIDNA2003のマッピングは考慮されなくなりました。したがって、この情報はもはや適用されません。 Unicodeは、IDNA2008に対応する派生プロパティファイルを提供しています。IDNA2008と比較すると、UTS #46 は主にマッピングを追加し、句読点と記号を有効とみなします。詳細については、セクション2「Unicode IDNA互換性処理」を参照し、IDNAマッピングテーブルを参照してください。 8. 適合性テスト
適合性テストファイル（IdnaTestV2.txt）は、Unicode 6.0以降の各バージョンのUnicode向けに、IDNA-Tableディレクトリ内のバージョン管理されたディレクトリに提供されています。このファイルには、UseSTD3ASCIIRules=trueの場合のテストケースのみが含まれています。 8.1 フォーマット
テストファイルはUTF-8で、可読性を高めるため、一部の文字は\uXXXXまたは\x{XXXX}の規則に従ってエスケープされています。詳細はテストファイルのヘッダーに記載されています。
8.2 適合性テスト
UTS #46 への適合性をテストするために、実装はソース文字列に対してtoUnicode、toAsciiN、toAsciiT演算を実行し、結果として得られる文字列と関連するステータス値を検証します。詳細はテストファイルのヘッダーに記載されています。 実装はUTS46のデフォルト設定よりも厳格である場合があります。特に、IDNA2008に準拠する実装では、NV8とマークされた行の入力は拒否されます。実装はエラーが発生したことのみを記録すればよく、無視されたステータス値を除いた後の正確なステータスコードを再現する必要はありません。
8.3 移行
16.0
バージョン16.0のテストファイルでは、ステータス値の生成におけるいくつかの誤りが修正され、いくつかの改善が行われています。
Unicode 16.0以降、テストフォーマットでは空文字列を表すのに「""」が使用されます。これは、引き続き異なる意味を持つ空白フィールド値とは対照的です。例：
""; ; [X4_2]; ; [A4_1, A4_2]; ; #
\u200C; ; [C1]; xn--0ug; ; ""; [A4_1, A4_2] #
詳細はテストデータファイルのヘッダーを参照してください。
1つ以上の新しいソース文字列が不正な形式であり、ペアになっていないサロゲートが含まれているため、ステータス値A3がテストケースでカバーされます。
Unicode 15.1における妥当性基準4の導入に合わせて、ステータス値V4～V6はV5～V7に番号が変更されました。
ファイルヘッダーのコメントで示唆されていた通り、小文字（a～z）、数字（0～9）、ハイフンマイナス（U+002D）以外のASCII文字には、ステータス値V7の代わりにU1が設定されます。
いくつかのステータス値に関するファイルヘッダーのコメントが修正または明確化されました。
11.0
バージョン11.0では、ユーザーが必要とする様々な入力オプションの組み合わせを表現できるように、テスト形式とファイル名が変更されました。新しい形式では、サポートされていない入力フラグに対応するステータスコードを除外することで、テスト実装がサポートフラグの組み合わせの結果を正確にテストできます。また、実用上あまり有用ではなかった値XV8は削除されました。
以下に、旧形式と新形式の違いを示します。この一連の例はすべてを網羅しているわけではありませんが、同じ例でさらに多くの情報が得られることを示しています。
11.0 より前のテスト データ形式のサンプル行:
code:sample
T; Faß.de; faß.de; fass.de
N; Faß.de; faß.de; xn--fa-hia.de
B; Bücher.de; bücher.de; xn--bcher-kva.de
11.0 以降のテスト データ形式のサンプル行:
code:11sample
Faß.de; faß.de; []; xn--fa-hia.de; ; fass.de;
Bücher.de; bücher.de; []; xn--bcher-kva.de; ; ;
à\u05D0; àא; B5 B6; xn--0ca24w; ; ; a。。b; a..b; A4_2; a..b; ; ; 9. IDNA派生プロパティ
Unicode文字データベースの各バージョン間の比較を容易にし、新しい文字の追加や文字プロパティの変更に伴う影響を明確にするため、Unicode技術委員会はIDNA派生プロパティのデータファイル集を作成しました。これらのデータファイルはIDNA-Derivedに永続的に掲載されています。 Unicode 6.1.0以降のUnicode標準の各バージョンにおいて、列挙型IDNA2008_Categoryプロパティの値が計算され、別のデータファイルに明示的に記載されています。このプロパティはRFC 5892で定義されている「IDNA派生プロパティ」に相当します（IDNA2008を参照）。明示的なリストは、実装者の便宜のために提供されています。これは、各バージョンのUnicode文字データベースのリリースと同時に、RFC 5892で定義されている正確な計算を実行した結果です。 RFC 5892には、例外的な値によって派生が上書きされるコードポイントのリストが記載されています。データファイルの作成時には既知の例外がすべて適用されますが、IDNAプロトコルの今後のアップデートで追加された例外は遡及的に適用されません。
これらのIDNA派生プロパティデータファイルのフォーマットは、RFC 5892の付録B.1で規定されているフォーマットにほぼ準拠していますが、各行のコメントセクションは72列目で切り捨てられません。例えば、RFC 5892からの抜粋を以下に示します。
code:sample
007B..00B6 ; DISALLOWED # LEFT CURLY BRACKET..PILCROW SIGN
00B7 ; CONTEXTO # MIDDLE DOT
00B8..00DE ; DISALLOWED # CEDILLA..LATIN CAPITAL LETTER THORN
00DF..00F6 ; PVALID # LATIN SMALL LETTER SHARP S..LATIN SMALL LETT
データファイルから抽出した同じ範囲を比較します。
code:sample
007B..00B6 ; DISALLOWED # LEFT CURLY BRACKET..PILCROW SIGN
00B7 ; CONTEXTO # MIDDLE DOT
00B8..00DE ; DISALLOWED # CEDILLA..LATIN CAPITAL LETTER THORN
00DF..00F6 ; PVALID # LATIN SMALL LETTER SHARP S..LATIN SMALL LETTER O WITH DIAERESIS
この形式の類似性は、unicode.org に掲載されているこれらの IDNA 派生プロパティ データ ファイルと、IANA またはその他の場所に掲載されている RFC 5892 に基づく既存の計算済みリストとの間で、スクリプトによる比較を簡素化するように設計されています。
謝辞
マーク・デイビスとミシェル・スイニャールは、Unicode技術委員会の指示の下、この文書の原文の大部分を執筆しました。この仕様書へのアイデアやテキストの貢献に対し、編集者はジュリー・アレン、マティティアフ・アルーシュ、ピーター・コンスタブル、クレイグ・カミングス、マーティン・デュルスト、ピーター・エドバーグ、アスムス・フライターク、デボラ・ゴールドスミス、ローレンティウ・イアンク、ジャーベイス・マーカム、サイモン・モンタギュー、リサ・ムーア、エリック・ミュラー、サイモン・サピン、マレー・サージェント、マルクス・シェラー、シン・ジョンシク、アンリ・シヴォネン、ショーン・スティール、エリック・ファン・デル・ポール、クリス・ウェーバー、ケン・ウィスラーに感謝いたします。この仕様は、IETF Idna-updateワーキンググループで開発されたIDNA2008、特にMatitiahu Allouche、Harald Alvestrand、Vint Cerf、Martin J. Dürst、Lisa Dusseault、Patrik Fältström、Paul Hoffman、Cary Karp、John Klensin、およびPeter Resnickの貢献、そしてMarc Blanchet、Adam Costello、Patrik Fältström、およびPaul Hoffmanによって書かれたIDNA2003に基づいています。