IRI
RFC 3987 IRI 国際化されたリソース識別子 基本的にURIと同じ、URIはIRIに含まれる、URIに含まれないものは変換可能。URIはASCII文字などに限定されるので使い分ける必要あり。
Unicode文字をURIにマッピングする方法などを定義
ドメイン以外の部分の国際化表記にも対応している
HTTPではURIを使用するので国際化文字はIRIの仕様でURIに変換してから
RFC 3987
Internationalized Resource Identifiers (IRIs)
このメモのステータス
この文書は、インターネットコミュニティ向けにインターネット標準化過程のプロトコルを規定し、改善のための議論と提案を求めています。このプロトコルの標準化状況とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
1. はじめに
1.1. 概要と目的
Uniform Resource Identifier (URI) は、RFC3986 において、US-ASCII ASCII 文字集合の限定されたサブセットから選択された文字の並びとして定義されています。 URI 内の文字は、自然言語の単語を表すために頻繁に使用されます。この用法には多くの利点があります。例えば、このような URI は、記憶しやすく、解釈しやすく、転写しやすく、作成しやすく、推測しやすいなどです。しかし、英語以外のほとんどの言語では、自然文字として A - Z 以外の文字が使用されています。多くの人にとって、ラテン文字の扱いは、ラテンアルファベットのみを使用する人にとって他の文字の扱いと同じくらい難しいものです。ラテン文字以外の文字を使用する多くの言語は、ラテン文字で転写されています。これらの転写は現在では URI で頻繁に使用されていますが、それによって曖昧さが増すという問題もあります。
ローカルスクリプトの文字を適切に処理するためのインフラストラクチャは、現在、オペレーティングシステムやアプリケーションソフトウェアのローカルバージョンに広く導入されています。多様なスクリプトや言語を同時に処理できるソフトウェアはますます普及しています。また、多様な文字を扱うことができるプロトコルやフォーマットの数も増加しています。
この文書では、URIの構文をより広範な文字範囲に拡張することにより、国際化リソース識別子（IRI）と呼ばれる新しいプロトコル要素を定義します。また、URI参照など、RFC3986の他の構成要素に対応する「国際化」バージョンも定義します。IRIの構文はセクション2で定義され、IRIとURIの関係はセクション3で定義されます。 IRIでAからZ以外の文字を使用すると、いくつかの問題が発生します。セクション4では双方向IRIの特殊なケースについて、セクション5ではIRI間の様々な同等性について、セクション6ではさまざまな状況におけるIRIの使用について説明します。セクション7では追加の参考ガイドラインを示し、セクション8ではセキュリティに関する考慮事項について説明します。
1.2. 適用範囲
IRIは、新しいURIスキームの勧告 RFC2718と互換性を持つように設計されています。この互換性は、IRI文字シーケンスから機能的に同等なURI文字シーケンスへの、明確かつ決定論的なマッピングを規定することによって実現されます。
URI（またはURI参照）の代わりにIRI（またはIRI参照）を実際に使用するには、以下の条件を満たす必要があります。
a. プロトコル要素またはフォーマット要素は、IRIを伝送できることを明示的に指定する必要があります。IRIを受け入れるように定義されていないコンテキストにIRIを導入する意図はありません。例えば、XMLスキーマXML Schemaには、IRIとIRI参照を含む明示的な型「anyURI」があります。したがって、IRIとIRI参照は、「anyURI」型の属性および要素に含めることができます。一方、HTTPプロトコル RFC2616 では、リクエストURIはURIとして定義されているため、HTTPリクエストではIRIを直接使用することはできません。 b. IRIを伝送するプロトコルまたはフォーマットは、IRIで使用される広範囲の文字をネイティブに、またはプロトコルまたはフォーマット固有のエスケープメカニズム（例えば、XMLにおける数値文字参照）によって表現するメカニズムを持つ必要があります。 c. 問題のIRIに対応するURIは、元の文字をUTF-8を使用してオクテットにエンコードする必要があります。新しいURIスキームについては、RFC2718でこれが推奨されています。スキーム全体（例：IMAP URL RFC2192、POP URL RFC2384、URN構文 RFC2141）に適用できます。また、フラグメント識別子（例：XPointer）など、URIの特定の部分に適用することもできます。さらに、特定のURIまたはその一部に適用することもできます。詳細については、セクション6.4を参照してください。 1.3. 定義
文字:character: データの編成、制御、または表現に使用される要素集合の要素。例えば、「LATIN CAPITAL LETTER A」は文字を表します。
オクテット:octet: 8ビットの順序付けられた列を1単位とみなします。
文字レパートリー:character repertoire: 文字の集合（数学的な意味で）。
文字列:sequence of characters: 文字の列（連続する文字）。
オクテット列:sequence of octets: オクテットの列（連続するオクテット）。
文字符号化:character encoding: 文字の列をオクテットの列（場合によっては変形を含む）として表現する方法。また、オクテットの列を文字の列に（明確に）変換する方法。
charset: 文字エンコーディングを識別するために使用されるパラメータまたは属性の名前。
IRI 参照: 国際化リソース識別子 (IRI) の一般的な使用法を示します。IRI 参照は絶対参照または相対参照が可能です。ただし、このような参照から得られる「IRI」には絶対 IRI のみが含まれます。相対 IRI 参照は絶対形式に解決されます。RFC2396 では URI にフラグメント識別子は含まれませんでしたが、RFC3986 ではフラグメント識別子は URI の一部であることに注意してください。 本文:running text: 自然言語の綴り規則に従った構文を持つ人間のテキスト (段落、文、句)。機械による処理を容易にするために定義された構文 (マークアップ、プログラミング言語など) とは異なります。
プロトコル要素:protocol element: 当該プロトコルによるメッセージの処理に影響を与えるメッセージの一部。
プレゼンテーション要素:presentation element: プロトコル要素に対応するプレゼンテーション形式。例えば、より広範囲の文字を使用するなど。
(URI または IRI の) 作成:create (a URI or IRI): URI および IRI に関して、この用語は最初の作成を指します。これは、特定の識別子を持つリソースの最初の作成、または特定の識別子の下でのリソースの最初の公開を指します。
(URI または IRI の) 生成:generate (a URI or IRI): URI および IRI に関して、この用語は、他の情報から派生して IRI が生成される場合に使用されます。
1.4. 表記法
RFCおよびインターネットドラフトでは、現在、US-ASCIIレパートリー外の文字は認められていません。そのため、このドキュメントでは、例においてそのような文字を表すために、様々な特別な表記法を使用しています。
本文中では、US-ASCII外の文字は、接頭辞「U+」に4～6桁の16進数を付けて参照することがあります。
例においてUS-ASCII外の文字を表すために、このドキュメントでは「XML表記法」と「Bidi表記法」という2つの表記法を使用しています。
XML表記法では、先頭に「&#x」、末尾に「;」、そしてその間にUCS内の文字の16進数を記述します。例えば、яはキリル大文字YAを表します。この表記法では、実際の「&」は「&」で表されます。
双方向の例にはBidi表記法が使用されます。小文字はラテン文字など左から右に記述する文字を表し、大文字はアラビア文字やヘブライ文字など右から左に記述する文字を表します。
例の中で実際のオクテットを表すには（パーセントエンコードされたオクテットではなく）、オクテットを表す2つの16進数を「<」と「>」で囲みます。例えば、通常0xc9と表記されるオクテットは、ここでは<c9>と表記します。
この文書では、キーワード「MUST（しなければならない）」、「MUST NOT（してはならない）」、「REQUIRED（必須）」、「SHALL（するものとする）」、「SHALL NOT（しないものとする）」、「SHOULD（すべきである）」、「SHOULD NOT（すべきでない）」、「RECOMMENDED（推奨される）」、「MAY（してもよい）」、および「OPTIONAL（任意）」は、RFC2119で説明されているとおりに解釈されます。 2. IRI 構文
このセクションでは、国際化リソース識別子 (IRI) の構文を定義します。
URI と同様に、IRI はオクテットのシーケンスではなく、文字のシーケンスとして定義されます。この定義は、IRI が紙に書き込まれたり、無線で読み取られたり、デジタル形式で保存または伝送されたりする可能性があるという事実を考慮しています。異なるプロトコルまたは文書が異なる文字エンコーディング (および/または転送エンコーディング) を使用している場合、同じ IRI が異なるオクテットのシーケンスとして表現されることがあります。IRI を含むプロトコルまたは文書と同じ文字エンコーディングを使用することで、IRI 内の文字をプロトコルまたは文書の他の部分と同様に処理 (例: 検索、変換、表示) できるようになります。
2.1. IRI構文の概要
IRIはRFC3986においてURIと同様に定義されていますが、非予約文字のクラスはUCS（Universal Character Set, ISO10646）のU+007Fを超える文字を追加することで拡張されています。ただし、以下の構文規則および6.1節で規定される制限が適用されます。 その他の点では、構文および構成要素と予約文字の使用はRFC3986と同じです。RFC3986で定義されているすべての操作（相対参照の解決など）は、URI処理ソフトウェアがURIに適用するのと全く同じように、IRI処理ソフトウェアによってIRIに適用できます。 US-ASCIIレパートリー外の文字は予約文字ではないため、新しく定義されたスキームにおける構成要素の区切りなど、構文上の目的で使用してはいけません。例えば、U+00A2（CENT SIGN セント記号）は「非予約」'iunreserved' カテゴリに属するため、IRIの区切り文字として使用できません。これは、「-」が「非予約」'unreserved' カテゴリに属するため、URIの区切り文字として使用できないのと同様です。
2.2. IRI参照およびIRIのABNF
IRI参照およびIRIは、URI参照およびURIへの変換のみで定義することも可能ですが、直接受け入れて処理することも可能です。したがって、ここでは、最も一般的な概念であり、文法の出発点となるIRI参照およびIRIのABNF定義を示します。このABNFの構文はRFC2234で記述されています。文字番号はUCSから取得されますが、実際のバイナリエンコーディングは意味しません。ABNFにおける終端文字はバイトではなく文字です。 以下の文法はRFC3986のURI文法に厳密に従っていますが、非予約文字の範囲がUCS文字を含むように拡張されています。ただし、プライベートUCS文字はクエリ部でのみ出現できるという制限があります。文法は2つの部分に分かれています。 上記の拡張によりRFC3986と異なる規則と、RFC3986と同じ規則です。RFC3986と異なる規則については、非終端記号の名称が以下のように変更されています。非終端記号に「URI」が含まれる場合は「IRI」に変更されています。それ以外の場合は「i」が接頭辞として付加されています。 code:ABNF
ihier-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-rootless
/ ipath-empty
IRI-reference = IRI / irelative-ref
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
iuserinfo = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost = IP-literal / IPv4address / ireg-name
ireg-name = *( iunreserved / pct-encoded / sub-delims )
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
ipath-abempty = *( "/" isegment )
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar
isegment-nz = 1*ipchar
isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims
/ "@" )
; non-zero-length segment without any colon ":"
ipchar = iunreserved / pct-encoded / sub-delims / ":"
/ "@"
iquery = *( ipchar / iprivate / "/" / "?" )
ifragment = *( ipchar / "/" / "?" )
iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
いくつかの生成規則は曖昧です。「先着順」（別名「貪欲」）アルゴリズムが適用されます。詳細はRFC3986を参照してください。 code:RFC 3986.ABNF
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
port = *DIGIT
IP-literal = "( IPv6address / IPvFuture ) ""
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ h16 "::" 4( h16 ":" ) ls32 h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "/ "" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
この構文は、IPv6 スコープのアドレス指定ゾーン識別子をサポートしていません。
3. IRIとURIの関係
IRIは、UCSベースの文字レパートリーを使用するプロトコル、フォーマット、およびソフトウェアコンポーネントのリソースを識別する際に、URIの代わりに使用されることを目的としています。これらのプロトコルやコンポーネントは、特にリソース識別子が識別目的のみで使用される場合、URIを直接使用する必要がない場合があります。しかし、リソース識別子がリソースの検索に使用される場合、多くの場合、関連するURIを特定する必要があります。これは、現在ほとんどの検索メカニズムがURIのみを対象としているためです。このような場合、IRIはURIプロトコル要素の表示要素として機能します。例としては、Webユーザーエージェントのアドレスバーが挙げられます。（詳細は3.1節を参照してください。）
3.1. IRIからURIへのマッピング
この節では、IRIをURIにマッピングする方法を定義します。この節の内容はすべて、IRI参照とURI参照、そしてそれらの構成要素（例えば、フラグメント識別子）にも適用されます。
このマッピングには2つの目的があります。
構文的。多くのURIスキームおよびコンポーネントは、セクション2.2で取り上げられていない追加の構文制約を定義しています。
スキーム固有の制約は、IRIをURIに変換し、そのURIをスキーム固有の制約と照合することによってIRIに適用されます。
解釈的。URIは様々な方法でリソースを識別します。IRIもまたリソースを識別します。IRIが識別目的のみで使用される場合、IRIをURIにマッピングする必要はありません（セクション5を参照）。ただし、IRIがリソースの取得に使用される場合、IRIが検索するリソースは、ここで定義される手順に従ってIRIを変換した後に取得されたURIによって検索されるリソースと同じです。つまり、IRIレベルで別途解決を定義する必要はありません。
アプリケーションは、以下の2つの手順を使用してIRIをURIにマッピングする必要があります。
手順1. 元のIRI形式からUCS文字列を生成します。このステップには、入力の形式に応じて以下の3つのバリエーションがあります。
a. IRIが紙に書かれたり、読み上げられたり、あるいは文字エンコーディングに依存しない文字列として表現される場合、IRIを正規化形式C (NFC, UTR15)に従って正規化されたUCSの文字列として表現します。 b. IRIが既知の非Unicode文字エンコーディングによるデジタル表現（例：オクテットストリーム）である場合、IRIをNFCに従って正規化されたUCSの文字シーケンスに変換する。
c. IRIがUnicodeベースの文字エンコーディング（例：UTF-8またはUTF-16）である場合は、正規化を行わない（詳細はセクション5.3.2.2を参照）。エンコードされたUnicode文字シーケンスに手順2を直接適用する。
手順2. 'ucschar'または'iprivate'内の各文字について、以下の手順2.1から2.3を適用する。
2.1. UTF-8 RFC3629を使用して、文字を1つ以上のオクテットのシーケンスに変換する。 2.2. 各オクテットを%HHに変換する。ここで、HHはオクテット値の16進数表記である。これは、RFC3986 のセクション 2.1 にあるパーセントエンコーディングの仕組みと同一であることに注意してください。可変性を減らすため、16 進表記では大文字を使用するべきです。 2.3. 元の文字を結果の文字列（つまり、%HH トリプレットの文字列）に置き換えます。
上記の IRI から URI へのマッピングにより、RFC3986 に完全に準拠した URI が生成されます。このマッピングは URI の恒等変換でもあり、べき等性があります。つまり、このマッピングを再度適用しても何も変わりません。すべての URI は定義上 IRI です。 IRIを受け入れるシステムは、ireg-nameでドメイン名を使用することが知られているスキームにおいて、スキーム定義でireg-nameのパーセントエンコーディングが許可されていない場合、IRIのireg-nameコンポーネントを以下のように変換してもよい（MAY、上記手順2の前）。
IRIのireg-name部分を、RFC3490のセクション4.1で規定されているToASCII操作を用いて変換された部分に置き換え、ラベル区切り文字としてU+002E（ピリオド）を使用し、UseSTD3ASCIIRulesフラグをTRUEに設定し、AllowUnassignedフラグをIRI作成時にはFALSE、それ以外の時にはTRUEに設定する。 ToASCII 操作は失敗する可能性がありますが、これは IRI が解決できないことを意味します。この変換は、従来の URI リゾルバとの相互運用性を最大限に高めることを目的とする場合に使用する必要があります。例えば、IRI
は、
に変換される可能性があります。
ireg-name でドメイン名を使用することが知られているスキームを持つ IRI であっても、スキーム定義で ireg-name のパーセントエンコーディングが許可されていない場合、直接的な変換または ireg-name に対する ToASCII 操作を使用した変換のいずれかによって、スキーム固有の制限を満たす URI が生成されると、スキーム固有の制限を満たします。
このような IRI は、IRI を変換した後に得られる URI に解決され、ireg-name に対して ToASCII 操作が使用されます。実装は、同じ結果を生成する限り、この変換を行う必要はありません。
注: 手順1のバリエーションbとc（NFCによる正規化を使用する場合と、正規化を使用しない場合）の違いは、多くの非Unicode文字エンコーディングでは、一部のテキストを直接表現できないという事実を考慮しています。例えば、「Vietnam」という単語は、NFCではネイティブでは「Vi't Nam」（ラテン小文字のサーキュムフレックス付きEと下点を含む）と表記されますが、Windows 1258文字エンコーディングから直接トランスコードすると「Vi't Nam」（ラテン小文字のサーキュムフレックス付きEと下点を含む）になります。
ベトナム語の他の8ビットエンコーディングから直接トランスコードすると、異なる表現になる場合があります。
注: ステップ2におけるIRI全体の統一的な扱いは、URIスキームに依存しない処理を実現するために重要です。詳細な議論についてはGettysを参照してください。 注: 実際には、IRIからURIへのマッピングと解決が緊密に統合されている場合（例えば、同一のユーザーエージェント内で実行される場合）、ireg-nameに対して一般的なマッピング（手順1および2）が使用されるか、RFC3490のToASCII操作が使用されるかは問題になりません。しかし、HTTPプロキシを使用する場合のように、マッピングと解決が分離されている場合は、RFC3490を使用した変換の方が後方互換性の問題に適切に対処できる可能性があります。 IRIを受け入れるシステムは、上記の手順2において、URIでは許可されていないUS-ASCIIの印字可能文字（「<」、「>」、「'"」、「スペース」、「{」、「}」、「|」、「\」、「^」、「`」）も処理してもよい（MAY）。これらの文字が見つかったが変換されていない場合、変換は失敗するべきである（SHOULD）。ただし、番号記号（「#」）、パーセント記号（「%」）、および角括弧文字（「"」、「」）は上記のリストに含まれておらず、変換してはならない（MUST NOT）ことに留意してください。これらの文字を含む以前のIRI定義を使用しているプロトコルおよびフォーマットでは、特定のフィールドから実際のIRIを抽出するための前処理として、これらの文字のパーセントエンコードが必要となる場合がある（MAY）。この前処理は、ユーザーがIRIを入力できるようにするアプリケーションでも使用される場合がある（MAY）。 注: 一部の古いソフトウェアで UTF-8 にトランスコードすると、特に BMP (基本多言語面) 以外の文字に対して、一部の入力に対して不正な出力が生成される可能性があります。例えば、BMP 以外の文字を含む IRI (XML 表記) の場合、次のようになります。
3.2. URIからIRIへの変換
状況によっては、URIを同等のIRIに変換することが望ましい場合があります。このセクションでは、この変換の手順を説明します。このセクションで説明する変換では、変換の入力として使用したURIにマッピングされるIRIが常に生成されます（パーセントエンコードにおける大文字と小文字の区別、およびパーセントエンコードされた非予約文字の可能性を除く）。ただし、この変換によって生成されるIRIは、元のIRI（もしあったとしても）と完全に同じではない場合があります。
URIからIRIへの変換ではパーセントエンコードは削除されますが、すべてのパーセントエンコードを削除できるわけではありません。これにはいくつかの理由があります。
1. 一部のパーセントエンコードは、パーセントエンコードされた予約文字とエンコードされていない予約文字を区別するために必要です。
2. 一部のパーセントエンコードは、UTF-8オクテットのシーケンスとして解釈できません。
（注：UTF-8のオクテットパターンは非常に規則的です。そのため、UTF-8オクテットのシーケンスとして解釈できるパーセントエンコーディングが、実際にはUTF-8に由来する可能性は非常に高いですが、保証はありません。詳細な議論については、Duerst97を参照してください。） 3. 変換の結果、IRIに適さない文字が生成される場合があります。詳細については、セクション2.2、4.1、および6.1を参照してください。
URIからIRIへの変換は、以下の手順（または同じ結果を生成する他のアルゴリズム）を使用して行われます。
1. URIをUS-ASCIIのオクテットのシーケンスとして表現します。
2. すべてのパーセントエンコーディング（「%」の後に2桁の16進数が続く）を、対応するオクテットに変換します。ただし、「%」に対応するオクテット、「予約語」に含まれる文字、およびURIで許可されていないUS-ASCIIの文字は除きます。
3. 手順2で生成されたオクテットのうち、厳密に正しいUTF-8オクテットシーケンスに含まれないオクテットを、再度パーセントエンコードします。
4. 手順3で生成されたUTF-8のオクテットのうち、セクション2.2、4.1、および6.1に従って適切ではない文字を表すすべてのオクテットを、再度パーセントエンコードする。
5. 結果のオクテットシーケンスをUTF-8でエンコードされた文字列として解釈する。
この手順により、可能な限り多くのパーセントエンコードされた文字がIRI内の文字に変換される。手順4を適用する際にはいくつかの選択肢があるため（セクション6.1を参照）、結果は異なる可能性がある。
3.2.1. 例
このセクションでは、URIをIRIに変換する様々な例を示します。各例は、手順1から5までを適用した後の結果を示しています。最終的な結果にはXML表記法が使用されます。オクテットは、「<」、2桁の16進数、そして「>」で表されます。
次の例には、UTF-8で厳密に有効なシーケンス「%C3%BC」が含まれており、これは実際の文字U+00FC（分音記号付きラテン小文字U、ウムラウトとも呼ばれる）に変換されます。
次の例には、シーケンス「%FC」が含まれており、これはISO-8859-1文字エンコーディングではU+00FC（分音記号付きラテン小文字U）を表す可能性があります。 （他の文字エンコーディングでは、他の文字を表す場合があります。例えば、ISO-8859-5 のオクテット <fc> は U+045C（キリル小文字 KJE）を表します。）<fc> は厳密に有効な UTF-8 シーケンスの一部ではないため、手順 3 で再パーセントエンコードされます。
次の例には、UTF-8 文字エンコーディングで U+202E（右から左へのオーバーライド）をパーセントエンコードした「%e2%80%ae」が含まれています。
セクション4.1では、この文字をIRIに直接使用することは禁止されています。
したがって、対応するオクテットは手順4で再パーセントエンコードされます。
この例は、パーセントエンコードで使用される文字の大文字と小文字の区別が保持されない可能性があることを示しています。また、この例にはPunycodeエンコードされたドメイン名ラベル（xn--99zt52a）が含まれていますが、これは変換されません。