[要約] RFC 3987は、国際化されたリソース識別子（IRI）の標準仕様であり、URLやURIの拡張として使用されます。その目的は、非ASCII文字やUnicode文字を含む国際的なリソースを一意に識別するための方法を提供することです。
Network Working Group M. Duerst
Request for Comments: 3987 W3C
Category: Standards Track M. Suignard
Microsoft Corporation
January 2005
Internationalized Resource Identifiers (IRIs)
国際化されたリソース識別子（IRIS）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.
このドキュメントでは、均一なリソース識別子（URI）の補完として、新しいプロトコル要素である国際化されたリソース識別子（IRI）を定義しています。IRIは、ユニバーサル文字セット（Unicode/ISO 10646）の文字のシーケンスです。IRISからURISへのマッピングが定義されています。つまり、リソースを特定するために、必要に応じてURIの代わりにIRISを使用できます。
The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.
URIの定義を拡張または変更する代わりに、新しいプロトコル要素を定義するアプローチが選択されました。これは、明確な区別を可能にし、既存のソフトウェアとの互換性を回避するために行われました。現在URIを扱っているさまざまなプロトコル、形式、およびソフトウェアコンポーネントでのIRISの使用と展開に関するガイドラインが提供されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview and Motivation . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . 3
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. IRI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Summary of IRI Syntax . . . . . . . . . . . . . . . . . 6
2.2. ABNF for IRI References and IRIs . . . . . . . . . . . . 7
3. Relationship between IRIs and URIs . . . . . . . . . . . . . . 10
3.1. Mapping of IRIs to URIs . . . . . . . . . . . . . . . . 10
3.2. Converting URIs to IRIs . . . . . . . . . . . . . . . . 14
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . 15
4. Bidirectional IRIs for Right-to-Left Languages. . . . . . . . 16
4.1. Logical Storage and Visual Presentation . . . . . . . . 17
4.2. Bidi IRI Structure . . . . . . . . . . . . . . . . . . . 18
4.3. Input of Bidi IRIs . . . . . . . . . . . . . . . . . . . 19
4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Normalization and Comparison . . . . . . . . . . . . . . . . . 21
5.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Preparation for Comparison . . . . . . . . . . . . . . . 22
5.3. Comparison Ladder . . . . . . . . . . . . . . . . . . . 23
5.3.1. Simple String Comparison . . . . . . . . . . . . 23
5.3.2. Syntax-Based Normalization . . . . . . . . . . . 24
5.3.3. Scheme-Based Normalization . . . . . . . . . . . 27
5.3.4. Protocol-Based Normalization . . . . . . . . . . 28
6. Use of IRIs . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Limitations on UCS Characters Allowed in IRIs . . . . . 29
6.2. Software Interfaces and Protocols . . . . . . . . . . . 29
6.3. Format of URIs and IRIs in Documents and Protocols . . . 30
6.4. Use of UTF-8 for Encoding Original Characters .. . . . . 30
6.5. Relative IRI References . . . . . . . . . . . . . . . . 32
7. URI/IRI Processing Guidelines (informative) . . . . . . . . . 32
7.1. URI/IRI Software Interfaces . . . . . . . . . . . . . . 32
7.2. URI/IRI Entry . . . . . . . . . . . . . . . . . . . . . 33
7.3. URI/IRI Transfer between Applications . . . . . . . . . 33
7.4. URI/IRI Generation . . . . . . . . . . . . . . . . . . . 34
7.5. URI/IRI Selection . . . . . . . . . . . . . . . . . . . 34
7.6. Display of URIs/IRIs . . . . . . . . . . . . . . . . . . 35
7.7. Interpretation of URIs and IRIs . . . . . . . . . . . . 36
7.8. Upgrading Strategy . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41
A. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 44
A.1. New Scheme(s) . . . . . . . . . . . . . . . . . . . . . 44
A.2. Character Encodings Other Than UTF-8 . . . . . . . . . . 44
A.3. New Encoding Convention . . . . . . . . . . . . . . . . 44
A.4. Indicating Character Encodings in the URI/IRI . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
A Uniform Resource Identifier (URI) is defined in [RFC3986] as a sequence of characters chosen from a limited subset of the repertoire of US-ASCII [ASCII] characters.
均一なリソース識別子（URI）は、[RFC3986]で、US-ASCII [ASCII]文字のレパートリーの限られたサブセットから選択された一連の文字として定義されています。
The characters in URIs are frequently used for representing words of natural languages. This usage has many advantages: Such URIs are easier to memorize, easier to interpret, easier to transcribe, easier to create, and easier to guess. For most languages other than English, however, the natural script uses characters other than A - Z. For many people, handling Latin characters is as difficult as handling the characters of other scripts is for those who use only the Latin alphabet. Many languages with non-Latin scripts are transcribed with Latin letters. These transcriptions are now often used in URIs, but they introduce additional ambiguities.
URIのキャラクターは、自然言語の言葉を表すために頻繁に使用されます。この使用法には多くの利点があります。そのようなURIは、覚えやすく、解釈が簡単で、転写が簡単で、作成しやすく、推測しやすいです。ただし、英語以外のほとんどの言語では、Natural ScriptはA -Z以外の文字を使用します。多くの人にとって、ラテン文字を処理することは、他のスクリプトの文字を処理するのと同じくらい難しいのは、ラテン語のアルファベットのみを使用する人向けです。ラチン以外のスクリプトを持つ多くの言語は、ラテン文字で転写されています。これらの転写は現在、URIでよく使用されていますが、追加のあいまいさを導入します。
The infrastructure for the appropriate handling of characters from local scripts is now widely deployed in local versions of operating system and application software. Software that can handle a wide variety of scripts and languages at the same time is increasingly common. Also, increasing numbers of protocols and formats can carry a wide range of characters.
ローカルスクリプトからの文字を適切に処理するためのインフラストラクチャは、オペレーティングシステムとアプリケーションソフトウェアのローカルバージョンに広く展開されています。さまざまなスクリプトと言語を同時に処理できるソフトウェアはますます一般的になります。また、プロトコルと形式の数を増やすと、幅広い文字が搭載されます。
This document defines a new protocol element called Internationalized Resource Identifier (IRI) by extending the syntax of URIs to a much wider repertoire of characters. It also defines "internationalized" versions corresponding to other constructs from [RFC3986], such as URI references. The syntax of IRIs is defined in section 2, and the relationship between IRIs and URIs in section 3.
このドキュメントでは、URIの構文をより広い文字のレパートリーに拡張することにより、国際化されたリソース識別子（IRI）と呼ばれる新しいプロトコル要素を定義します。また、URI参照など、[RFC3986]の他の構成要素に対応する「国際化された」バージョンも定義します。IRISの構文は、セクション2で定義されており、IRISとURISの関係はセクション3で定義されています。
Using characters outside of A - Z in IRIs brings some difficulties. Section 4 discusses the special case of bidirectional IRIs, section 5 various forms of equivalence between IRIs, and section 6 the use of IRIs in different situations. Section 7 gives additional informative guidelines, and section 8 security considerations.
虹彩のA -Z以外の文字を使用すると、いくつかの困難がもたらされます。セクション4では、双方向虹彩の特別なケース、セクション5虹彩間のさまざまな形式の同等性、およびセクション6のさまざまな状況での虹彩の使用について説明します。セクション7では、追加の有益なガイドラインとセクション8のセキュリティに関する考慮事項を示します。
IRIs are designed to be compatible with recommendations for new URI schemes [RFC2718]. The compatibility is provided by specifying a well-defined and deterministic mapping from the IRI character sequence to the functionally equivalent URI character sequence. Practical use of IRIs (or IRI references) in place of URIs (or URI references) depends on the following conditions being met: a. A protocol or format element should be explicitly designated to be able to carry IRIs. The intent is not to introduce IRIs into contexts that are not defined to accept them. For example, XML schema [XMLSchema] has an explicit type "anyURI" that includes IRIs and IRI references. Therefore, IRIs and IRI references can be in attributes and elements of type "anyURI". On the other hand, in the HTTP protocol [RFC2616], the Request URI is defined as a URI, which means that direct use of IRIs is not allowed in HTTP requests.
IRISは、新しいURIスキーム[RFC2718]の推奨事項と互換性があるように設計されています。互換性は、IRI文字シーケンスから機能的に同等のURI文字シーケンスへの明確に定義された決定論的マッピングを指定することにより提供されます。URI（またはURI参照）の代わりにIRI（またはIRI参照）の実際の使用は、次の条件に依存します。プロトコルまたはフォーマット要素は、虹彩を運ぶことができるように明示的に指定する必要があります。意図は、それらを受け入れるように定義されていないコンテキストに虹彩を導入することではありません。たとえば、XMLスキーマ[XMLSchema]には、IRISおよびIRIの参照を含む明示的なタイプ「Anyuri」があります。したがって、IRISおよびIRIの参照は、タイプ「Anyuri」の属性と要素に含まれる場合があります。一方、HTTPプロトコル[RFC2616]では、Request URIはURIとして定義されています。つまり、HTTPリクエストではIRISの直接使用は許可されていません。
b. The protocol or format carrying the IRIs should have a mechanism to represent the wide range of characters used in IRIs, either natively or by some protocol- or format-specific escaping mechanism (for example, numeric character references in [XML1]).
b. IRISを運ぶプロトコルまたはフォーマットには、ネイティブまたは一部のプロトコルまたは形式固有の脱出メカニズム（[XML1]の数値文字参照）のいずれかで、虹彩で使用される幅広い文字を表すメカニズムを備えている必要があります。
c. The URI corresponding to the IRI in question has to encode original characters into octets using UTF-8. For new URI schemes, this is recommended in [RFC2718]. It can apply to a whole scheme (e.g., IMAP URLs [RFC2192] and POP URLs [RFC2384], or the URN syntax [RFC2141]). It can apply to a specific part of a URI, such as the fragment identifier (e.g., [XPointer]). It can apply to a specific URI or part(s) thereof. For details, please see section 6.4.
c. 問題のIRIに対応するURIは、UTF-8を使用して元の文字をオクテットにエンコードする必要があります。新しいURIスキームの場合、これは[RFC2718]で推奨されます。スキーム全体（例：IMAP URL [RFC2192]およびPOP URLS [RFC2384]、またはURN構文[RFC2141]）に適用できます。フラグメント識別子（[xpointer]など）など、URIの特定の部分に適用できます。特定のURIまたはその一部に適用できます。詳細については、セクション6.4を参照してください。
The following definitions are used in this document; they follow the terms in [RFC2130], [RFC2277], and [ISO10646].
このドキュメントでは、次の定義が使用されています。それらは、[RFC2130]、[RFC2277]、および[ISO10646]の用語に従います。
character: A member of a set of elements used for the organization, control, or representation of data. For example, "LATIN CAPITAL LETTER A" names a character.
文字：組織、制御、またはデータの表現に使用される一連の要素のメンバー。たとえば、「ラテン語の大文字a」というキャラクターと名付けられています。
octet: An ordered sequence of eight bits considered as a unit.
Octet：ユニットと見なされる8ビットの順序付けられたシーケンス。
character repertoire: A set of characters (in the mathematical sense).
文字レパートリー：文字のセット（数学的な意味で）。
sequence of characters: A sequence of characters (one after another).
文字のシーケンス：文字のシーケンス（次々）。
sequence of octets: A sequence of octets (one after another).
オクテットのシーケンス：オクテットのシーケンス（次々）。
character encoding: A method of representing a sequence of characters as a sequence of octets (maybe with variants). Also, a method of (unambiguously) converting a sequence of octets into a sequence of characters.
文字エンコーディング：一連の文字をオクテットのシーケンスとして表す方法（多分バリアント付き）。また、一連のオクテットを一連の文字に変換する（明確に）（明確に）変換する方法。
charset: The name of a parameter or attribute used to identify a character encoding.
charset：文字エンコードの識別に使用されるパラメーターまたは属性の名前。
UCS: Universal Character Set. The coded character set defined by ISO/IEC 10646 [ISO10646] and the Unicode Standard [UNIV4].
UCS：ユニバーサル文字セット。ISO/IEC 10646 [ISO10646]およびUnicode標準[UNIV4]で定義されたコード化された文字セット。
IRI reference: Denotes the common usage of an Internationalized Resource Identifier. An IRI reference may be absolute or relative. However, the "IRI" that results from such a reference only includes absolute IRIs; any relative IRI references are resolved to their absolute form. Note that in [RFC2396] URIs did not include fragment identifiers, but in [RFC3986] fragment identifiers are part of URIs.
IRIリファレンス：国際化されたリソース識別子の一般的な使用法を示します。IRIの参照は、絶対的または相対的なものである場合があります。ただし、このような参照から生じる「IRI」には、絶対虹彩のみが含まれます。相対的なIRI参照は、それらの絶対形式に解決されます。[RFC2396]では、URIにはフラグメント識別子が含まれていなかったが、[RFC3986]にはフラグメント識別子がURISの一部であることに注意してください。
running text: Human text (paragraphs, sentences, phrases) with syntax according to orthographic conventions of a natural language, as opposed to syntax defined for ease of processing by machines (e.g., markup, programming languages).
ランニングテキスト：機械による処理の容易さ（マークアップ、プログラミング言語）のために定義された構文とは対照的に、自然言語の正書法の慣習に従って構文を使用した人間のテキスト（段落、文、フレーズ）。
protocol element: Any portion of a message that affects processing of that message by the protocol in question.
プロトコル要素：問題のプロトコルによるそのメッセージの処理に影響するメッセージの任意の部分。
presentation element: A presentation form corresponding to a protocol element; for example, using a wider range of characters.
プレゼンテーション要素：プロトコル要素に対応するプレゼンテーションフォーム。たとえば、より広い範囲の文字を使用します。
create (a URI or IRI): With respect to URIs and IRIs, the term is used for the initial creation. This may be the initial creation of a resource with a certain identifier, or the initial exposition of a resource under a particular identifier.
Create（URIまたはIRI）：URISおよびIRISに関して、この用語は最初の作成に使用されます。これは、特定の識別子を備えたリソースの初期作成、または特定の識別子の下でのリソースの初期博覧会です。
generate (a URI or IRI): With respect to URIs and IRIs, the term is used when the IRI is generated by derivation from other information.
Generate（URIまたはIRI）：URISおよびIRISに関して、IRIが他の情報から派生して生成されると、この用語が使用されます。
RFCs and Internet Drafts currently do not allow any characters outside the US-ASCII repertoire. Therefore, this document uses various special notations to denote such characters in examples.
RFCとインターネットドラフトは現在、米国ASCIIレパートリー以外のキャラクターを許可していません。したがって、このドキュメントでは、さまざまな特別表記を使用して、そのような文字を例で示します。
In text, characters outside US-ASCII are sometimes referenced by using a prefix of 'U+', followed by four to six hexadecimal digits.
テキストでは、us-asciiの外側の文字は、「u」のプレフィックスを使用して4〜6匹の16進数桁を使用して参照されることがあります。
To represent characters outside US-ASCII in examples, this document uses two notations: 'XML Notation' and 'Bidi Notation'.
例では、us-ascii以外の文字を表すために、このドキュメントでは、「xml notation」と「bidi notation」という2つの表記を使用します。
XML Notation uses a leading '&#x', a trailing ';', and the hexadecimal number of the character in the UCS in between. For example, я stands for CYRILLIC CAPITAL LETTER YA. In this notation, an actual '&' is denoted by '&'.
XML表記は、その間のUCSの主要な '＆＃x'、Trailing ';'、およびChexadecimal数を使用します。たとえば、＆＃x44f;キリル語の大文字Yaの略です。この表記では、実際の「＆」は「＆amp;」によって示されます。
Bidi Notation is used for bidirectional examples: Lowercase letters stand for Latin letters or other letters that are written left to right, whereas uppercase letters represent Arabic or Hebrew letters that are written right to left.
Bidi Notationは双方向の例に使用されます：小文字の文字は、ラテン文字または左から右に書かれた他の文字を表しますが、大文字は左から左に書かれたアラビア語またはヘブライ語の文字を表しています。
To denote actual octets in examples (as opposed to percent-encoded octets), the two hex digits denoting the octet are enclosed in "<" and ">". For example, the octet often denoted as 0xc9 is denoted here as <c9>.
例で実際のオクテットを示すために（エンコードされたオクテットとは対照的に）、オクテットを示す2つの16進数は「<」と「>」に囲まれています。たとえば、0xc9として示されるオクテットは、ここで<c9>として示されることがよくあります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"[RFC2119]に記載されているように解釈されます。
This section defines the syntax of Internationalized Resource Identifiers (IRIs).
このセクションでは、国際化されたリソース識別子（IRIS）の構文を定義します。
As with URIs, an IRI is defined as a sequence of characters, not as a sequence of octets. This definition accommodates the fact that IRIs may be written on paper or read over the radio as well as stored or transmitted digitally. The same IRI may be represented as different sequences of octets in different protocols or documents if these protocols or documents use different character encodings (and/or transfer encodings). Using the same character encoding as the containing protocol or document ensures that the characters in the IRI can be handled (e.g., searched, converted, displayed) in the same way as the rest of the protocol or document.
URISと同様に、IRIはオクテットのシーケンスとしてではなく、一連の文字として定義されます。この定義は、IRISを紙に書いたり、ラジオで読んだり、デジタルに保管または送信したりする可能性があるという事実に対応しています。これらのプロトコルまたはドキュメントが異なる文字エンコーディング（および/または転送エンコーディング）を使用している場合、同じIRIが異なるプロトコルまたはドキュメントのオクテットの異なるシーケンスとして表される場合があります。含有プロトコルまたはドキュメントと同じ文字エンコードを使用すると、IRIの文字を他のプロトコルまたはドキュメントと同じ方法で処理（検索、変換、表示）が保証します。
IRIs are defined similarly to URIs in [RFC3986], but the class of unreserved characters is extended by adding the characters of the UCS (Universal Character Set, [ISO10646]) beyond U+007F, subject to the limitations given in the syntax rules below and in section 6.1.
虹彩は[RFC3986]のURIと同様に定義されていますが、UCSの文字（ユニバーサル文字セット、[ISO10646]）のキャラクターをU 007Fを超えて追加することにより、予約されていない文字のクラスは拡張されます。セクション6.1で。
Otherwise, the syntax and use of components and reserved characters is the same as that in [RFC3986]. All the operations defined in [RFC3986], such as the resolution of relative references, can be applied to IRIs by IRI-processing software in exactly the same way as they are for URIs by URI-processing software.
それ以外の場合、コンポーネントと予約文字の構文と使用は[RFC3986]の構文と同じです。[RFC3986]で定義されているすべての操作は、相対的な参照の解像度など、URI処理ソフトウェアとまったく同じ方法でIRI処理ソフトウェアによってIRISによってIRISに適用できます。
Characters outside the US-ASCII repertoire are not reserved and therefore MUST NOT be used for syntactical purposes, such as to delimit components in newly defined schemes. For example, U+00A2, CENT SIGN, is not allowed as a delimiter in IRIs, because it is in the 'iunreserved' category. This is similar to the fact that it is not possible to use '-' as a delimiter in URIs, because it is in the 'unreserved' category.
米国ASCIIレパートリー以外のキャラクターは予約されていないため、新たに定義されたスキームでコンポーネントを区切るなどの構文目的に使用してはなりません。たとえば、U 00A2、Cent Signは、「iunreserved」カテゴリにあるため、虹彩の区切り文字として許可されていません。これは、「未控えめな」カテゴリにあるため、「 - 」をウリの区切り文字として使用することができないという事実に似ています。
Although it might be possible to define IRI references and IRIs merely by their transformation to URI references and URIs, they can also be accepted and processed directly. Therefore, an ABNF definition for IRI references (which are the most general concept and the start of the grammar) and IRIs is given here. The syntax of this ABNF is described in [RFC2234]. Character numbers are taken from the UCS, without implying any actual binary encoding. Terminals in the ABNF are characters, not bytes.
URI参照とURIへの変換だけでIRI参照とIRIを定義することは可能かもしれませんが、それらを直接受け入れて処理することもできます。したがって、IRI参照のABNF定義（これは最も一般的な概念であり、文法の開始）とIRIがここに示されています。このABNFの構文は[RFC2234]で説明されています。文字番号は、実際のバイナリエンコーディングを暗示することなく、UCSから取得されます。ABNFの端子は文字であり、バイトではありません。
The following grammar closely follows the URI grammar in [RFC3986], except that the range of unreserved characters is expanded to include UCS characters, with the restriction that private UCS characters can occur only in query parts. The grammar is split into two parts: Rules that differ from [RFC3986] because of the above-mentioned expansion, and rules that are the same as those in [RFC3986]. For rules that are different than those in [RFC3986], the names of the non-terminals have been changed as follows. If the non-terminal contains 'URI', this has been changed to 'IRI'. Otherwise, an 'i' has been prefixed.
次の文法は、[RFC3986]のURI文法に密接に続きますが、予約されていない文字の範囲がUCS文字を含むように拡張されており、プライベートUCS文字がクエリパーツでのみ発生できるという制限があります。文法は、上記の拡張のために[RFC3986]とは異なるルールと[RFC3986]のルールと同じ2つの部分に分割されます。[RFC3986]のルールとは異なるルールの場合、非端子の名前は次のように変更されています。非末端に「URI」が含まれている場合、これは「IRI」に変更されました。それ以外の場合は、「I」がプレフィックスされています。
The following rules are different from those in [RFC3986]:
次のルールは、[RFC3986]のルールとは異なります。
IRI = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]
IRI = Scheme "：" ihier-part ["？"iquery] ["＃" ifragment]
ihier-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-rootless
/ ipath-empty
IRI-reference = IRI / irelative-ref
absolute-IRI = scheme ":" ihier-part [ "?" iquery ]
absolute-iri = scheme "：" ihier-part ["？"iquery]
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
IRELATIVE-REF = IRELETIVE-PART ["？"iquery] ["＃" ifragment]
irelative-part = "//" iauthority ipath-abempty / ipath-absolute
IRELATIVE-PART = "//" iAuthority ipath-abempty/ipath-absolute
/ ipath-noscheme / ipath-empty
/ ipath-noscheme / ipath-empty
iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
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-absolute = "/" [ isegment-nz *( "/" 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
Some productions are ambiguous. The "first-match-wins" (a.k.a. "greedy") algorithm applies. For details, see [RFC3986].
一部の作品は曖昧です。「ファーストマッチウィン」（別名「貪欲」）アルゴリズムが適用されます。詳細については、[RFC3986]を参照してください。
The following rules are the same as those in [RFC3986]:
次のルールは[RFC3986]のルールと同じです。
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
ip-literal = "["（ipv6address / ipvfuture） "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
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
pct-encoded = "％" hexdig hexdig
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
This syntax does not support IPv6 scoped addressing zone identifiers.
この構文は、IPv6スコープアドレス指定ゾーン識別子をサポートしていません。
IRIs are meant to replace URIs in identifying resources for protocols, formats, and software components that use a UCS-based character repertoire. These protocols and components may never need to use URIs directly, especially when the resource identifier is used simply for identification purposes. However, when the resource identifier is used for resource retrieval, it is in many cases necessary to determine the associated URI, because currently most retrieval mechanisms are only defined for URIs. In this case, IRIs can serve as presentation elements for URI protocol elements. An example would be an address bar in a Web user agent. (Additional rationale is given in section 3.1.)
IRISは、UCSベースの文字レパートリーを使用するプロトコル、フォーマット、およびソフトウェアコンポーネントのリソースを特定する際にURIを置き換えることを目的としています。これらのプロトコルとコンポーネントは、特にリソース識別子が単に識別目的で使用される場合、URIを直接使用する必要はない場合があります。ただし、リソース識別子がリソースの検索に使用される場合、現在のほとんどの検索メカニズムはURIに対してのみ定義されているため、関連するURIを決定する必要があります。この場合、IRISはURIプロトコル要素のプレゼンテーション要素として機能します。例は、Webユーザーエージェントのアドレスバーです。（追加の根拠はセクション3.1に記載されています。）
This section defines how to map an IRI to a URI. Everything in this section also applies to IRI references and URI references, as well as to components thereof (for example, fragment identifiers).
このセクションでは、IRIをURIにマッピングする方法を定義します。このセクションのすべては、IRI参照とURI参照、およびそのコンポーネント（たとえば、フラグメント識別子）にも適用されます。
This mapping has two purposes:
このマッピングには2つの目的があります。
Syntaxical. Many URI schemes and components define additional syntactical restrictions not captured in section 2.2. Scheme-specific restrictions are applied to IRIs by converting IRIs to URIs and checking the URIs against the scheme-specific restrictions.
構文。多くのURIスキームとコンポーネントは、セクション2.2でキャプチャされていない追加の構文制限を定義しています。スキーム固有の制限は、IRISをURISに変換し、スキーム固有の制限に対してURIを確認することにより、IRISに適用されます。
Interpretational. URIs identify resources in various ways. IRIs also identify resources. When the IRI is used solely for identification purposes, it is not necessary to map the IRI to a URI (see section 5). However, when an IRI is used for resource retrieval, the resource that the IRI locates is the same as the one located by the URI obtained after converting the IRI according to the procedure defined here. This means that there is no need to define resolution separately on the IRI level.
解釈。urisはさまざまな方法でリソースを識別します。アイリスもリソースを特定します。IRIが識別目的でのみ使用される場合、IRIをURIにマッピングする必要はありません（セクション5を参照）。ただし、IRIがリソースの取得に使用される場合、IRIが見つけるリソースは、ここで定義されている手順に従ってIRIを変換した後に得られたURIによって見つかったリソースと同じです。これは、IRIレベルで解像度を個別に定義する必要がないことを意味します。
Applications MUST map IRIs to URIs by using the following two steps.
アプリケーションは、次の2つの手順を使用して、IRISをURISにマッピングする必要があります。
Step 1. Generate a UCS character sequence from the original IRI format. This step has the following three variants, depending on the form of the input:
ステップ1.元のIRI形式からUCS文字シーケンスを生成します。このステップには、入力の形式に応じて、次の3つのバリアントがあります。
a. If the IRI is written on paper, read aloud, or otherwise represented as a sequence of characters independent of any character encoding, represent the IRI as a sequence of characters from the UCS normalized according to Normalization Form C (NFC, [UTR15]).
a. IRIが紙に書かれている場合、声を出して読み取るか、または任意の文字エンコーディングとは独立した文字のシーケンスとして表された場合、IRIを正規化フォームC（NFC、[UTR15]）に従って正規化されたUCSの文字のシーケンスとして表します。
b. If the IRI is in some digital representation (e.g., an octet stream) in some known non-Unicode character encoding, convert the IRI to a sequence of characters from the UCS normalized according to NFC.
b. IRIがいくつかのデジタル表現（例えば、オクテットストリーム）に既知の非ユニコード文字エンコードにある場合、IRIをNFCに従って正規化されたUCSの文字のシーケンスに変換します。
c. If the IRI is in a Unicode-based character encoding (for example, UTF-8 or UTF-16), do not normalize (see section 5.3.2.2 for details). Apply step 2 directly to the encoded Unicode character sequence.
c. IRIがユニコードベースの文字エンコード（UTF-8やUTF-16など）にある場合、正規化しないでください（詳細については、セクション5.3.2.2を参照）。エンコードされたユニコード文字シーケンスにステップ2を直接適用します。
Step 2. For each character in 'ucschar' or 'iprivate', apply steps 2.1 through 2.3 below.
ステップ2.「ucschar」または「iprivate」の各文字について、以下の手順2.1から2.3を適用します。
2.1. Convert the character to a sequence of one or more octets using UTF-8 [RFC3629].
2.1. UTF-8 [RFC3629]を使用して、文字を1つ以上のオクテットのシーケンスに変換します。
2.2. Convert each octet to %HH, where HH is the hexadecimal notation of the octet value. Note that this is identical to the percent-encoding mechanism in section 2.1 of [RFC3986]. To reduce variability, the hexadecimal notation SHOULD use uppercase letters.
2.2. 各オクテットを％HHに変換します。ここで、HHはオクテット値の16進表です。これは、[RFC3986]のセクション2.1のパーセントエンコードメカニズムと同一であることに注意してください。変動性を低下させるために、16進表記は大文字を使用する必要があります。
2.3. Replace the original character with the resulting character sequence (i.e., a sequence of %HH triplets).
2.3. 元の文字を、結果の文字シーケンス（つまり、％HHトリプレットのシーケンス）に置き換えます。
The above mapping from IRIs to URIs produces URIs fully conforming to [RFC3986]. The mapping is also an identity transformation for URIs and is idempotent; applying the mapping a second time will not change anything. Every URI is by definition an IRI.
虹彩からURISへの上記のマッピングは、[RFC3986]に完全に適合しているURIを生成します。マッピングは、URIのアイデンティティ変換でもあり、iDempotentです。マッピングをもう一度適用しても、何も変更されません。すべてのURIは定義上IRIです。
Systems accepting IRIs MAY convert the ireg-name component of an IRI as follows (before step 2 above) for schemes known to use domain names in ireg-name, if the scheme definition does not allow percent-encoding for ireg-name:
IRISを受け入れるシステムは、スキーム定義がIREG-NAMEのパーセントエンコードを許可しない場合、IREG-NAMEでドメイン名を使用することが知られているスキームについて、次のように（上記のステップ2以前）IRIのIREG名コンポーネントを変換することができます。
Replace the ireg-name part of the IRI by the part converted using the ToASCII operation specified in section 4.1 of [RFC3490] on each dot-separated label, and by using U+002E (FULL STOP) as a label separator, with the flag UseSTD3ASCIIRules set to TRUE, and with the flag AllowUnassigned set to FALSE for creating IRIs and set to TRUE otherwise.
IRIのIREG-NAME部分を、各ドット分離ラベルの[RFC3490]のセクション4.1で指定されたToascii操作を使用して変換された部品に置き換え、ラベルセパレーターとしてU 002E（フルストップ）を使用して、フラグのUSESTD3ASCIIRULESを使用して使用します。trueに設定し、フラグを使用すると、虹彩を作成するためにfalseにaspoldassignedセットを使用して、それ以外の場合はtrueに設定します。
The ToASCII operation may fail, but this would mean that the IRI cannot be resolved. This conversion SHOULD be used when the goal is to maximize interoperability with legacy URI resolvers. For example, the IRI
Toascii操作は失敗する可能性がありますが、これはIRIを解決できないことを意味します。この変換は、レガシーURIリゾルバーとの相互運用性を最大化するための目標である場合に使用する必要があります。たとえば、IRI
"http://résumé.example.org"
may be converted to
に変換される場合があります
"http://xn--rsum-bpad.example.org"
「http://xn ---rsum-bpad.example.org」
instead of
の代わりに代りに代わりにせずに立代って
"http://r%C3%A9sum%C3%A9.example.org".
"http：//r%C3%A9Sum%C3%A9.example.org"」。
An IRI with a scheme that is known to use domain names in ireg-name, but where the scheme definition does not allow percent-encoding for ireg-name, meets scheme-specific restrictions if either the straightforward conversion or the conversion using the ToASCII operation on ireg-name result in an URI that meets the scheme-specific restrictions.
IREG名でドメイン名を使用することが知られているが、スキーム定義がIREG-NAMEのパーセントエンコードを許可しない場合、IREGNAMEのパーセントエンコードを持たないIRIは、THOASCII操作を使用した単純な変換または変換のいずれかでスキーム固有の制限を満たしますIREG-NAMEの結果、スキーム固有の制限を満たすURIが発生します。
Such an IRI resolves to the URI obtained after converting the IRI and uses the ToASCII operation on ireg-name. Implementations do not have to do this conversion as long as they produce the same result.
このようなIRIは、IRIを変換した後に得られたURIに解決し、IReg-NameでToascii操作を使用します。実装は、同じ結果を生み出す限り、この変換を行う必要はありません。
Note: The difference between variants b and c in step 1 (using normalization with NFC, versus not using any normalization) accounts for the fact that in many non-Unicode character encodings, some text cannot be represented directly. For example, the word "Vietnam" is natively written "Việt Nam" (containing a LATIN SMALL LETTER E WITH CIRCUMFLEX AND DOT BELOW) in NFC, but a direct transcoding from the windows-1258 character encoding leads to "Việt Nam" (containing a LATIN SMALL LETTER E WITH CIRCUMFLEX followed by a COMBINING DOT BELOW). Direct transcoding of other 8-bit encodings of Vietnamese may lead to other representations.
注：ステップ1のバリアントBとCの違い（NFCでの正規化を使用することと正規化を使用しないのではなく）は、多くの非波状文字エンコーディングで、一部のテキストを直接表すことができないという事実を説明します。たとえば、「ベトナム」という単語は、NFCで「VI＆＃x1EC7; t nam」（以下にcircirflexとドットを伴うラテン語の小さな文字Eを含む）をネイティブに書かれていますが、Windows-1258文字をエンコードする直接的なトランスコーディングは「VI＆」につながります。#xea;＆＃x323; t nam "（ラテン語の小さな文字eを含むcircirflexの後、下に結合するドットが続きます）。ベトナム語の他の8ビットエンコーディングの直接トランスコーディングは、他の表現につながる可能性があります。
Note: The uniform treatment of the whole IRI in step 2 is important to make processing independent of URI scheme. See [Gettys] for an in-depth discussion.
注：ステップ2のIRI全体の均一な処理は、URIスキームとは無関係に処理を行うために重要です。詳細な議論については、[Gettys]を参照してください。
Note: In practice, whether the general mapping (steps 1 and 2) or the ToASCII operation of [RFC3490] is used for ireg-name will not be noticed if mapping from IRI to URI and resolution is tightly integrated (e.g., carried out in the same user agent). But conversion using [RFC3490] may be able to better deal with backwards compatibility issues in case mapping and resolution are separated, as in the case of using an HTTP proxy.
注：実際には、一般的なマッピング（ステップ1および2）または[RFC3490]のTOASCII操作がIREG-NAMEに使用されているかどうかは、IRIからURIへのマッピングと解像度が緊密に統合されている場合にはわかりません（例えば、実行されます。同じユーザーエージェント）。ただし、[RFC3490]を使用した変換は、HTTPプロキシを使用する場合のように、マッピングと解像度が分離された場合に、後方互換性の問題をよりよく扱うことができる場合があります。
Note: Internationalized Domain Names may be contained in parts of an IRI other than the ireg-name part. It is the responsibility of scheme-specific implementations (if the Internationalized Domain Name is part of the scheme syntax) or of server-side implementations (if the Internationalized Domain Name is part of 'iquery') to apply the necessary conversions at the appropriate point. Example: Trying to validate the Web page at http://résumé.example.org would lead to an IRI of http://validator.w3.org/check?uri=http%3A%2F%2Frésumé. example.org, which would convert to a URI of http://validator.w3.org/check?uri=http%3A%2F%2Fr%C3%A9sum%C3%A9. example.org. The server side implementation would be responsible for making the necessary conversions to be able to retrieve the Web page.
注：国際化されたドメイン名は、IREG-NAME部分以外のIRIの一部に含まれる場合があります。適切なポイントで必要な変換を適用することは、スキーム固有の実装（国際化ドメイン名がスキーム構文の一部である場合）またはサーバー側の実装（国際化ドメイン名が「iquery」の一部である場合）の責任です。。例：http：// r＆＃xe9; sum＆＃xe9; .example.orgでWebページを検証しようとすると、http://validator.w3.org/check?uri=http%3a%2ffff％2fr＆＃xe9; sum＆＃xe9;。example.org、http：//validator.w3.org/check?uri=http%3a%2FFFFFFFFFR%C3%A9Sum%C3%A9のURIに変換されます。example.org。サーバー側の実装は、Webページを取得できるように必要な変換を行う責任があります。
Systems accepting IRIs MAY also deal with the printable characters in US-ASCII that are not allowed in URIs, namely "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", in step 2 above. If these characters are found but are not converted, then the conversion SHOULD fail. Please note that the number sign ("#"), the percent sign ("%"), and the square bracket characters ("[", "]") are not part of the above list and MUST NOT be converted. Protocols and formats that have used earlier definitions of IRIs including these characters MAY require percent-encoding of these characters as a preprocessing step to extract the actual IRI from a given field. This preprocessing MAY also be used by applications allowing the user to enter an IRI.
IRISを受け入れるシステムは、URIで許可されていないUS-ASCIIの印刷可能な文字、つまり「<」、「>」、 '"、' '、" {"、"} "、" | "、" \"、"^"、および「` "、上記のステップ2の。これらの文字が見つかったが変換されていない場合、変換は失敗するはずです。数字符号（"＃ "）、パーセント記号（"％に注意してください。"）、およびスクエアブラケット文字（" ["、"] "）は上記のリストの一部ではなく、変換してはなりません。これらの文字を含む虹彩の以前の定義を使用したプロトコルと形式では、これらのパーセントエンコードが必要になる場合があります。特定のフィールドから実際のIRIを抽出するための前処理ステップとしての文字。この前処理は、ユーザーがIRIを入力できるアプリケーションでも使用できます。
Note: In this process (in step 2.3), characters allowed in URI references and existing percent-encoded sequences are not encoded further. (This mapping is similar to, but different from, the encoding applied when arbitrary content is included in some part of a URI.) For example, an IRI of "http://www.example.org/red%09rosé#red" (in XML notation) is converted to "http://www.example.org/red%09ros%C3%A9#red", not to something like "http%3A%2F%2Fwww.example.org%2Fred%2509ros%C3%A9%23red".
注：このプロセス（ステップ2.3）では、URI参照と既存のパーセントエンコードシーケンスで許可されている文字は、それ以上エンコードされていません。（このマッピングは、任意のコンテンツがURIの一部に含まれている場合に適用されるエンコードとは異なりますが、異なります。）たとえば、「http://www.example.org/red%09rosé#Red "（XML NOTATION）は「http://www.example.org/red%09ros%C3%A9#red」に変換されます。2FRED％2509ROS％C3％A9％23RED "。
Note: Some older software transcoding to UTF-8 may produce illegal
output for some input, in particular for characters outside the
BMP (Basic Multilingual Plane). As an example, for the IRI with
non-BMP characters (in XML Notation):
"http://example.com/𐌀𐌁𐌂";
which contains the first three letters of the Old Italic alphabet, the correct conversion to a URI is "http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82"
古いイタリックアルファベットの最初の3文字を含む、URIへの正しい変換は「http://example.com/%f0%90%8Cです。％82 "
In some situations, converting a URI into an equivalent IRI may be desirable. This section gives a procedure for this conversion. The conversion described in this section will always result in an IRI that maps back to the URI used as an input for the conversion (except for potential case differences in percent-encoding and for potential percent-encoded unreserved characters). However, the IRI resulting from this conversion may not be exactly the same as the original IRI (if there ever was one).
状況によっては、URIを同等のIRIに変換することが望ましい場合があります。このセクションでは、この変換の手順を示します。このセクションで説明した変換は、常に変換の入力として使用されるURIに戻るIRIにつながります（パーセントエンコードの潜在的な症例の違いと潜在的なパーセントにエンコードされていない文字を除く）。ただし、この変換の結果として生じるIRIは、元のIRIとまったく同じではない場合があります（もしあれば）。
URI-to-IRI conversion removes percent-encodings, but not all percent-encodings can be eliminated. There are several reasons for this:
URIからIRIへの変換はパーセントエンコードを削除しますが、すべてのパーセントエンコードを排除できるわけではありません。これにはいくつかの理由があります：
1. Some percent-encodings are necessary to distinguish percent-encoded and unencoded uses of reserved characters.
1. 予約された文字のパーセントとエンコードされていない使用を区別するには、いくつかのパーセントエンコードが必要です。
2. Some percent-encodings cannot be interpreted as sequences of UTF-8 octets.
2. いくつかのパーセントエンコングをUTF-8オクテットのシーケンスとして解釈することはできません。
(Note: The octet patterns of UTF-8 are highly regular. Therefore, there is a very high probability, but no guarantee, that percent-encodings that can be interpreted as sequences of UTF-8 octets actually originated from UTF-8. For a detailed discussion, see [Duerst97].)
（注：UTF-8のオクテットパターンは非常に規則的です。したがって、非常に高い確率がありますが、保証はありませんが、UTF-8オクテットのシーケンスとして実際にUTF-8に由来するものとして解釈できるパーセントエンコードはありません。詳細な議論、[duerst97]を参照してください。）
3. The conversion may result in a character that is not appropriate in an IRI. See sections 2.2, 4.1, and 6.1 for further details.
3. 変換により、IRIで適切でないキャラクターが生じる場合があります。詳細については、セクション2.2、4.1、および6.1を参照してください。
Conversion from a URI to an IRI is done by using the following steps (or any other algorithm that produces the same result):
URIからIRIへの変換は、次の手順（または同じ結果を生成する他のアルゴリズム）を使用して行われます。
1. Represent the URI as a sequence of octets in US-ASCII.
1. URIをUS-ASCIIのオクテットのシーケンスとして表します。
2. Convert all percent-encodings ("%" followed by two hexadecimal digits) to the corresponding octets, except those corresponding to "%", characters in "reserved", and characters in US-ASCII not allowed in URIs.
2. すべてのパーセントエンコード（「％」に続いて2匹の16進数桁）を対応するオクテットに変換します。ただし、「％」に対応するオクテット、「予約済み」の文字、およびURISで許可されていないUS-ASCIIの文字。
3. Re-percent-encode any octet produced in step 2 that is not part of a strictly legal UTF-8 octet sequence.
3. 厳密に合法的なUTF-8オクテットシーケンスの一部ではないステップ2で生成されたオクテットの再透過エンコード。
4. Re-percent-encode all octets produced in step 3 that in UTF-8 represent characters that are not appropriate according to sections 2.2, 4.1, and 6.1.
4. ステップ3で作成されたすべてのオクテットを再透過性エンコードUTF-8では、セクション2.2、4.1、および6.1に従って適切でない文字を表します。
5. Interpret the resulting octet sequence as a sequence of characters encoded in UTF-8.
5. 結果のオクテットシーケンスを、UTF-8でエンコードされた一連の文字として解釈します。
This procedure will convert as many percent-encoded characters as possible to characters in an IRI. Because there are some choices when step 4 is applied (see section 6.1), results may vary.
この手順は、IRIのキャラクターにできるだけ多くのパーセントエンコードされた文字を変換します。ステップ4が適用されるといくつかの選択肢があるため（セクション6.1を参照）、結果は異なる場合があります。
Conversions from URIs to IRIs MUST NOT use any character encoding other than UTF-8 in steps 3 and 4, even if it might be possible to guess from the context that another character encoding than UTF-8 was used in the URI. For example, the URI "http://www.example.org/r%E9sum%E9.html" might with some guessing be interpreted to contain two e-acute characters encoded as iso-8859-1. It must not be converted to an IRI containing these e-acute characters. Otherwise, in the future the IRI will be mapped to "http://www.example.org/r%C3%A9sum%C3%A9.html", which is a different URI from "http://www.example.org/r%E9sum%E9.html".
URISからIRISへの変換は、URIでUTF-8よりも別のキャラクターエンコードが使用されていることがコンテキストから推測できる場合でも、ステップ3および4でUTF-8以外のキャラクターエンコードを使用してはなりません。たとえば、URI "http://www.example.org/r%E9Sum%E9.html"は、ISO-8859-1としてエンコードされた2つのe-acte文字が含まれていると解釈されると、一部の推測であると思われます。これらのe-acte文字を含むIRIに変換してはなりません。それ以外の場合、将来、IRIは「http://www.example.org/r%C3%A9Sum%C3%A9.html」にマッピングされます。org/r％e9sum％e9.html "。
This section shows various examples of converting URIs to IRIs. Each example shows the result after each of the steps 1 through 5 is applied. XML Notation is used for the final result. Octets are denoted by "<" followed by two hexadecimal digits followed by ">".
このセクションでは、URIをIRISに変換するさまざまな例を示しています。各例は、ステップ1〜5のそれぞれが適用された後の結果を示しています。XML表記は、最終結果に使用されます。オクテットは、「<」に続いて2つの16進数桁に続いて「>」で示されます。
The following example contains the sequence "%C3%BC", which is a strictly legal UTF-8 sequence, and which is converted into the actual character U+00FC, LATIN SMALL LETTER U WITH DIAERESIS (also known as u-umlaut).
次の例には、厳密に合法的なUTF-8シーケンスであるシーケンス「％C3％BC」が含まれており、実際の文字U 00FC、ラテンの小文字Uに変換されます。
1. http://www.example.org/D%C3%BCrst
1.
2. http://www.example.org/D<c3><bc>rst
2.
3. http://www.example.org/D<c3><bc>rst
3.
4. http://www.example.org/D<c3><bc>rst
4.
5. http://www.example.org/Dürst
5.
The following example contains the sequence "%FC", which might represent U+00FC, LATIN SMALL LETTER U WITH DIAERESIS, in the iso-8859-1 character encoding. (It might represent other characters in other character encodings. For example, the octet <fc> in iso-8859-5 represents U+045C, CYRILLIC SMALL LETTER KJE.) Because <fc> is not part of a strictly legal UTF-8 sequence, it is re-percent-encoded in step 3.
次の例には、ISO-8859-1文字エンコーディングで、u 00FC、diaeresisを伴うラテン語の小文字uを表す可能性のあるシーケンス「％fc」が含まれています。（他のキャラクターエンコーディングの他の文字を表す可能性があります。たとえば、ISO-8859-5のoctet <fc>はu 045c、キリル語の小文字kjeを表します。）<fc>は厳密に合法的なUTF-8シーケンスの一部ではないため、ステップ3で再透過性エンコードされています。
1. http://www.example.org/D%FCrst
1.
2. http://www.example.org/D<fc>rst
2.
3. http://www.example.org/D%FCrst
3.
4. http://www.example.org/D%FCrst
4.
5. http://www.example.org/D%FCrst
5.
The following example contains "%e2%80%ae", which is the percent-encoded UTF-8 character encoding of U+202E, RIGHT-TO-LEFT OVERRIDE. Section 4.1 forbids the direct use of this character in an IRI. Therefore, the corresponding octets are re-percent-encoded in step 4. This example shows that the case (upper- or lowercase) of letters used in percent-encodings may not be preserved. The example also contains a punycode-encoded domain name label (xn--99zt52a), which is not converted.
次の例には、「％E2％80％AE」が含まれています。これは、U 202EのUTF-8文字エンコードパーセントであり、左から左へのオーバーライドです。セクション4.1は、IRIでのこのキャラクターの直接使用を禁止しています。したがって、対応するオクテットは、ステップ4で再透過性エンコードされています。この例は、パーセントエンコーディングで使用される文字のケース（上位または小文字）が保存されない可能性があることを示しています。この例には、パニコードエンコードドメイン名ラベル（XN - 99ZT52A）も含まれていますが、これは変換されていません。
1. http://xn--99zt52a.example.org/%e2%80%ae
1.
2. http://xn--99zt52a.example.org/<e2><80><ae>
2.
3. http://xn--99zt52a.example.org/<e2><80><ae>
3.
4. http://xn--99zt52a.example.org/%E2%80%AE
4.
5. http://xn--99zt52a.example.org/%E2%80%AE
5.
Implementations with scheme-specific knowledge MAY convert punycode-encoded domain name labels to the corresponding characters by using the ToUnicode procedure. Thus, for the example above, the label "xn--99zt52a" may be converted to U+7D0D U+8C46 (Japanese Natto), leading to the overall IRI of "http://納豆.example.org/%E2%80%AE".
スキーム固有の知識を持つ実装では、トゥナイコード手順を使用して、プニコードエンコードドメイン名ラベルを対応する文字に変換する場合があります。したがって、上記の例では、ラベル「xn-99zt52a」はu 7d0d u 8c46（日本のnatto）に変換され、「http：//＆＃x7d0d;＆＃x7d0d;＆＃x8c46; .example」の全体的なIRIにつながる場合があります。org/％e2％80％ae "。
Some UCS characters, such as those used in the Arabic and Hebrew scripts, have an inherent right-to-left (rtl) writing direction. IRIs containing these characters (called bidirectional IRIs or Bidi IRIs) require additional attention because of the non-trivial relation between logical representation (used for digital representation and for reading/spelling) and visual representation (used for display/printing).
アラビア語やヘブライ語のスクリプトで使用されているものなど、一部のUCS文字には、左から左への権利（RTL）の執筆指示があります。これらのキャラクターを含む虹彩（双方向虹彩またはBidi Irisと呼ばれる）は、論理表現（デジタル表現と読み取り/スペルに使用）と視覚表現（ディスプレイ/印刷に使用）の間の非重要な関係のために、追加の注意が必要です。
Because of the complex interaction between the logical representation, the visual representation, and the syntax of a Bidi IRI, a balance is needed between various requirements. The main requirements are
論理表現、視覚表現、およびBidi IRIの構文の間の複雑な相互作用のため、さまざまな要件の間でバランスが必要です。主な要件は次のとおりです
1. user-predictable conversion between visual and logical representation;
1. 視覚表現と論理的表現の間のユーザー予測の変換。
2. the ability to include a wide range of characters in various parts of the IRI; and
2. IRIのさまざまな部分に幅広いキャラクターを含める機能。そして
3. minor or no changes or restrictions for implementations.
3. 実装の変更または制限なし。
When stored or transmitted in digital representation, bidirectional IRIs MUST be in full logical order and MUST conform to the IRI syntax rules (which includes the rules relevant to their scheme). This ensures that bidirectional IRIs can be processed in the same way as other IRIs.
デジタル表現に保存または送信される場合、双方向虹彩は完全に論理的な順序でなければならず、IRI構文規則（スキームに関連するルールを含む）に準拠する必要があります。これにより、双方向の虹彩が他の虹彩と同じ方法で処理されることが保証されます。
Bidirectional IRIs MUST be rendered by using the Unicode Bidirectional Algorithm [UNIV4], [UNI9]. Bidirectional IRIs MUST be rendered in the same way as they would be if they were in a left-to-right embedding; i.e., as if they were preceded by U+202A, LEFT-TO-RIGHT EMBEDDING (LRE), and followed by U+202C, POP DIRECTIONAL FORMATTING (PDF). Setting the embedding direction can also be done in a higher-level protocol (e.g., the dir='ltr' attribute in HTML).
双方向虹彩は、単一コード双方向アルゴリズム[UNIV4]、[UNI9]を使用してレンダリングする必要があります。双方向虹彩は、左から右の埋め込みにある場合と同じようにレンダリングされなければなりません。つまり、まるでu 202a、左から右への埋め込み（LRE）が先行し、続いてU 202C、POP方向フォーマット（PDF）が続きます。埋め込み方向の設定は、高レベルのプロトコル（たとえば、HTMLのDIR = 'LTR'属性）で実行することもできます。
There is no requirement to use the above embedding if the display is still the same without the embedding. For example, a bidirectional IRI in a text with left-to-right base directionality (such as used for English or Cyrillic) that is preceded and followed by whitespace and strong left-to-right characters does not need an embedding. Also, a bidirectional relative IRI reference that only contains strong right-to-left characters and weak characters and that starts and ends with a strong right-to-left character and appears in a text with right-to-left base directionality (such as used for Arabic or Hebrew) and is preceded and followed by whitespace and strong characters does not need an embedding.
ディスプレイが埋め込みなしでまだ同じである場合、上記の埋め込みを使用する必要はありません。たとえば、左から右へのベースの方向性（英語やキリル語に使用されるなど）があるテキストの双方向IRIは、その後に白人が続き、左から右への強いキャラクターが埋め込む必要はありません。また、強力な右から左へのキャラクターのみを含み、左から左への右の文字で始まり、左から左へのベースの方向性を持つテキストに表示される双方向の相対的な参照。アラビア語またはヘブライ語に使用されています）、そして前に、そしてその後にwhitespaceが続き、強いキャラクターは埋め込みを必要としません。
In some other cases, using U+200E, LEFT-TO-RIGHT MARK (LRM), may be sufficient to force the correct display behavior. However, the details of the Unicode Bidirectional algorithm are not always easy to understand. Implementers are strongly advised to err on the side of caution and to use embedding in all cases where they are not completely sure that the display behavior is unaffected without the embedding.
他のいくつかの場合、u 200eを使用して、左から右へのマーク（LRM）は、正しいディスプレイの動作を強制するのに十分かもしれません。ただし、ユニコード双方向アルゴリズムの詳細は、必ずしも理解しやすいとは限りません。実装者は、注意を払っている側で誤りを犯し、埋め込みの動作が埋め込みなしで影響を受けていないことが完全にわからないすべての場合に埋め込みを使用することを強くお勧めします。
The Unicode Bidirectional Algorithm ([UNI9], section 4.3) permits higher-level protocols to influence bidirectional rendering. Such changes by higher-level protocols MUST NOT be used if they change the rendering of IRIs.
ユニコード双方向アルゴリズム（[UNI9]、セクション4.3）は、高レベルのプロトコルが双方向レンダリングに影響を与えることを許可しています。高レベルのプロトコルによるこのような変更は、虹彩のレンダリングを変更した場合は使用しないでください。
The bidirectional formatting characters that may be used before or after the IRI to ensure correct display are not themselves part of the IRI. IRIs MUST NOT contain bidirectional formatting characters (LRM, RLM, LRE, RLE, LRO, RLO, and PDF). They affect the visual rendering of the IRI but do not appear themselves. It would therefore not be possible to input an IRI with such characters correctly.
IRIの前または後に使用できる双方向フォーマット文字は、正しいディスプレイ自体がIRIの一部ではないことを確認します。IRISには、双方向のフォーマット文字（LRM、RLM、LRE、RLE、LRO、RLO、およびPDF）を含めてはなりません。それらはIRIの視覚的なレンダリングに影響を与えますが、自分自身には見えません。したがって、そのようなキャラクターとIRIを正しく入力することはできません。
The Unicode Bidirectional Algorithm is designed mainly for running text. To make sure that it does not affect the rendering of bidirectional IRIs too much, some restrictions on bidirectional IRIs are necessary. These restrictions are given in terms of delimiters (structural characters, mostly punctuation such as "@", ".", ":", and "/") and components (usually consisting mostly of letters and digits).
ユニコード双方向アルゴリズムは、主にテキストを実行するために設計されています。それが双方向虹彩のレンダリングにあまりにも影響を与えないことを確認するには、双方向虹彩のいくつかの制限が必要です。これらの制限は、区切り文字（構造文字、「@」、」、「」、「」、「/」などの句読点）とコンポーネント（通常はほとんど文字と数字で構成される）の観点から与えられます。
The following syntax rules from section 2.2 correspond to components for the purpose of Bidi behavior: iuserinfo, ireg-name, isegment, isegment-nz, isegment-nz-nc, ireg-name, iquery, and ifragment.
セクション2.2の次の構文規則は、ビディの行動を目的としたコンポーネントに対応しています：iuserinfo、iReg-name、isegment、等gment-nz、Isegment-nz-nc、ireg-name、iquery、およびifragment。
Specifications that define the syntax of any of the above components MAY divide them further and define smaller parts to be components according to this document. As an example, the restrictions of [RFC3490] on bidirectional domain names correspond to treating each label of a domain name as a component for schemes with ireg-name as a domain name. Even where the components are not defined formally, it may be helpful to think about some syntax in terms of components and to apply the relevant restrictions. For example, for the usual name/value syntax in query parts, it is convenient to treat each name and each value as a component. As another example, the extensions in a resource name can be treated as separate components.
上記のコンポーネントのいずれかの構文を定義する仕様は、それらをさらに分割し、このドキュメントに従って小さな部分をコンポーネントに定義する場合があります。例として、双方向のドメイン名に対する[RFC3490]の制限は、ドメイン名の各ラベルをドメイン名としてIREG-NAMEのスキームのコンポーネントとして扱うことに対応しています。コンポーネントが正式に定義されていない場合でも、コンポーネントの観点からいくつかの構文について考えると、関連する制限を適用することが役立つ場合があります。たとえば、クエリパーツの通常の名前/値構文の場合、各名前と各値をコンポーネントとして扱うのが便利です。別の例として、リソース名の拡張機能は別々のコンポーネントとして扱うことができます。
For each component, the following restrictions apply:
各コンポーネントについて、次の制限が適用されます。
1. A component SHOULD NOT use both right-to-left and left-to-right characters.
1. コンポーネントは、右から右への左右の文字の両方を使用しないでください。
2. A component using right-to-left characters SHOULD start and end with right-to-left characters.
2. 右から左の文字を使用するコンポーネントは、右から左の文字で開始および終了する必要があります。
The above restrictions are given as shoulds, rather than as musts. For IRIs that are never presented visually, they are not relevant. However, for IRIs in general, they are very important to ensure consistent conversion between visual presentation and logical representation, in both directions.
上記の制限は、必見ではなく、肩として与えられます。視覚的に提示されない虹彩の場合、それらは関連性がありません。ただし、一般的に虹彩の場合、視覚的なプレゼンテーションと論理表現の間に一貫した変換を確保するためには、両方向に非常に重要です。
Note: In some components, the above restrictions may actually be strictly enforced. For example, [RFC3490] requires that these restrictions apply to the labels of a host name for those schemes where ireg-name is a host name. In some other components (for example, path components) following these restrictions may not be too difficult. For other components, such as parts of the query part, it may be very difficult to enforce the restrictions because the values of query parameters may be arbitrary character sequences.
注：一部のコンポーネントでは、上記の制限が実際に厳密に施行される場合があります。たとえば、[RFC3490]では、これらの制限がIREGNAMEがホスト名であるスキームのホスト名のラベルに適用されることを要求しています。これらの制限後の他のコンポーネント（たとえば、パスコンポーネントなど）では、それほど難しくない場合があります。クエリ部分の一部などの他のコンポーネントの場合、クエリパラメーターの値が任意の文字シーケンスである可能性があるため、制限を実施することは非常に困難な場合があります。
If the above restrictions cannot be satisfied otherwise, the affected component can always be mapped to URI notation as described in section 3.1. Please note that the whole component has to be mapped (see also Example 9 below).
上記の制限が満たされない場合、それ以外の場合、影響を受けるコンポーネントは、セクション3.1で説明されているように、常にURI表記にマッピングできます。コンポーネント全体をマッピングする必要があることに注意してください（以下の例も参照）。
Bidi input methods MUST generate Bidi IRIs in logical order while rendering them according to section 4.1. During input, rendering SHOULD be updated after every new character is input to avoid end-user confusion.
Bidi入力方法は、セクション4.1に従ってそれらをレンダリングしながら、論理的な順序でBidi Irisを生成する必要があります。入力中、エンドユーザーの混乱を避けるために、新しい文字が入力されるたびにレンダリングを更新する必要があります。
This section gives examples of bidirectional IRIs, in Bidi Notation. It shows legal IRIs with the relationship between logical and visual representation and explains how certain phenomena in this relationship may look strange to somebody not familiar with bidirectional behavior, but familiar to users of Arabic and Hebrew. It also shows what happens if the restrictions given in section 4.2 are not followed. The examples below can be seen at [BidiEx], in Arabic, Hebrew, and Bidi Notation variants.
このセクションでは、Bidi Notationの双方向虹彩の例を示します。論理的表現と視覚的表現の関係を伴う合法的な虹彩を示しており、この関係の特定の現象が、双方向の行動に精通していないが、アラビア語とヘブライ語のユーザーに馴染みのある人にとって奇妙に見えるかもしれないことを説明しています。また、セクション4.2で与えられた制限が守られていない場合に何が起こるかを示します。以下の例は、[Bidiex]、アラビア語、ヘブライ語、およびBidi表記のバリアントで見ることができます。
To read the bidi text in the examples, read the visual representation from left to right until you encounter a block of rtl text. Read the rtl block (including slashes and other special characters) from right to left, then continue at the next unread ltr character.
例のBIDIテキストを読むには、RTLテキストのブロックに遭遇するまで、視覚表現を左から右に読んでください。RTLブロック（スラッシュやその他の特殊文字を含む）を右から左に読んでから、次のUnread LTR文字で続行します。
Example 1: A single component with rtl characters is inverted: Logical representation: "http://ab.CDEFGH.ij/kl/mn/op.html" Visual representation: "http://ab.HGFEDC.ij/kl/mn/op.html" Components can be read one by one, and each component can be read in its natural direction.
例1：RTL文字を含む単一のコンポーネントが反転します：論理表現： "http：//ab.cdefgh.ij/kl/mn/op.html"視覚表現： "http：//ab.hgfedc.ij/kl/mn/op.html "コンポーネントは1つずつ読み取ることができ、各コンポーネントはその自然な方向に読み取ることができます。
Example 2: More than one consecutive component with rtl characters is inverted as a whole: Logical representation: "http://ab.CDE.FGH/ij/kl/mn/op.html" Visual representation: "http://ab.HGF.EDC/ij/kl/mn/op.html" A sequence of rtl components is read rtl, in the same way as a sequence of rtl words is read rtl in a bidi text.
例2：RTL文字を含む複数の連続したコンポーネントが全体として反転されます：論理表現： "http：//ab.cde.fgh/ij/kl/mn/op.html"視覚表現： "http：// ab.hgf.edc/ij/kl/mn/op.html "rtlコンポーネントのシーケンスはRTLを読み取り、rtlワードのシーケンスがBIDIテキストでRTLを読み取るのと同じ方法で読み取りされます。
Example 3: All components of an IRI (except for the scheme) are rtl. All rtl components are inverted overall: Logical representation: "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV" Visual representation: "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA" The whole IRI (except the scheme) is read rtl. Delimiters between rtl components stay between the respective components; delimiters between ltr and rtl components don't move.
例3：IRIのすべてのコンポーネント（スキームを除く）はRTLです。すべてのRTLコンポーネントが全体的に反転します：論理表現： "http：//ab.cd.ef/gh/ij/kl？mn = op; qr = st＃uv"視覚表現： "http：// vu＃ts = rq; po = nm？lk/ji/hg/fe.dc.ba "全体のIRI（スキームを除く）は読み取りrtlです。RTLコンポーネント間のデリミターは、それぞれのコンポーネント間に留まります。LTRコンポーネントとRTLコンポーネントの間の区切り文字は移動しません。
Example 4: Each of several sequences of rtl components is inverted on its own: Logical representation: "http://AB.CD.ef/gh/IJ/KL.html" Visual representation: "http://DC.BA.ef/gh/LK/JI.html" Each sequence of rtl components is read rtl, in the same way as each sequence of rtl words in an ltr text is read rtl.
例4：RTLコンポーネントのいくつかのシーケンスのそれぞれは、それ自体で反転されます： "http：//ab.cd.ef/gh/ij/kl.html"視覚表現： "http://dc.ba。ef/gh/lk/ji.html "rtlコンポーネントの各シーケンスは、rtlを読み取り、ltrテキスト内のrtlワードの各シーケンスがrtlに読み取られます。
Example 5: Example 2, applied to components of different kinds: Logical representation: "http://ab.cd.EF/GH/ij/kl.html" Visual representation: "http://ab.cd.HG/FE/ij/kl.html" The inversion of the domain name label and the path component may be unexpected, but it is consistent with other bidi behavior. For reassurance that the domain component really is "ab.cd.EF", it may be helpful to read aloud the visual representation following the bidi algorithm. After "http://ab.cd." one reads the RTL block "E-F-slash-G-H", which corresponds to the logical representation.
例5：例2、さまざまな種類のコンポーネントに適用：論理表現： "http：//ab.cd.ef/gh/ij/kl.html"視覚表現： "http：//ab.cd.hg/fe/ij/kl.html "ドメイン名ラベルとパスコンポーネントの反転は予想外かもしれませんが、他のBidiの動作と一致しています。ドメインコンポーネントが実際に「ab.cd.ef」であるという安心感のために、Bidiアルゴリズムに従って視覚表現を声に出して読み上げると役立つかもしれません。「http://ab.cd」の後RTLブロック「E-F-Slash-G-H」を読み取ります。これは、論理表現に対応します。
Example 6: Same as Example 5, with more rtl components: Logical representation: "http://ab.CD.EF/GH/IJ/kl.html" Visual representation: "http://ab.JI/HG/FE.DC/kl.html" The inversion of the domain name labels and the path components may be easier to identify because the delimiters also move.
例6：例5と同じ、より多くのRTLコンポーネントを備えた：論理表現： "http：//ab.cd.ef/gh/ij/kl.html"視覚表現： "http：//ab.ji/hg/fe.dc/kl.html "ドメイン名のラベルとパスコンポーネントの反転は、デリミターも移動するため識別しやすい場合があります。
Example 7: A single rtl component includes digits: Logical representation: "http://ab.CDE123FGH.ij/kl/mn/op.html" Visual representation: "http://ab.HGF123EDC.ij/kl/mn/op.html" Numbers are written ltr in all cases but are treated as an additional embedding inside a run of rtl characters. This is completely consistent with usual bidirectional text.
例7：単一のRTLコンポーネントには数字が含まれます：論理表現： "http：//ab.cde123fgh.ij/kl/mn/op.html"視覚表現： "http：//ab.hgf123edc.ij/kl/mn/op.html "番号はすべての場合にLTRと書かれていますが、RTL文字の実行内に追加の埋め込みとして扱われます。これは、通常の双方向テキストと完全に一致しています。
Example 8 (not allowed): Numbers are at the start or end of an rtl component: Logical representation: "http://ab.cd.ef/GH1/2IJ/KL.html" Visual representation: "http://ab.cd.ef/LK/JI1/2HG.html" The sequence "1/2" is interpreted by the bidi algorithm as a fraction, fragmenting the components and leading to confusion. There are other characters that are interpreted in a special way close to numbers; in particular, "+", "-", "#", "$", "%", ",", ".", and ":".
例8（許可されていない）：数字はRTLコンポーネントの開始または終了時にあります：論理表現： "http：//ab.cd.ef/gh1/2ij/kl.html"視覚表現： "http：// ab.cd.ef/lk/ji1/2hg.html "シーケンス" 1/2 "は、Bidiアルゴリズムによって分数として解釈され、コンポーネントを断片化し、混乱につながります。数字に近い特別な方法で解釈される他のキャラクターがあります。特に、 ""、 " - "、 "＃"、 "$"、 "％"、 "、"。 "、および"： "。
Example 9 (not allowed): The numbers in the previous example are percent-encoded: Logical representation: "http://ab.cd.ef/GH%31/%32IJ/KL.html", Visual representation (Hebrew): "http://ab.cd.ef/%31HG/LK/JI%32.html" Visual representation (Arabic): "http://ab.cd.ef/31%HG/%LK/JI32.html" Depending on whether the uppercase letters represent Arabic or Hebrew, the visual representation is different.
例9（許可されていない）：前の例の数字はパーセントエンコードされています：論理表現： "http：//ab.cd.ef/gh%31/%32ij/kl.html"、視覚表現（ヘブライ語）："http：//ab.cd.ef/%31hg/lk/ji%32.html"視覚表現（アラビア語）： "http：//ab.cd.ef/31%hg/%lk/Ji32.html"大文字がアラビア語を表すかヘブライ語を表すかによって、視覚的表現は異なります。
Example 10 (allowed but not recommended): Logical representation: "http://ab.CDEFGH.123/kl/mn/op.html" Visual representation: "http://ab.123.HGFEDC/kl/mn/op.html" Components consisting of only numbers are allowed (it would be rather difficult to prohibit them), but these may interact with adjacent RTL components in ways that are not easy to predict.
例10（許可されているが推奨されない）：論理表現： "http：//ab.cdefgh.123/kl/mn/op.html"視覚表現： "http：//ab.123.hgfedc/kl/mn/op.html "数値のみで構成されるコンポーネントは許可されます（それらを禁止することはかなり困難です）が、これらは予測が容易ではない方法で隣接するRTLコンポーネントと相互作用する場合があります。
Note: The structure and much of the material for this section is taken from section 6 of [RFC3986]; the differences are due to the specifics of IRIs.
注：このセクションの構造と材料の多くは、[RFC3986]のセクション6から取得しています。違いは、虹彩の詳細によるものです。
One of the most common operations on IRIs is simple comparison: Determining whether two IRIs are equivalent without using the IRIs or the mapped URIs to access their respective resource(s). A comparison is performed whenever a response cache is accessed, a browser checks its history to color a link, or an XML parser processes tags within a namespace. Extensive normalization prior to comparison of IRIs may be used by spiders and indexing engines to prune a search space or reduce duplication of request actions and response storage.
IRISで最も一般的な操作の1つは、単純な比較です。IRISまたはマッピングされたURIを使用してそれぞれのリソースにアクセスすることなく、2つのIRIが同等であるかどうかを判断することです。応答キャッシュにアクセスするたびに比較が実行されます。ブラウザは履歴をチェックしてリンクを色付けするか、名前空間内のXMLパーサープロセスタグをプロセスします。虹彩の比較前の広範な正規化は、クモとインデックスエンジンによって使用され、検索スペースを剪定するか、リクエストアクションと応答ストレージの重複を減らすことができます。
IRI comparison is performed for some particular purpose. Protocols or implementations that compare IRIs for different purposes will often be subject to differing design trade-offs in regards to how much effort should be spent in reducing aliased identifiers. This section describes various methods that may be used to compare IRIs, the trade-offs between them, and the types of applications that might use them.
IRIの比較は、特定の目的のために実行されます。さまざまな目的でIRIを比較するプロトコルまたは実装は、多くの場合、エイリアスの識別子を減らすためにどれだけの努力を費やすべきかに関して、異なる設計トレードオフの対象となります。このセクションでは、虹彩の間のトレードオフ、およびそれらを使用する可能性のあるアプリケーションの種類を比較するために使用できるさまざまな方法について説明します。
Because IRIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, this definition of equivalence is not of much practical use, as there is no way for an implementation to compare two resources unless it has full knowledge or control of them. For this reason, determination of equivalence or difference of IRIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence.
IRISはリソースを識別するために存在するため、おそらく同じリソースを識別するときに同等と見なされるべきです。ただし、この等価性の定義は、実装が完全に使用されていないため、2つのリソースを完全に知識または制御しない限り、2つのリソースを比較する方法がないため、あまり実用的ではありません。このため、IRISの等価性または差の決定は、URIスキーム定義によって提供される追加のルールを参照することにより、おそらく文字列比較に基づいています。「異なる」と「同等の」という用語を使用して、そのような比較の可能な結果を記述しますが、同等性のアプリケーション依存バージョンはたくさんあります。
Even though it is possible to determine that two IRIs are equivalent, IRI comparison is not sufficient to determine whether two IRIs identify different resources. For example, an owner of two different domain names could decide to serve the same resource from both, resulting in two different IRIs. Therefore, comparison methods are designed to minimize false negatives while strictly avoiding false positives.
2つの虹彩が同等であると判断することは可能ですが、IRIの比較は2つのIRIが異なるリソースを識別するかどうかを判断するのに十分ではありません。たとえば、2つの異なるドメイン名の所有者は、両方から同じリソースを提供し、2つの異なる虹彩になることを決定できます。したがって、比較方法は、誤検知を厳密に回避しながら、偽陰性を最小限に抑えるように設計されています。
In testing for equivalence, applications should not directly compare relative references; the references should be converted to their respective target IRIs before comparison. When IRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison.
同等性のテストでは、アプリケーションは相対的な参照を直接比較してはなりません。参照は、比較前にそれぞれのターゲット虹彩に変換する必要があります。IRISを選択した場合（または避ける）場合、表現の検索などのネットワークアクションを選択（または回避する）、フラグメントコンポーネント（ある場合）は比較から除外する必要があります。
Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). All other applications MUST select one of the comparison practices from the Comparison Ladder (see section 5.3 or, after IRI-to-URI conversion, select one of the comparison practices from the URI comparison ladder in [RFC3986], section 6.2)
IRISを使用するアプリケーションは、プロトコルとの関係のないアイデンティティトークンとして単純な文字列比較を使用する必要があります（セクション5.3.1を参照）。他のすべてのアプリケーションは、比較ラダーから比較プラクティスのいずれかを選択する必要があります（セクション5.3を参照するか、IRIからURIへの変換後、[RFC3986]のURI比較ラダーから比較慣行の1つ、セクション6.2を選択します）
Any kind of IRI comparison REQUIRES that all escapings or encodings in the protocol or format that carries an IRI are resolved. This is usually done when the protocol or format is parsed. Examples of such escapings or encodings are entities and numeric character references in [HTML4] and [XML1]. As an example, "http://example.org/rosé" (in HTML), "http://example.org/rosé"; (in HTML or XML), and "http://example.org/rosé"; (in HTML or XML) are all resolved into what is denoted in this document (see section 1.4) as "http://example.org/rosé"; (the "é" here standing for the actual e-acute character, to compensate for the fact that this document cannot contain non-ASCII characters).
あらゆる種類のIRI比較には、IRIを運ぶプロトコルまたは形式のすべての脱出またはエンコーディングが解決されることが必要です。これは通常、プロトコルまたはフォーマットが解析されたときに行われます。このような逃亡またはエンコーディングの例は、[html4]および[xml1]のエンティティと数値文字参照です。例として、「http://example.org/ros&ecute;」（html）、 "http://example.org/rosझ";（HTMLまたはXML）、および「http://example.org/rosé」;（HTMLまたはXMLで）はすべて、このドキュメントで示されているもの（セクション1.4を参照）に「http://example.org/rosé」として解決されます。（「＆＃xe9;」は、このドキュメントがASSASCII以外の文字を含めることができないという事実を補うために、実際のe-actute文字のために立っています）。
Similar considerations apply to encodings such as Transfer Codings in HTTP (see [RFC2616]) and Content Transfer Encodings in MIME ([RFC2045]), although in these cases, the encoding is based not on characters but on octets, and additional care is required to make sure that characters, and not just arbitrary octets, are compared (see section 5.3.1).
同様の考慮事項は、HTTPの転送コーディング（[RFC2616]を参照）やMIMEのコンテンツ転送エンコーディング（[RFC2045]）などのエンコーディングにも適用されますが、エンコーディングは文字ではなくオクテットに基づいており、追加のケアが必要です。任意のオクテットだけでなく、キャラクターが比較されることを確認するために（セクション5.3.1を参照）。
In practice, a variety of methods are used, to test IRI equivalence. These methods fall into a range distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications.
実際には、IRIの等価性をテストするために、さまざまな方法が使用されています。これらの方法は、必要な処理の量と偽陰性の確率が低下する程度によって区別される範囲に分類されます。上記のように、偽のネガを排除することはできません。実際には、それらの確率を減らすことができますが、この削減にはより多くの処理が必要であり、すべてのアプリケーションで費用対効果が高くありません。
If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives.
この比較プラクティスの範囲が梯子と見なされる場合、次の議論は梯子を登ります。安価でありながら、誤ったネガを生成する可能性が比較的高いプラクティスから始め、計算コストが高く、リスクが低い人に進むことができます。偽のネガ。
If two IRIs, when considered as character strings, are identical, then it is safe to conclude that they are equivalent. This type of equivalence test has very low computational cost and is in wide use in a variety of applications, particularly in the domain of parsing. It is also used when a definitive answer to the question of IRI equivalence is needed that is independent of the scheme used and that can be calculated quickly and without accessing a network. An example of such a case is XML Namespaces ([XMLNamespace]).
2つの虹彩がキャラクター文字列と見なされる場合、同一である場合、それらが同等であると結論付けるのは安全です。このタイプの同等性テストは、計算コストが非常に低く、特に解析の領域ではさまざまなアプリケーションで広く使用されています。また、使用されるスキームに依存しないIRIの等価性の問題に対する決定的な答えが必要であり、ネットワークにアクセスせずに迅速かつ計算できる場合にも使用されます。そのような場合の例は、XMLネームスペース（[XMLNamesPace]）です。
Testing strings for equivalence requires some basic precautions. This procedure is often referred to as "bit-for-bit" or "byte-for-byte" comparison, which is potentially misleading. Testing strings for equality is normally based on pair comparison of the characters that make up the strings, starting from the first and proceeding until both strings are exhausted and all characters are found to be equal, until a pair of characters compares unequal, or until one of the strings is exhausted before the other.
等価性の文字列をテストするには、いくつかの基本的な予防策が必要です。この手順は、多くの場合、「ビット」または「バイトフォーバイト」の比較と呼ばれ、誤解を招く可能性があります。平等のテスト文字列は通常、文字列を構成する文字のペア比較に基づいています。最初から始まり、両方の文字列が使い果たされ、すべての文字が等しくなることが判明するまで、一対の文字が不平等になるか、1つまで比較されるまで、弦の前で弦が疲れます。
This character comparison requires that each pair of characters be put in comparable encoding form. For example, should one IRI be stored in a byte array in UTF-8 encoding form and the second in a UTF-16 encoding form, bit-for-bit comparisons applied naively will produce errors. It is better to speak of equality on a character-for-character rather than on a byte-for-byte or bit-for-bit basis. In practical terms, character-by-character comparisons should be done codepoint by codepoint after conversion to a common character encoding form. When comparing character by character, the comparison function MUST NOT map IRIs to URIs, because such a mapping would create additional spurious equivalences. It follows that an IRI SHOULD NOT be modified when being transported if there is any chance that this IRI might be used as an identifier.
このキャラクターの比較では、各ペアのペアを同等のエンコードフォームに配置する必要があります。たとえば、1つのIRIがUTF-8エンコードフォームのバイト配列に保存され、2番目がUTF-16エンコードフォームに保存された場合、ビットファービット比較は素朴にエラーを生成します。バイトフォーバイトまたはビットビットベースではなく、キャラクター用のキャラクターの平等について話す方が良いでしょう。実際には、文字ごとの比較は、一般的な文字エンコードフォームへの変換後、CodePointによってCodePointを実行する必要があります。キャラクターを文字で比較する場合、比較関数はIRISをURISにマッピングしてはなりません。このようなマッピングは追加の偽の等価性を作成するためです。この場合、このIRIが識別子として使用される可能性がある場合、輸送されるときはIRIを変更すべきではありません。
False negatives are caused by the production and use of IRI aliases. Unnecessary aliases can be reduced, regardless of the comparison method, by consistently providing IRI references in an already normalized form (i.e., a form identical to what would be produced after normalization is applied, as described below). Protocols and data formats often limit some IRI comparisons to simple string comparison, based on the theory that people and implementations will, in their own best interest, be consistent in providing IRI references, or at least be consistent enough to negate any efficiency that might be obtained from further normalization.
偽のネガは、IRIエイリアスの生産と使用によって引き起こされます。比較方法に関係なく、不必要なエイリアスは、すでに正規化された形式で一貫してIRI参照を提供することで削減できます（つまり、以下で説明するように、正規化後に生成されるものと同一の形式）。プロトコルとデータ形式は、多くの場合、IRIの比較を単純な文字列比較と制限することがよくあります。これは、人々と実装が自分自身の最大の関心事で、IRIの参照を提供することに一貫しているか、少なくともあらゆる効率を無効にするのに十分な一貫性があるという理論に基づいています。さらなる正規化から得られます。
Implementations may use logic based on the definitions provided by this specification to reduce the probability of false negatives. This processing is moderately higher in cost than character-for-character string comparison. For example, an application using this approach could reasonably consider the following two IRIs equivalent:
実装は、この仕様で提供された定義に基づいてロジックを使用して、偽のネガの確率を低下させる場合があります。この処理は、キャラクターフォーキャラクターの文字列比較よりも中程度にコストが高くなっています。たとえば、このアプローチを使用するアプリケーションは、次の2つの虹彩に相当するものを合理的に考慮することができます。
example://a/b/c/%7Bfoo%7D/rosé
eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9
Web user agents, such as browsers, typically apply this type of IRI normalization when determining whether a cached response is available. Syntax-based normalization includes such techniques as case normalization, character normalization, percent-encoding normalization, and removal of dot-segments.
ブラウザなどのWebユーザーエージェントは、通常、キャッシュされた応答が利用可能かどうかを判断するときに、このタイプのIRI正規化を適用します。構文ベースの正規化には、ケースの正規化、文字正規化、パーセントエンコード正規化、ドットセグメントの除去などの手法が含まれます。
For all IRIs, the hexadecimal digits within a percent-encoding triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore should be normalized to use uppercase letters for the digits A - F.
すべての虹彩の場合、パーセントエンコードトリプレット内の16進数（たとえば、 "％3a"対 "％3a"）は大文字と小文字を区別するため、数字a-fに大文字を使用するように正規化する必要があります。
When an IRI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and US-ASCII only host are case insensitive and therefore should be normalized to lowercase. For example, the URI "HTTP://www.EXAMPLE.com/" is equivalent to "http://www.example.com/". Case equivalence for non-ASCII characters in IRI components that are IDNs are discussed in section 5.3.3. The other generic syntax components are assumed to be case sensitive unless specifically defined otherwise by the scheme.
IRIが一般的な構文のコンポーネントを使用する場合、コンポーネント構文の等価ルールが常に適用されます。つまり、スキームとUS-ASCIIのみが症例の鈍感であり、したがって小文字に正規化する必要があります。たとえば、uri "http://www.example.com/"は「http://www.example.com/」に相当します。IDNであるIRIコンポーネントの非ASCII文字のケース等価性については、セクション5.3.3で説明します。他の一般的な構文コンポーネントは、スキームによって特別に定義されていない限り、ケースに敏感であると想定されます。
Creating schemes that allow case-insensitive syntax components containing non-ASCII characters should be avoided. Case normalization of non-ASCII characters can be culturally dependent and is always a complex operation. The only exception concerns non-ASCII host names for which the character normalization includes a mapping step derived from case folding.
非ASCII文字を含むケースに依存しない構文コンポーネントを可能にするスキームを作成することは避ける必要があります。非ASCII文字の症例正規化は文化的に依存する可能性があり、常に複雑な操作です。唯一の例外は、文字の正規化にケースの折りたたみから派生したマッピングステップが含まれる非ASCIIホスト名に関するものです。
The Unicode Standard [UNIV4] defines various equivalences between sequences of characters for various purposes. Unicode Standard Annex #15 [UTR15] defines various Normalization Forms for these equivalences, in particular Normalization Form C (NFC, Canonical Decomposition, followed by Canonical Composition) and Normalization Form KC (NFKC, Compatibility Decomposition, followed by Canonical Composition).
Unicode標準[UNIV4]は、さまざまな目的で文字のシーケンス間のさまざまな等価性を定義します。Unicode Standard Annex＃15 [UTR15]は、これらの等価性のさまざまな正規化形式、特に正規化形式C（NFC、標準分解、続いて標準組成）および正規化形式KC（NFKC、互換性分解、それに続く標準組成）を定義します。
Equivalence of IRIs MUST rely on the assumption that IRIs are appropriately pre-character-normalized rather than apply character normalization when comparing two IRIs. The exceptions are conversion from a non-digital form, and conversion from a non-UCS-based character encoding to a UCS-based character encoding. In these cases, NFC or a normalizing transcoder using NFC MUST be used for interoperability. To avoid false negatives and problems with transcoding, IRIs SHOULD be created by using NFC. Using NFKC may avoid even more problems; for example, by choosing half-width Latin letters instead of full-width ones, and full-width instead of half-width Katakana.
IRISの同等性は、2つのIRIを比較するときに文字の正規化を適用するのではなく、IRISが適切に特徴的な正規化されているという仮定に依存する必要があります。例外は、非デジタル形式からの変換、および非UCSベースの文字エンコードからUCSベースの文字エンコードへの変換です。これらの場合、NFCまたはNFCを使用した正規化トランスコダーを相互運用性に使用する必要があります。誤ったネガティブやトランスコーディングの問題を回避するには、NFCを使用して虹彩を作成する必要があります。NFKCを使用すると、さらに多くの問題が回避される場合があります。たとえば、完全な幅の手紙の代わりに半幅のラテン文字を選択し、半幅のカタカナの代わりに全幅を選択することにより。
As an example, "http://www.example.org/résumé.html" (in XML Notation) is in NFC. On the other hand, "http://www.example.org/résumé.html" is not in NFC.
例として、「http://www.example.org/ré sumé.html」（xml Notation）はNFCにあります。一方、「http://www.example.org/RÉ sumé.html」はNFCではありません。
The former uses precombined e-acute characters, and the latter uses "e" characters followed by combining acute accents. Both usages are defined as canonically equivalent in [UNIV4].
前者は、前駆的な電子急性キャラクターを使用し、後者は「E」文字を使用して、その後の急性アクセントを組み合わせます。両方の使用法は、[UNIV4]で正規に同等であると定義されています。
Note: Because it is unknown how a particular sequence of characters is being treated with respect to character normalization, it would be inappropriate to allow third parties to normalize an IRI arbitrarily. This does not contradict the recommendation that when a resource is created, its IRI should be as character normalized as possible (i.e., NFC or even NFKC). This is similar to the uppercase/lowercase problems. Some parts of a URI are case insensitive (domain name). For others, it is unclear whether they are case sensitive, case insensitive, or something in between (e.g., case sensitive, but with a multiple choice selection if the wrong case is used, instead of a direct negative result). The best recipe is that the creator use a reasonable capitalization and, when transferring the URI, capitalization never be changed.
注：特定の一連の文字が文字の正規化に関してどのように扱われているかは不明であるため、第三者がIRIを任意に正規化できるようにすることは不適切です。これは、リソースが作成されたときに、IRIが可能な限り文字を正規化する（つまり、NFCまたはNFKC）であるという勧告と矛盾するものではありません。これは、大文字/小文字の問題に似ています。URIの一部は、症例の鈍感（ドメイン名）です。他の人にとっては、それらが症例に敏感であるか、症例の鈍感であるか、またはその間の何かであるかは不明です（たとえば、ケースに敏感ですが、直接的な負の結果ではなく、間違ったケースが使用される場合は多肢選択の選択があります）。最良のレシピは、作成者が合理的な大文字化を使用し、URIを転送するときに資本化が変更されないことです。
Various IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in the ireg-name part or elsewhere. Character Normalization also applies to IDNs, as discussed in section 5.3.3.
さまざまなIRIスキームでは、IREG名またはその他の場所で、国際化ドメイン名（IDN）[RFC3490]の使用を許可する場合があります。セクション5.3.3で説明したように、文字の正規化もIDNに適用されます。
The percent-encoding mechanism (section 2.1 of [RFC3986]) is a frequent source of variance among otherwise identical IRIs. In addition to the case normalization issue noted above, some IRI producers percent-encode octets that do not require percent-encoding, resulting in IRIs that are equivalent to their non encoded counterparts. These IRIs should be normalized by decoding any percent-encoded octet sequence that corresponds to an unreserved character, as described in section 2.3 of [RFC3986].
パーセントエンコードメカニズム（[RFC3986]のセクション2.1）は、それ以外の場合は同一の虹彩の間で頻繁に分散源です。上記の場合の正規化の問題に加えて、一部のIRIプロデューサーはパーセントエンコードを必要としないパーセントエンコードオクテットであり、その結果、非エンコードされた対応物と同等のIRIが生じます。これらの虹彩は、[RFC3986]のセクション2.3で説明されているように、予約されていない文字に対応するパーセントエンコードのオクテットシーケンスをデコードすることにより正規化する必要があります。
For actual resolution, differences in percent-encoding (except for the percent-encoding of reserved characters) MUST always result in the same resource. For example, "http://example.org/~user", "http://example.org/%7euser", and "http://example.org/%7Euser", must resolve to the same resource.
実際の解像度では、パーセントエンコードの違い（予約された文字のパーセントエンコードを除く）は、常に同じリソースをもたらす必要があります。たとえば、「http://example.org/~user」、「http://example.org/%7euser」、および「http://example.org/%7euser」は、同じリソースに解決する必要があります。
If this kind of equivalence is to be tested, the percent-encoding of both IRIs to be compared has to be aligned; for example, by converting both IRIs to URIs (see section 3.1), eliminating escape differences in the resulting URIs, and making sure that the case of the hexadecimal characters in the percent-encoding is always the same (preferably uppercase). If the IRI is to be passed to another application or used further in some other way, its original form MUST be preserved. The conversion described here should be performed only for local comparison.
この種の同等性をテストする場合、比較される両方の虹彩のエンコードパーセントを調整する必要があります。たとえば、両方のIRIをURISに変換し（セクション3.1を参照）、結果のURIの脱出の違いを排除し、パーセントエンコードの16進数文字のケースが常に同じであることを確認します（できれば大文字）。IRIが別のアプリケーションに渡される場合、または他の方法でさらに使用される場合、その元のフォームを保存する必要があります。ここで説明する変換は、ローカル比較のためにのみ実行する必要があります。
The complete path segments "." and ".." are intended only for use within relative references (section 4.1 of [RFC3986]) and are removed as part of the reference resolution process (section 5.2 of [RFC3986]). However, some implementations may incorrectly assume that reference resolution is not necessary when the reference is already an IRI, and thus fail to remove dot-segments when they occur in non-relative paths. IRI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in section 5.2.4 of [RFC3986].
完全なパスセグメント」。および「..」は、相対参照（[RFC3986]のセクション4.1）内でのみ使用することを目的としており、参照解決プロセスの一部（[RFC3986]のセクション5.2）の一部として削除されます。ただし、一部の実装では、参照がすでにIRIである場合、参照解像度が不要であると誤って想定している場合があり、したがって、非関連パスで発生する場合、ドットセグメントを削除できない場合があります。IRIノーマイザーは、[RFC3986]のセクション5.2.4で説明されているように、Remove_Dot_Segmentsアルゴリズムをパスに適用して、DOTセグメントを削除する必要があります。
The syntax and semantics of IRIs vary from scheme to scheme, as described by the defining specification for each scheme. Implementations may use scheme-specific rules, at further processing cost, to reduce the probability of false negatives. For example, because the "http" scheme makes use of an authority component, has a default port of "80", and defines an empty path to be equivalent to "/", the following four IRIs are equivalent:
虹彩の構文とセマンティクスは、各スキームの定義仕様によって説明されているように、スキームによって異なります。実装では、さらに処理コストでスキーム固有のルールを使用して、偽のネガの可能性を減らすことができます。たとえば、「http」スキームは権限コンポーネントを使用し、デフォルトのポート「80」を持ち、空のパスを「/」に相当すると定義するため、次の4つの虹彩は同等です。
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
In general, an IRI that uses the generic syntax for authority with an empty path should be normalized to a path of "/". Likewise, an explicit ":port", for which the port is empty or the default for the scheme, is equivalent to one where the port and its ":" delimiter are elided and thus should be removed by scheme-based normalization. For example, the second IRI above is the normal form for the "http" scheme.
一般に、空のパスを持つ権威に一般的な構文を使用するIRIは、「/」のパスに正規化する必要があります。同様に、明示的な「：ポート」は、ポートが空になっているか、スキームのデフォルトであるため、ポートとその "："デリミッターが排除されるため、スキームベースの正規化によって削除される必要があります。たとえば、上記の2番目のIRIは、「HTTP」スキームの通常のフォームです。
Another case where normalization varies by scheme is in the handling of an empty authority component or empty host subcomponent. For many scheme specifications, an empty authority or host is considered an error; for others, it is considered equivalent to "localhost" or the end-user's host. When a scheme defines a default for authority and an IRI reference to that default is desired, the reference should be normalized to an empty authority for the sake of uniformity, brevity, and internationalization. If, however, either the userinfo or port subcomponents are non-empty, then the host should be given explicitly even if it matches the default.
正規化がスキームによって変化する別のケースは、空の権限コンポーネントまたは空のホストサブコンポーネントの処理にあります。多くのスキーム仕様では、空の権限またはホストはエラーと見なされます。他の人にとっては、「LocalHost」またはエンドユーザーのホストに相当すると考えられています。スキームが当局のデフォルトを定義し、そのデフォルトへのIRI参照が望ましい場合、均一性、簡潔さ、国際化のために、参照は空の権限に正規化する必要があります。ただし、userInfoまたはポートサブコンポーネントのいずれかが空でない場合、デフォルトと一致する場合でも、ホストを明示的に指定する必要があります。
Normalization should not remove delimiters when their associated component is empty unless it is licensed to do so by the scheme specification. For example, the IRI "http://example.com/?" cannot be assumed to be equivalent to any of the examples above. Likewise, the presence or absence of delimiters within a userinfo subcomponent is usually significant to its interpretation. The fragment component is not subject to any scheme-based normalization; thus, two IRIs that differ only by the suffix "#" are considered different regardless of the scheme.
スキームの仕様によってライセンスを取得しない限り、関連コンポーネントが空になっている場合、正規化はデリミターを削除しないでください。たとえば、IRI「http://example.com/？」上記の例のいずれかと同等であると想定することはできません。同様に、userinfoサブコンポーネント内の区切り文字の有無は通常、その解釈にとって重要です。フラグメントコンポーネントは、スキームベースの正規化の対象ではありません。したがって、接尾辞「＃」によってのみ異なる2つの虹彩は、スキームに関係なく異なると見なされます。
Some IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in their ireg-name part or elsewhere. When in use in IRIs, those names SHOULD be validated by using the ToASCII operation defined in [RFC3490], with the flags "UseSTD3ASCIIRules" and "AllowUnassigned". An IRI containing an invalid IDN cannot successfully be resolved. Validated IDN components of IRIs SHOULD be character normalized by using the Nameprep process [RFC3491]; however, for legibility purposes, they SHOULD NOT be converted into ASCII Compatible Encoding (ACE).
一部のIRIスキームでは、IREG名の一部または他の場所で、国際化ドメイン名（IDN）[RFC3490]の使用を許可する場合があります。IRISで使用している場合、[RFC3490]で定義されたToascii操作を使用して、「usestd3asciirules」および「loplunassigned」を使用して、これらの名前を検証する必要があります。無効なIDNを含むIRIは正常に解決できません。IRISの検証されたIDNコンポーネントは、NAMEPREPプロセス[RFC3491]を使用して文字正規化する必要があります。ただし、読みやすさのために、それらはASCII互換のエンコード（ACE）に変換されるべきではありません。
Scheme-based normalization may also consider IDN components and their conversions to punycode as equivalent. As an example, "http://résumé.example.org" may be considered equivalent to "http://xn--rsum-bpad.example.org".
スキームベースの正規化では、IDNコンポーネントとそのパニコードへの変換を同等と見なす場合もあります。例として、「http：// r＆＃xe9; sum＆＃xe9; .example.org」は「http://xn - rsum-bpad.example.org」に相当すると見なされる場合があります。
Other scheme-specific normalizations are possible.
他のスキーム固有の正常化が可能です。
Substantial effort to reduce the incidence of false negatives is often cost-effective for web spiders. Consequently, they implement even more aggressive techniques in IRI comparison. For example, if they observe that an IRI such as
偽陰性の発生率を減らすための実質的な努力は、多くの場合、Webスパイダーにとって費用対効果が高くなります。その結果、彼らはIRI比較にさらに積極的な手法を実装します。たとえば、彼らがそのようなIRIが
http://example.com/data
redirects to an IRI differing only in the trailing slash
後続のスラッシュでのみ異なるIRIにリダイレクト
http://example.com/data/
they will likely regard the two as equivalent in the future. This kind of technique is only appropriate when equivalence is clearly indicated by both the result of accessing the resources and the common conventions of their scheme's dereference algorithm (in this case, use of redirection by HTTP origin servers to avoid problems with relative references).
彼らはおそらく2つを将来同等と見なすでしょう。この種の手法は、リソースにアクセスした結果とスキームの控えめなアルゴリズムの共通規則の両方によって明確に示される場合にのみ適切です（この場合、相対的な参照の問題を回避するためにHTTP起源サーバーによるリダイレクトの使用）。
This section discusses limitations on characters and character sequences usable for IRIs beyond those given in section 2.2 and section 4.1. The considerations in this section are relevant when IRIs are created and when URIs are converted to IRIs.
このセクションでは、セクション2.2およびセクション4.1に記載されているものを超えて、虹彩に使用可能な文字と文字シーケンスの制限について説明します。このセクションの考慮事項は、IRISが作成されたときとURIがIRISに変換されるときに関連します。
a. The repertoire of characters allowed in each IRI component is limited by the definition of that component. For example, the definition of the scheme component does not allow characters beyond US-ASCII.
a. 各IRIコンポーネントで許可されている文字のレパートリーは、そのコンポーネントの定義によって制限されます。たとえば、スキームコンポーネントの定義では、us-ascii以外の文字を許可しません。
(Note: In accordance with URI practice, generic IRI software cannot and should not check for such limitations.)
（注：URIプラクティスに従って、一般的なIRIソフトウェアは、そのような制限を確認することはできませんし、そうすべきではありません。）
b. The UCS contains many areas of characters for which there are strong visual look-alikes. Because of the likelihood of transcription errors, these also should be avoided. This includes the full-width equivalents of Latin characters, half-width Katakana characters for Japanese, and many others. It also includes many look-alikes of "space", "delims", and "unwise", characters excluded in [RFC3491].
b. UCSには、強力な視覚的な外観があるキャラクターの多くの領域が含まれています。転写エラーの可能性があるため、これらも避ける必要があります。これには、ラテン語のキャラクターの全幅相当物質、日本語の半幅のカタカナキャラクター、その他多くの幅が含まれます。また、[RFC3491]で除外された「スペース」、「デリム」、「賢明でない」の多くの外観が含まれます。
Additional information is available from [UNIXML]. [UNIXML] is written in the context of running text rather than in that of identifiers. Nevertheless, it discusses many of the categories of characters not appropriate for IRIs.
追加情報は[UNIXML]から入手できます。[UNIXML]は、識別子のテキストではなく、テキストを実行するコンテキストで書かれています。それにもかかわらず、それは虹彩に適していないキャラクターのカテゴリの多くについて説明しています。
Although an IRI is defined as a sequence of characters, software interfaces for URIs typically function on sequences of octets or other kinds of code units. Thus, software interfaces and protocols MUST define which character encoding is used.
IRIは文字のシーケンスとして定義されていますが、URIのソフトウェアインターフェイスは通常、オクテットまたは他の種類のコードユニットのシーケンスで機能します。したがって、ソフトウェアインターフェイスとプロトコルは、使用される文字エンコードを定義する必要があります。
Intermediate software interfaces between IRI-capable components and URI-only components MUST map the IRIs per section 3.1, when transferring from IRI-capable to URI-only components. This mapping SHOULD be applied as late as possible. It SHOULD NOT be applied between components that are known to be able to handle IRIs.
IRIに対応するコンポーネントとURIのみのコンポーネント間の中間ソフトウェアインターフェイスは、IRI対応コンポーネントにIRIのみのコンポーネントに転送する場合、セクション3.1ごとにIRIをマッピングする必要があります。このマッピングは、できるだけ遅く適用する必要があります。虹彩を処理できることが知られているコンポーネント間に適用されるべきではありません。
Document formats that transport URIs may have to be upgraded to allow the transport of IRIs. In cases where the document as a whole has a native character encoding, IRIs MUST also be encoded in this character encoding and converted accordingly by a parser or interpreter. IRI characters not expressible in the native character encoding SHOULD be escaped by using the escaping conventions of the document format if such conventions are available. Alternatively, they MAY be percent-encoded according to section 3.1. For example, in HTML or XML, numeric character references SHOULD be used. If a document as a whole has a native character encoding and that character encoding is not UTF-8, then IRIs MUST NOT be placed into the document in the UTF-8 character encoding.
URIを輸送するドキュメント形式は、虹彩の輸送を許可するためにアップグレードする必要がある場合があります。ドキュメント全体にネイティブキャラクターがエンコードされている場合、IRISもこのキャラクターでエンコードしてエンコードし、パーサーまたはインタープリターによってそれに応じて変換する必要があります。ネイティブキャラクターのエンコードで表現できないIRI文字は、そのような規則が利用可能な場合は、ドキュメント形式の脱出規則を使用して逃げる必要があります。あるいは、セクション3.1に従ってパーセントエンコードされる場合があります。たとえば、HTMLまたはXMLでは、数値文字参照を使用する必要があります。ドキュメント全体にネイティブの文字エンコードがあり、そのキャラクターエンコードがUTF-8ではない場合、IRISをUTF-8文字エンコードのドキュメントに配置する必要はありません。
Note: Some formats already accommodate IRIs, although they use different terminology. HTML 4.0 [HTML4] defines the conversion from IRIs to URIs as error-avoiding behavior. XML 1.0 [XML1], XLink [XLink], XML Schema [XMLSchema], and specifications based upon them allow IRIs. Also, it is expected that all relevant new W3C formats and protocols will be required to handle IRIs [CharMod].
注：いくつかのフォーマットはすでに虹彩に対応していますが、異なる用語を使用しています。HTML 4.0 [HTML4]は、IRISからURISへの変換をエラー回避動作として定義します。xml 1.0 [xml1]、xlink [xlink]、xml schema [xmlschema]、およびそれらに基づく仕様は虹彩を可能にします。また、虹彩を処理するには、関連するすべての新しいW3C形式とプロトコルが必要になることが予想されます[Charmod]。
This section discusses details and gives examples for point c) in section 1.2. To be able to use IRIs, the URI corresponding to the IRI in question has to encode original characters into octets by using UTF-8. This can be specified for all URIs of a URI scheme or can apply to individual URIs for schemes that do not specify how to encode original characters. It can apply to the whole URI, or only to some part. For background information on encoding characters into URIs, see also section 2.5 of [RFC3986].
このセクションでは、詳細について説明し、ポイントc）の例について説明します。セクション1.2。IRIを使用できるようにするには、問題のIRIに対応するURIは、UTF-8を使用して元の文字をオクテットにエンコードする必要があります。これは、URIスキームのすべてのURIに指定することも、元の文字をエンコードする方法を指定していないスキームを個々のURIに適用できます。URI全体、または一部にのみ適用できます。URISへの文字のエンコードに関する背景情報については、[RFC3986]のセクション2.5も参照してください。
For new URI schemes, using UTF-8 is recommended in [RFC2718]. Examples where UTF-8 is already used are the URN syntax [RFC2141], IMAP URLs [RFC2192], and POP URLs [RFC2384]. On the other hand, because the HTTP URL scheme does not specify how to encode original characters, only some HTTP URLs can have corresponding but different IRIs.
新しいURIスキームの場合、[RFC2718]でUTF-8を使用することをお勧めします。UTF-8がすでに使用されている例は、URN構文[RFC2141]、IMAP URL [RFC2192]、およびPOP URL [RFC2384]です。一方、HTTP URLスキームは元の文字をエンコードする方法を指定していないため、一部のHTTP URLのみが対応するが異なる虹彩を持つことができます。
For example, for a document with a URI of
"http://www.example.org/r%C3%A9sum%C3%A9.html", it is possible to
construct a corresponding IRI (in XML notation, see, section 1.4):
"http://www.example.org/résumé.html" ("é"; stands for
the e-acute character, and "%C3%A9" is the UTF-8 encoded and
percent-encoded representation of that character). On the other
hand, for a document with a URI of
"http://www.example.org/r%E9sum%E9.html", the percent-encoding octets cannot be converted to actual characters in an IRI, as the percent-encoding is not based on UTF-8.
「http://www.example.org/r%E9Sum%E9.html」、パーセントエンコードはUTF-8に基づいていないため、パーセントをエンコードするオクテットをIRIの実際の文字に変換することはできません。
This means that for most URI schemes, there is no need to upgrade their scheme definition in order for them to work with IRIs. The main case where upgrading makes sense is when a scheme definition, or a particular component of a scheme, is strictly limited to the use of US-ASCII characters with no provision to include non-ASCII characters/octets via percent-encoding, or if a scheme definition currently uses highly scheme-specific provisions for the encoding of non-ASCII characters. An example of this is the mailto: scheme [RFC2368].
これは、ほとんどのURIスキームでは、虹彩と協力するためにスキーム定義をアップグレードする必要がないことを意味します。アップグレードが理にかなっている主なケースは、スキーム定義、またはスキームの特定のコンポーネントが、パーセントエンコードを介して非ASCII文字/オクテットを含める規定のないUS-ASSII文字の使用に厳密に制限される場合、またはスキーム定義は現在、非ASCII文字のエンコードに非常にスキーム固有の規定を使用しています。この例は、Mailto：Scheme [RFC2368]です。
This specification does not upgrade any scheme specifications in any way; this has to be done separately. Also, note that there is no such thing as an "IRI scheme"; all IRIs use URI schemes, and all URI schemes can be used with IRIs, even though in some cases only by using URIs directly as IRIs, without any conversion.
この仕様では、スキームの仕様を決してアップグレードしません。これは別々に行う必要があります。また、「IRIスキーム」のようなものはないことに注意してください。すべての虹彩はURIスキームを使用し、場合によっては、虹彩として直接使用することによってのみ、変換なしでURIを使用することによってのみ、すべてのURIスキームを使用できます。
URI schemes can impose restrictions on the syntax of scheme-specific URIs; i.e., URIs that are admissible under the generic URI syntax [RFC3986] may not be admissible due to narrower syntactic constraints imposed by a URI scheme specification. URI scheme definitions cannot broaden the syntactic restrictions of the generic URI syntax; otherwise, it would be possible to generate URIs that satisfied the scheme-specific syntactic constraints without satisfying the syntactic constraints of the generic URI syntax. However, additional syntactic constraints imposed by URI scheme specifications are applicable to IRI, as the corresponding URI resulting from the mapping defined in section 3.1 MUST be a valid URI under the syntactic restrictions of generic URI syntax and any narrower restrictions imposed by the corresponding URI scheme specification.
URIスキームは、スキーム固有のURIの構文に制限を課すことができます。つまり、汎用URI構文[RFC3986]の下で認められるURIは、URIスキームの仕様によって課される狭い構文制約のために許容できない場合があります。URIスキームの定義は、一般的なURI構文の構文制限を拡大することはできません。それ以外の場合は、一般的なURI構文の構文制約を満たすことなく、スキーム固有の構文制約を満たしたURIを生成することが可能です。ただし、URIスキームの仕様によって課される追加の構文制約はIRIに適用されます。これは、セクション3.1で定義されているマッピングから生じる対応するURIが、一般的なURI構文の構文制限と対応するURIスキームによって課されるより狭い制限の下で有効なURIでなければならないため仕様。
The requirement for the use of UTF-8 applies to all parts of a URI (with the potential exception of the ireg-name part; see section 3.1). However, it is possible that the capability of IRIs to represent a wide range of characters directly is used just in some parts of the IRI (or IRI reference). The other parts of the IRI may only contain US-ASCII characters, or they may not be based on UTF-8. They may be based on another character encoding, or they may directly encode raw binary data (see also [RFC2397]).
UTF-8の使用の要件は、URIのすべての部分に適用されます（IREG-NAMEパーツを例外として潜在的に除き、セクション3.1を参照）。ただし、IRI（またはIRIリファレンス）の一部で直接幅広い文字を直接表現できるIRIの能力が使用される可能性があります。IRIの他の部分には、US-ASCII文字のみが含まれている場合があります。または、UTF-8に基づいていない場合があります。それらは、別の文字エンコードに基づいている場合があるか、生のバイナリデータを直接エンコードする場合があります（[RFC2397]も参照）。
For example, it is possible to have a URI reference of "http://www.example.org/r%E9sum%E9.xml#r%C3%A9sum%C3%A9", where the document name is encoded in iso-8859-1 based on server settings, but where the fragment identifier is encoded in UTF-8 according to
たとえば、「http://www.example.org/r%E9Sum%E9.xml#r%C3%A9Sum%C3%A9」のURI参照を持つことができます。文書名はISOでエンコードされています-8859-1サーバー設定に基づいていますが、フラグメント識別子がUTF-8でエンコードされている場合
[XPointer]. The IRI corresponding to the above URI would be (in XML notation) "http://www.example.org/r%E9sum%E9.xml#résumé";.
[xpointer]。上記のURIに対応するIRIは（XML表記で） "http://www.example.org/r%E9Sum%E9.xml#ré sumé";になります。
Similar considerations apply to query parts. The functionality of IRIs (namely, to be able to include non-ASCII characters) can only be used if the query part is encoded in UTF-8.
クエリパーツにも同様の考慮事項が適用されます。IRISの機能（つまり、ASCII以外の文字を含めることができる）は、クエリパーツがUTF-8でエンコードされている場合にのみ使用できます。
Processing of relative IRI references against a base is handled straightforwardly; the algorithms of [RFC3986] can be applied directly, treating the characters additionally allowed in IRI references in the same way that unreserved characters are in URI references.
ベースに対する相対的なIRI参照の処理は、簡単に処理されます。[rfc3986]のアルゴリズムは直接適用でき、未自由な文字がURI参照にあるのと同じように、IRI参照でさらに許可されている文字を扱うことができます。
This informative section provides guidelines for supporting IRIs in the same software components and operations that currently process URIs: Software interfaces that handle URIs, software that allows users to enter URIs, software that creates or generates URIs, software that displays URIs, formats and protocols that transport URIs, and software that interprets URIs. These may all require modification before functioning properly with IRIs. The considerations in this section also apply to URI references and IRI references.
この有益なセクションは、現在URIを処理する同じソフトウェアコンポーネントと操作でIRIをサポートするためのガイドラインを提供します。URIを処理するソフトウェアインターフェイス、ユーザーがURISを入力できるソフトウェア、URIを作成または生成するソフトウェア、URI、フォーマット、プロトコルを表示するソフトウェア、urisを輸送し、ウリスを解釈するソフトウェアを輸送します。これらはすべて、虹彩で適切に機能する前に変更を必要とする場合があります。このセクションの考慮事項は、URI参照とIRI参照にも適用されます。
Software interfaces that handle URIs, such as URI-handling APIs and protocols transferring URIs, need interfaces and protocol elements that are designed to carry IRIs.
URIハンドリングAPIやURIを転送するプロトコルなど、URIを処理するソフトウェアインターフェイスには、IRISを運ぶように設計されたインターフェイスとプロトコル要素が必要です。
In case the current handling in an API or protocol is based on US-ASCII, UTF-8 is recommended as the character encoding for IRIs, as it is compatible with US-ASCII, is in accordance with the recommendations of [RFC2277], and makes converting to URIs easy. In any case, the API or protocol definition must clearly define the character encoding to be used.
APIまたはプロトコルでの現在の取り扱いがUS-ASCIIに基づいている場合、UTF-8は、US-ASCIIと互換性があるため、IRISのキャラクターをエンコードすることで推奨され、[RFC2277]の推奨事項に従っています。URIへの変換を簡単にします。いずれにせよ、APIまたはプロトコル定義は、使用する文字エンコードを明確に定義する必要があります。
The transfer from URI-only to IRI-capable components requires no mapping, although the conversion described in section 3.2 above may be performed. It is preferable not to perform this inverse conversion when there is a chance that this cannot be done correctly.
URIのみからIRI対応コンポーネントへの転送にはマッピングは不要ですが、上記のセクション3.2で説明した変換は実行できます。これが正しく行われない可能性がある場合、この逆変換を実行しないことが望ましいです。
Some components allow users to enter URIs into the system by typing or dictation, for example. This software must be updated to allow for IRI entry.
一部のコンポーネントにより、ユーザーは、たとえばタイピングやディクテーションによってURISをシステムに入力できます。このソフトウェアは、IRIエントリを許可するために更新する必要があります。
A person viewing a visual representation of an IRI (as a sequence of glyphs, in some order, in some visual display) or hearing an IRI will use an entry method for characters in the user's language to input the IRI. Depending on the script and the input method used, this may be a more or less complicated process.
IRIの視覚的表現を見ている人（一連のグリフとして、ある順序で、ある程度の視覚的なディスプレイで）またはIRIを聞いて、ユーザーの言語のキャラクターに入力方法を使用してIRIを入力します。スクリプトと使用される入力方法に応じて、これは多かれ少なかれ複雑なプロセスである可能性があります。
The process of IRI entry must ensure, as much as possible, that the restrictions defined in section 2.2 are met. This may be done by choosing appropriate input methods or variants/settings thereof, by appropriately converting the characters being input, by eliminating characters that cannot be converted, and/or by issuing a warning or error message to the user.
IRIエントリのプロセスは、セクション2.2で定義されている制限が満たされていることを可能な限り確保する必要があります。これは、適切な入力メソッドまたはそのバリエーション/設定を選択すること、入力である文字を適切に変換すること、変換できない文字を排除すること、および/またはユーザーに警告またはエラーメッセージを発行することによって行うことができます。
As an example of variant settings, input method editors for East Asian Languages usually allow the input of Latin letters and related characters in full-width or half-width versions. For IRI input, the input method editor should be set so that it produces half-width Latin letters and punctuation and full-width Katakana.
バリアント設定の例として、東アジア言語の入力メソッドエディターは通常、全幅または半幅のバージョンでラテン文字と関連文字の入力を許可します。IRI入力の場合、入力メソッドエディターを設定して、半幅のラテン文字と句読点と全幅のカタカナを生成する必要があります。
An input field primarily or solely used for the input of URIs/IRIs may allow the user to view an IRI as it is mapped to a URI. Places where the input of IRIs is frequent may provide the possibility for viewing an IRI as mapped to a URI. This will help users when some of the software they use does not yet accept IRIs.
主にURI/IRISの入力に使用される入力フィールドは、ユーザーがURIにマッピングされているときにIRIを表示できる場合があります。虹彩の入力が頻繁に発生する場所は、URIにマッピングされたIRIを表示する可能性を提供する場合があります。これは、使用するソフトウェアの一部がまだIRISを受け入れない場合にユーザーに役立ちます。
An IRI input component interfacing to components that handle URIs, but not IRIs, must map the IRI to a URI before passing it to these components.
IRIではなくURIを処理するコンポーネントにインターフェースするIRI入力コンポーネントは、これらのコンポーネントに渡す前に、IRIをURIにマッピングする必要があります。
For the input of IRIs with right-to-left characters, please see section 4.3.
右から左の文字を持つ虹彩の入力については、セクション4.3を参照してください。
Many applications, particularly mail user agents, try to detect URIs appearing in plain text. For this, they use some heuristics based on URI syntax. They then allow the user to click on such URIs and retrieve the corresponding resource in an appropriate (usually scheme-dependent) application.
多くのアプリケーション、特にメールユーザーエージェントは、プレーンテキストに表示されるURIを検出しようとします。このために、彼らはURI構文に基づいていくつかのヒューリスティックを使用します。次に、ユーザーがそのようなURIをクリックし、適切な（通常はスキーム依存）アプリケーションで対応するリソースを取得できるようにします。
Such applications have to be upgraded to use the IRI syntax as a base for heuristics. In particular, a non-ASCII character should not be taken as the indication of the end of an IRI. Such applications also have to make sure that they correctly convert the detected IRI from the character encoding of the document or application where the IRI appears to the character encoding used by the system-wide IRI invocation mechanism, or to a URI (according to section 3.1) if the system-wide invocation mechanism only accepts URIs.
このようなアプリケーションは、IRI構文をヒューリスティックのベースとして使用するためにアップグレードする必要があります。特に、非ASCIIキャラクターをIRIの終わりの兆候とみなすべきではありません。このようなアプリケーションは、検出されたIRIを、IRIがシステム全体のIRI呼び出しメカニズムによって使用される文字エンコードまたはURIに表示される文書またはアプリケーションのキャラクターエンコードから正しく変換することを確認する必要があります（セクション3.1による）システム全体の呼び出しメカニズムがURIのみを受け入れる場合。
The clipboard is another frequently used way to transfer URIs and IRIs from one application to another. On most platforms, the clipboard is able to store and transfer text in many languages and scripts. Correctly used, the clipboard transfers characters, not bytes, which will do the right thing with IRIs.
クリップボードは、ウリと虹彩をあるアプリケーションに別のアプリケーションに転送するためのもう1つの頻繁に使用される方法です。ほとんどのプラットフォームでは、クリップボードは多くの言語やスクリプトでテキストを保存および転送することができます。正しく使用されているクリップボードは、バイトではなく文字を転送し、虹彩で正しいことをします。
Systems that offer resources through the Internet, where those resources have logical names, sometimes automatically generate URIs for the resources they offer. For example, some HTTP servers can generate a directory listing for a file directory and then respond to the generated URIs with the files.
これらのリソースが論理名を持っているインターネットを通じてリソースを提供するシステムは、提供するリソースのURIを自動的に生成することがあります。たとえば、一部のHTTPサーバーは、ファイルディレクトリのディレクトリリストを生成し、ファイルを使用して生成されたURIに応答できます。
Many legacy character encodings are in use in various file systems. Many currently deployed systems do not transform the local character representation of the underlying system before generating URIs.
さまざまなファイルシステムで多くのレガシーキャラクターエンコーディングが使用されています。現在展開されているシステムの多くは、URIを生成する前に、基礎となるシステムのローカル文字表現を変換しません。
For maximum interoperability, systems that generate resource identifiers should make the appropriate transformations. For example, if a file system contains a file named "résumé.html", a server should expose this as "r%C3%A9sum%C3%A9.html" in a URI, which allows use of "résumé.html" in an IRI, even if locally the file name is kept in a character encoding other than UTF-8.
相互運用性を最大限にするために、リソース識別子を生成するシステムは適切な変換を行う必要があります。たとえば、ファイルシステムに「r＆＃xe9; sum＆＃xe9; .html」という名前のファイルが含まれている場合、サーバーはこれを「r％c3％a9sum％c3％a9.html」として公開する必要があります。IRIの「R＆＃xe9; sum＆＃xe9; .html」の局所的に、ファイル名がUTF-8以外の文字エンコードに保持されていても。
This recommendation particularly applies to HTTP servers. For FTP servers, similar considerations apply; see [RFC2640].
この推奨事項は、特にHTTPサーバーに適用されます。FTPサーバーには、同様の考慮事項が適用されます。[RFC2640]を参照してください。
In some cases, resource owners and publishers have control over the IRIs used to identify their resources. This control is mostly executed by controlling the resource names, such as file names, directly.
場合によっては、リソースの所有者と出版社は、リソースを特定するために使用されるIRIを管理しています。このコントロールは、主にファイル名などのリソース名を直接制御することにより実行されます。
In these cases, it is recommended to avoid choosing IRIs that are easily confused. For example, for US-ASCII, the lower-case ell ("l") is easily confused with the digit one ("1"), and the upper-case oh ("O") is easily confused with the digit zero ("0"). Publishers should avoid confusing users with "br0ken" or "1ame" identifiers.
これらの場合、混乱しやすい虹彩の選択を避けることをお勧めします。たとえば、us-asciiの場合、低ケースのエル（ "l"）は数字（ "1"）と簡単に混同され、上部ケースのOH（ "o"）は数字ゼロ（ "o"）と簡単に混同されます（「0」）。出版社は、ユーザーを「BR0KEN」または「1AME」識別子と混同しないようにする必要があります。
Outside the US-ASCII repertoire, there are many more opportunities for confusion; a complete set of guidelines is too lengthy to include here. As long as names are limited to characters from a single script, native writers of a given script or language will know best when ambiguities can appear, and how they can be avoided. What may look ambiguous to a stranger may be completely obvious to the average native user. On the other hand, in some cases, the UCS contains variants for compatibility reasons; for example, for typographic purposes. These should be avoided wherever possible. Although there may be exceptions, newly created resource names should generally be in NFKC [UTR15] (which means that they are also in NFC).
米国ASCIIレパートリー以外では、混乱の機会がさらにたくさんあります。ガイドラインの完全なセットは、ここに含めるには長すぎます。名前が単一のスクリプトの文字に限定されている限り、特定のスクリプトまたは言語のネイティブライターは、曖昧さが表示されることと、それらを避ける方法を最もよく知るでしょう。見知らぬ人に曖昧に見えるかもしれないものは、平均的なネイティブユーザーにとって完全に明白かもしれません。一方、場合によっては、UCSには互換性の理由でバリアントが含まれています。たとえば、誤字の目的で。これらは可能な限り避けるべきです。例外があるかもしれませんが、新しく作成されたリソース名は一般にNFKC [UTR15]にある必要があります（つまり、それらもNFCにあることを意味します）。
As an example, the UCS contains the "fi" ligature at U+FB01 for compatibility reasons. Wherever possible, IRIs should use the two letters "f" and "i" rather than the "fi" ligature. An example where the latter may be used is in the query part of an IRI for an explicit search for a word written containing the "fi" ligature.
例として、UCSには、互換性の理由でU FB01の「FI」結紮が含まれています。可能な限り、Irisは「Fi」のligatureではなく2文字「F」と「I」を使用する必要があります。後者を使用できる例は、「fi」結晶を含む単語を明示的に検索するために、IRIのクエリ部分にあります。
In certain cases, there is a chance that characters from different scripts look the same. The best known example is the similarity of the Latin "A", the Greek "Alpha", and the Cyrillic "A". To avoid such cases, only IRIs should be created where all the characters in a single component are used together in a given language. This usually means that all of these characters will be from the same script, but there are languages that mix characters from different scripts (such as Japanese). This is similar to the heuristics used to distinguish between letters and numbers in the examples above. Also, for Latin, Greek, and Cyrillic, using lowercase letters results in fewer ambiguities than using uppercase letters would.
特定の場合、異なるスクリプトのキャラクターが同じように見える可能性があります。最もよく知られている例は、ラテン語の「A」、ギリシャ語の「アルファ」、キリルの「A」の類似性です。そのような場合を避けるために、単一のコンポーネント内のすべての文字が特定の言語で一緒に使用される場合、虹彩のみを作成する必要があります。これは通常、これらの文字はすべて同じスクリプトからのものであることを意味しますが、異なるスクリプト（日本語など）の文字を混ぜる言語があります。これは、上記の例で文字と数字を区別するために使用されるヒューリスティックに似ています。また、ラテン語、ギリシャ語、キリル語の場合、小文字を使用すると、大文字を使用するよりも曖昧さが少なくなります。
In situations where the rendering software is not expected to display non-ASCII parts of the IRI correctly using the available layout and font resources, these parts should be percent-encoded before being displayed.
レンダリングソフトウェアが利用可能なレイアウトとフォントリソースを使用してIRIの非ASCII部分を正しく表示するとは期待されていない状況では、これらの部品は表示される前にパーセントエンコードする必要があります。
For display of Bidi IRIs, please see section 4.1.
Bidi Irisの表示については、セクション4.1を参照してください。
Software that interprets IRIs as the names of local resources should accept IRIs in multiple forms and convert and match them with the appropriate local resource names.
IRISをローカルリソースの名前として解釈するソフトウェアは、複数の形式でIRISを受け入れ、適切なローカルリソース名と変換して一致させる必要があります。
First, multiple representations include both IRIs in the native character encoding of the protocol and also their URI counterparts.
第一に、複数の表現には、プロトコルのネイティブ文字エンコードの両方の虹彩と、そのURIのカウンターパートが含まれます。
Second, it may include URIs constructed based on character encodings other than UTF-8. These URIs may be produced by user agents that do not conform to this specification and that use legacy character encodings to convert non-ASCII characters to URIs. Whether this is necessary, and what character encodings to cover, depends on a number of factors, such as the legacy character encodings used locally and the distribution of various versions of user agents. For example, software for Japanese may accept URIs in Shift_JIS and/or EUC-JP in addition to UTF-8.
第二に、UTF-8以外の文字エンコーディングに基づいて構築されたURIが含まれる場合があります。これらのURIは、この仕様に準拠せず、レガシー文字エンコーディングを使用して非ASCII文字をURISに変換するユーザーエージェントによって生成される場合があります。これが必要かどうか、およびカバーするキャラクターエンコーディングは、ローカルで使用されるレガシー文字エンコーディングや、ユーザーエージェントのさまざまなバージョンの分布など、多くの要因に依存します。たとえば、日本語用のソフトウェアは、UTF-8に加えて、Shift_jisおよび/またはEUC-JPでURIを受け入れる場合があります。
Third, it may include additional mappings to be more user-friendly and robust against transmission errors. These would be similar to how some servers currently treat URIs as case insensitive or perform additional matching to account for spelling errors. For characters beyond the US-ASCII repertoire, this may, for example, include ignoring the accents on received IRIs or resource names. Please note that such mappings, including case mappings, are language dependent.
第三に、送信エラーに対してよりユーザーフレンドリーで堅牢になるために、追加のマッピングが含まれる場合があります。これらは、一部のサーバーが現在URIを症例の不感性として扱うか、スペルミスを説明するために追加のマッチングを実行する方法と類似しています。米国ASCIIレパートリーを超えたキャラクターの場合、これには、受信した虹彩またはリソース名のアクセントを無視することが含まれます。ケースマッピングを含むそのようなマッピングは言語に依存していることに注意してください。
It can be difficult to identify a resource unambiguously if too many mappings are taken into consideration. However, percent-encoded and not percent-encoded parts of IRIs can always be clearly distinguished. Also, the regularity of UTF-8 (see [Duerst97]) makes the potential for collisions lower than it may seem at first.
あまりにも多くのマッピングが考慮されている場合、リソースを明確に識別することは困難です。ただし、IRISの割合ではないパーセントではない部分は、常に明確に区別できます。また、UTF-8の規則性（[duerst97]を参照）は、衝突の可能性が最初に見えるよりも低くなります。
Where this recommendation places further constraints on software for which many instances are already deployed, it is important to introduce upgrades carefully and to be aware of the various interdependencies.
この推奨事項が、多くのインスタンスが既に展開されているソフトウェアにさらに制約がある場合、アップグレードを慎重に導入し、さまざまな相互依存関係を認識することが重要です。
If IRIs cannot be interpreted correctly, they should not be created, generated, or transported. This suggests that upgrading URI interpreting software to accept IRIs should have highest priority.
虹彩を正しく解釈できない場合、それらを作成、生成、または輸送しないでください。これは、URI通訳ソフトウェアをアップグレードしてIRISを受け入れることは、最優先事項が最も高いことを示唆しています。
On the other hand, a single IRI is interpreted only by a single or very few interpreters that are known in advance, although it may be entered and transported very widely.
一方、単一のIRIは、事前に知られている単一または非常に少数の通訳者によってのみ解釈されますが、非常に広く輸送される可能性があります。
Therefore, IRIs benefit most from a broad upgrade of software to be able to enter and transport IRIs. However, before an individual IRI is published, care should be taken to upgrade the corresponding interpreting software in order to cover the forms expected to be received by various versions of entry and transport software.
したがって、IRISは、虹彩に参加して輸送できるようにするために、ソフトウェアの広範なアップグレードから最も恩恵を受けます。ただし、個々のIRIが公開される前に、エントリーおよびトランスポートソフトウェアのさまざまなバージョンが受信すると予想されるフォームをカバーするために、対応する通訳ソフトウェアをアップグレードするように注意する必要があります。
The upgrade of generating software to generate IRIs instead of using a local character encoding should happen only after the service is upgraded to accept IRIs. Similarly, IRIs should only be generated when the service accepts IRIs and the intervening infrastructure and protocol is known to transport them safely.
ローカル文字エンコードを使用する代わりに、虹彩を生成するソフトウェアの生成のアップグレードは、サービスがIRISを受け入れるためにアップグレードされた後にのみ発生する必要があります。同様に、IRISは、サービスがIRISを受け入れ、介在するインフラストラクチャとプロトコルが安全に輸送されることが知られている場合にのみ生成される必要があります。
Software converting from URIs to IRIs for display should be upgraded only after upgraded entry software has been widely deployed to the population that will see the displayed result.
URISからIRISにディスプレイのために変換するソフトウェアは、アップグレードされたエントリソフトウェアが表示された結果が表示される母集団に広く展開された後にのみアップグレードする必要があります。
Where there is a free choice of character encodings, it is often possible to reduce the effort and dependencies for upgrading to IRIs by using UTF-8 rather than another encoding. For example, when a new file-based Web server is set up, using UTF-8 as the character encoding for file names will make the transition to IRIs easier. Likewise, when a new Web form is set up using UTF-8 as the character encoding of the form page, the returned query URIs will use UTF-8 as the character encoding (unless the user, for whatever reason, changes the character encoding) and will therefore be compatible with IRIs.
キャラクターエンコーディングの自由な選択がある場合、他のエンコードではなくUTF-8を使用してIRISにアップグレードするための努力と依存関係を減らすことができることがよくあります。たとえば、新しいファイルベースのWebサーバーが設定されている場合、ファイル名のキャラクターエンコードとしてUTF-8を使用すると、IRISへの移行が容易になります。同様に、フォームページの文字エンコードとしてUTF-8を使用して新しいWebフォームを設定すると、返されたクエリURISはUTF-8を文字エンコードとして使用します（ユーザーが何らかの理由で、文字エンコードを変更しない限り）したがって、虹彩と互換性があります。
These recommendations, when taken together, will allow for the extension from URIs to IRIs in order to handle characters other than US-ASCII while minimizing interoperability problems. For considerations regarding the upgrade of URI scheme definitions, see section 6.4.
これらの推奨事項は、一緒になった場合、US-ASCII以外の文字を処理しながら相互運用性の問題を最小限に抑えるために、URIからIRISへの拡張を可能にします。URIスキーム定義のアップグレードに関する考慮事項については、セクション6.4を参照してください。
The security considerations discussed in [RFC3986] also apply to IRIs. In addition, the following issues require particular care for IRIs.
[RFC3986]で説明されているセキュリティ上の考慮事項もIRISに適用されます。さらに、以下の問題には、虹彩の特定のケアが必要です。
Incorrect encoding or decoding can lead to security problems. In particular, some UTF-8 decoders do not check against overlong byte sequences. As an example, a "/" is encoded with the byte 0x2F both in UTF-8 and in US-ASCII, but some UTF-8 decoders also wrongly interpret the sequence 0xC0 0xAF as a "/". A sequence such as
エンコードまたはデコードが誤っていない可能性があり、セキュリティの問題につながる可能性があります。特に、一部のUTF-8デコーダは、長いバイトシーケンスに対してチェックしません。例として、「/」はUTF-8とUS-ASCIIの両方でバイト0x2Fでエンコードされますが、一部のUTF-8デコーダは、シーケンス0xc0 0xafを "/"として誤って解釈します。次のようなシーケンス
"%C0%AF.." may pass some security tests and then be interpreted as "/.." in a path if UTF-8 decoders are fault-tolerant, if conversion and checking are not done in the right order, and/or if reserved characters and unreserved characters are not clearly distinguished.
「％C0％AF ..」は、いくつかのセキュリティテストに合格し、UTF-8デコーダがフォールトトレラントである場合、パスで「/..」と解釈される場合があります。または、予約済みのキャラクターや予約されていないキャラクターが明確に区別されない場合。
There are various ways in which "spoofing" can occur with IRIs. "Spoofing" means that somebody may add a resource name that looks the same or similar to the user, but that points to a different resource. The added resource may pretend to be the real resource by looking very similar but may contain all kinds of changes that may be difficult to spot and that can cause all kinds of problems. Most spoofing possibilities for IRIs are extensions of those for URIs.
「スプーフィング」が虹彩で発生する可能性のあるさまざまな方法があります。「スプーフィング」とは、誰かがユーザーと同じまたは類似しているが、異なるリソースを指しているリソース名を追加することを意味します。追加されたリソースは、非常に似ているように見えることで実際のリソースのふりをするかもしれませんが、見つけるのが難しく、あらゆる種類の問題を引き起こす可能性のあるあらゆる種類の変更が含まれる場合があります。虹彩のほとんどのスプーフィングの可能性は、URIの拡張です。
Spoofing can occur for various reasons. First, a user's normalization expectations or actual normalization when entering an IRI or transcoding an IRI from a legacy character encoding do not match the normalization used on the server side. Conceptually, this is no different from the problems surrounding the use of case-insensitive web servers. For example, a popular web page with a mixed-case name ("http://big.example.com/PopularPage.html") might be "spoofed" by someone who is able to create "http://big.example.com/popularpage.html". However, the use of unnormalized character sequences, and of additional mappings for user convenience, may increase the chance for spoofing. Protocols and servers that allow the creation of resources with names that are not normalized are particularly vulnerable to such attacks. This is an inherent security problem of the relevant protocol, server, or resource and is not specific to IRIs, but it is mentioned here for completeness.
さまざまな理由でスプーフィングが発生する可能性があります。まず、IRIを入力したり、レガシー文字エンコードからIRIをトランスコードするときのユーザーの正規化の期待または実際の正規化は、サーバー側で使用される正規化と一致しません。概念的には、これは、ケースに依存しないWebサーバーの使用を取り巻く問題と違いはありません。たとえば、混合ケース名を持つ人気のあるWebページ（ "http://big.example.com/popularpage.html"）は、「http：//big.exampleを作成できる人が「スプーフィング」する可能性があります。.com/popularPage.html "。ただし、非正規化された文字シーケンスの使用、およびユーザーの利便性のための追加のマッピングの使用により、スプーフィングの機会が増える可能性があります。正規化されていない名前のリソースの作成を許可するプロトコルとサーバーは、そのような攻撃に対して特に脆弱です。これは、関連するプロトコル、サーバー、またはリソースの固有のセキュリティ問題であり、IRISに固有のものではありませんが、完全性についてはここで言及されています。
Spoofing can occur in various IRI components, such as the domain name part or a path part. For considerations specific to the domain name part, see [RFC3491]. For the path part, administrators of sites that allow independent users to create resources in the same sub area may have to be careful to check for spoofing.
スプーフィングは、ドメイン名のパートまたはパスパーツなど、さまざまなIRIコンポーネントで発生する可能性があります。ドメイン名パーツに固有の考慮事項については、[RFC3491]を参照してください。パス部分の場合、独立したユーザーが同じサブエリアにリソースを作成できるようにするサイトの管理者は、スプーフィングを確認するように注意する必要がある場合があります。
Spoofing can occur because in the UCS many characters look very similar. Details are discussed in Section 7.5. Again, this is very similar to spoofing possibilities on US-ASCII, e.g., using "br0ken" or "1ame" URIs.
UCSでは多くの文字が非常に似ているように見えるため、スプーフィングが発生する可能性があります。詳細については、セクション7.5で説明します。繰り返しますが、これは、「Br0ken」または「1ame」URIを使用する例えば、US-ASCIIのスプーフィングの可能性に非常に似ています。
Spoofing can occur when URIs with percent-encodings based on various character encodings are accepted to deal with older user agents. In some cases, particularly for Latin-based resource names, this is usually easy to detect because UTF-8-encoded names, when interpreted and viewed as legacy character encodings, produce mostly garbage.
さまざまな文字エンコーディングに基づいてパーセントエンコーディングを持つURIが、古いユーザーエージェントに対処するために受け入れられる場合、スプーフィングが発生する可能性があります。場合によっては、特にラテンベースのリソース名の場合、これは通常、レガシーキャラクターのエンコーディングと解釈および表示される場合、UTF-8エンコードされた名前が主にゴミを生成するため、通常は検出が簡単です。
When concurrently used character encodings have a similar structure but there are no characters that have exactly the same encoding, detection is more difficult.
同時に使用されている文字エンコーディングの構造は同様ですが、エンコードとまったく同じ文字がない場合、検出はより困難です。
Spoofing can occur with bidirectional IRIs, if the restrictions in section 4.2 are not followed. The same visual representation may be interpreted as different logical representations, and vice versa. It is also very important that a correct Unicode bidirectional implementation be used.
セクション4.2の制限が守られていない場合、双方向虹彩ではスプーフィングが発生する可能性があります。同じ視覚表現は、異なる論理表現として解釈される場合があり、その逆も同様です。また、正しいユニコード双方向の実装を使用することも非常に重要です。
We would like to thank Larry Masinter for his work as coauthor of many earlier versions of this document (draft-masinter-url-i18n-xx).
このドキュメントの多くの以前のバージョン（Draft-Masinter-URL-I18N-XX）の共著者としての彼の仕事について、Larry Masinterに感謝します。
The discussion on the issue addressed here started a long time ago. There was a thread in the HTML working group in August 1995 (under the topic of "Globalizing URIs") and in the www-international mailing list in July 1996 (under the topic of "Internationalization and URLs"), and there were ad-hoc meetings at the Unicode conferences in September 1995 and September 1997.
ここで説明した問題に関する議論は、ずっと前に始まりました。1995年8月にHTMLワーキンググループ（「Globalizing URI」のトピックの下）と1996年7月のwww-internationalメーリングリスト（「国際化とURL」のトピックの下）にスレッドがあり、アドバイスがありました。1995年9月と1997年9月のユニコード会議でのHOCミーティング。
Many thanks go to Francois Yergeau, Matitiahu Allouche, Roy Fielding, Tim Berners-Lee, Mark Davis, M.T. Carrasco Benitez, James Clark, Tim Bray, Chris Wendt, Yaron Goland, Andrea Vine, Misha Wolf, Leslie Daigle, Ted Hardie, Bill Fenner, Margaret Wasserman, Russ Housley, Makoto MURATA, Steven Atkin, Ryan Stansifer, Tex Texin, Graham Klyne, Bjoern Hoehrmann, Chris Lilley, Ian Jacobs, Adam Costello, Dan Oscarson, Elliotte Rusty Harold, Mike J. Brown, Roy Badami, Jonathan Rosenne, Asmus Freytag, Simon Josefsson, Carlos Viegas Damasio, Chris Haynes, Walter Underwood, and many others for help with understanding the issues and possible solutions, and with getting the details right.
フランソワ・イェルゴー、マティティアフ・オールーシュ、ロイ・フィールディング、ティム・バーナーズ・リー、マーク・デイビス、M.T。カラスコ・ベニテス、ジェームズ・クラーク、ティム・ブレイ、クリス・ウェント、ヤロン・ゴーランド、アンドレア・ヴァイン、ミーシャ・ウルフ、レスリー・デイグル、テッド・ハーディ、ビル・フェナー、マーガレット・ワッサーマン、ラシュ・ムラタ、マコト・ムラタ、スティーブン・アトキン、ラハラハ・スタンシン、テキス・テキシン、グラハム・ヘインヌ、Bjoern Hoehrmann、Chris Lilley、Ian Jacobs、Adam Costello、Dan Oscarson、Elliotte Rusty Harold、Mike J. Brown、Roy Badami、Jonathan Rosenne、Asmus Freytag、Simon Josefsson、Carlos Viegas Damasio、Chris Hayt問題や可能な解決策を理解し、詳細を正しく理解するのに役立ちます。
This document is a product of the Internationalization Working Group (I18N WG) of the World Wide Web Consortium (W3C). Thanks to the members of the W3C I18N Working Group and Interest Group for their contributions and their work on [CharMod]. Thanks also go to the members of many other W3C Working Groups for adopting IRIs, and to the members of the Montreal IAB Workshop on Internationalization and Localization for their review.
この文書は、World Wide Webコンソーシアム（W3C）の国際化ワーキンググループ（I18N WG）の製品です。W3C I18Nワーキンググループおよび利息グループのメンバーの貢献と[Charmod]に関する作業に感謝します。また、IRIを採用してくれた他の多くのW3Cワーキンググループのメンバー、およびレビューのための国際化とローカリゼーションに関するモントリオールIABワークショップのメンバーにも感謝します。
[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII] American National Standards Institute、「コード化された文字セット - 情報交換のための7ビットアメリカ標準コード」、ANSI X3.4、1986。
[ISO10646] International Organization for Standardization, "ISO/IEC 10646:2003: Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO Standard 10646, December 2003.
[ISO10646]国際標準化機関、「ISO/IEC 10646：2003：情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS）」、ISO Standard 10646、2003年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、RFC 3491、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[UNI9] Davis, M., "The Bidirectional Algorithm", Unicode Standard Annex #9, March 2004, <http://www.unicode.org/reports/tr9/tr9-13.html>.
[Uni9] Davis、M。、「双方向アルゴリズム」、Unicode Standard Annex＃9、2004年3月、<http://www.unicode.org/reports/tr9/tr9-13.html>。
[UNIV4] The Unicode Consortium, "The Unicode Standard, Version 4.0.1, defined by: The Unicode Standard, Version 4.0 (Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), as amended by Unicode 4.0.1 (http://www.unicode.org/versions/Unicode4.0.1/)", March 2004.
[Univ4] Unicode Consortium、「Unicode Standard、バージョン4.0.1、定義：Unicode Standard、バージョン4.0（Reading、Ma、Addison-Wesley、2003）Unicode 4.0.1（http://www.unicode.org/versions/unicode4.0.1/） "、2004年3月。
[UTR15] Davis, M. and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex #15, April 2003, <http://www.unicode.org/unicode/reports/ tr15/tr15-23.html>.
[UTR15] Davis、M。and M. Duerst、「Unicode Normalization Forms」、Unicode Standard Annex＃15、<http://www.unicode.org/unicode/reports/ TR15/TR15-23.HTML>。
[BidiEx] "Examples of bidirectional IRIs", <http://www.w3.org/International/iri-edit/ BidiExamples>.
[Bidiex]「双方向虹彩の例」、<http://www.w3.org/international/iri-edit/ bidiexamples>。
[CharMod] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., and T. Texin, "Character Model for the World Wide Web: Resource Identifiers", World Wide Web Consortium Candidate Recommendation, November 2004, <http://www.w3.org/TR/charmod-resid>.
[Charmod] Duerst、M.、Yergeau、F.、Ishida、R.、Wolf、M.、およびT. Texin、「World Wide Web：Resource Identiersiersのキャラクターモデル」、World Wide Web Consortium候補の推奨、2004年11月、<http://www.w3.org/tr/charmod-resid>。
[Duerst97] Duerst, M., "The Properties and Promises of UTF-8", Proc. 11th International Unicode Conference, San Jose , September 1997, <http://www.ifi.unizh.ch/mml/mduerst/papers/ PDF/IUC11-UTF-8.pdf>.
[Duerst97] Duerst、M。、「UTF-8の特性と約束」、Proc。第11回国際ユニコード会議、サンノゼ、1997年9月、<http://www.ifi.unizh.ch/mml/mduerst/papers/ pdf/iuc11-utf-8.pdf>。
[Gettys] Gettys, J., "URI Model Consequences", <http://www.w3.org/DesignIssues/ModelConsequences>.
[Gettys] Gettys、J。、「Uri Model結果」、<http://www.w3.org/designissues/modelconsequences>。
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation, December 1999, <http://www.w3.org/TR/html401/appendix/ notes.html#h-B.2>.
[HTML4] Raggett、D.、Le Hors、A。、およびI. Jacobs、「HTML 4.01仕様」、World Wide Web Consortiumの推奨、1999年12月、<http://www.w3.org/tr/html401/appendix/ notes.html＃h-b.2>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[RFC2130] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Crispin、M。、およびP. Svanberg、」 - 1996年3月1日 "、RFC 2130、1997年4月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[RFC2192]ニューマン、C。、「IMAP URLスキーム」、RFC 2192、1997年9月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368] Hoffman、P.、Masinter、L。、およびJ. Zawinski、「The Mailto URL Scheme」、RFC 2368、1998年7月。
[RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[RFC2384] Gellens、R。、「Pop URL Scheme」、RFC 2384、1998年8月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397] Masinter、L。、 "The" Data "URL Scheme"、RFC 2397、1998年8月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC2640] Curtin、B。、「ファイル転送プロトコルの国際化」、RFC 2640、1999年7月。
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[RFC2718] Masinter、L.、Alvestrand、H.、Zigmond、D。、およびR. Petke、「新しいURLスキームのガイドライン」、RFC 2718、1999年11月。
[UNIXML] Duerst, M. and A. Freytag, "Unicode in XML and other Markup Languages", Unicode Technical Report #20, World Wide Web Consortium Note, June 2003, <http://www.w3.org/TR/unicode-xml/>.
[UNIXML] Duerst、M。and A. Freytag、「XMLおよびその他のマークアップ言語のUnicode」、Unicode Technical Report＃20、World Wide Web Consortium Note、2003年6月、<http://www.w3.org/tr/unicode-xml/>。
[XLink] DeRose, S., Maler, E., and D. Orchard, "XML Linking Language (XLink) Version 1.0", World Wide Web Consortium Recommendation, June 2001, <http://www.w3.org/TR/xlink/#link-locators>.
[Xlink] Derose、S.、Maler、E。、およびD. Orchard、「XML Linking Language（Xlink）バージョン1.0」、World Wide Webコンソーシアムの推奨、2001年6月、<http://www.w3.org/tr/xlink/＃link-locators>。
[XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation, February 2004, <http://www.w3.org/TR/REC-xml#sec-external-ent>.
[XML1] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第3版）」、World Wide Web Consortiumの推奨、2004年2月、<http://www.w3.org/tr/rec-xml#sec-external-ent>。
[XMLNamespace] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XMLNamesPace] Bray、T.、Hollander、D.、A。Layman、「XMLの名前空間」、World Wide Web Consortiumの推奨、1999年1月、<http://www.w3.org/tr/rec-xml-名前>。
[XMLSchema] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", World Wide Web Consortium Recommendation, May 2001, <http://www.w3.org/TR/xmlschema-2/#anyURI>.
[Xmlschema] Biron、P。and A. Malhotra、「XML Schema Part 2：Datatypes」、World Wide Web Consortiumの推奨、2001年5月、<http://www.w3.org/tr/xmlschema-2/#anyuri>。
[XPointer] Grosso, P., Maler, E., Marsh, J. and N. Walsh, "XPointer Framework", World Wide Web Consortium Recommendation, March 2003, <http://www.w3.org/TR/xptr-framework/#escaping>.
[Xpointer] Grosso、P.、Maler、E.、Marsh、J。and N. Walsh、「Xpointer Framework」、World Wide Webコンソーシアムの推奨、2003年3月、<http://www.w3.org/tr/xptr-framework/＃escaping>。
This section shortly summarizes major design alternatives and the reasons for why they were not chosen.
このセクションでは、まもなく主要な設計の代替案と、それらが選ばれなかった理由をまとめたものです。
Appendix A.1. New Scheme(s)
付録A.1。新しいスキーム
Introducing new schemes (for example, httpi:, ftpi:,...) or a new metascheme (e.g., i:, leading to URI/IRI prefixes such as i:http:, i:ftp:,...) was proposed to make IRI-to-URI conversion scheme dependent or to distinguish between percent-encodings resulting from IRI-to-URI conversion and percent-encodings from legacy character encodings.
新しいスキーム（たとえば、httpi：、ftpi：、...）または新しいMetasheeme（例えば、i：、i：http：、i：ftp：、...などのURI/IRIプレフィックスにつながる）の導入IRIからURIへの変換スキームを依存するか、IRIから尿への変換とレガシーキャラクターのエンコーディングからのパーセントエンコードに起因するパーセントエンコードを区別することを提案します。
New schemes are not needed to distinguish URIs from true IRIs (i.e., IRIs that contain non-ASCII characters). The benefit of being able to detect the origin of percent-encodings is marginal, as UTF-8 can be detected with very high reliability. Deploying new schemes is extremely hard, so not requiring new schemes for IRIs makes deployment of IRIs vastly easier. Making conversion scheme dependent is highly inadvisable and would be encouraged by separate schemes for IRIs. Using a uniform convention for conversion from IRIs to URIs makes IRI implementation orthogonal to the introduction of actual new schemes.
URIを真の虹彩（つまり、非ASCII文字を含む虹彩）と区別するために新しいスキームは必要ありません。UTF-8は非常に高い信頼性で検出できるため、パーセントエンコーディングの起源を検出できることの利点はわずかです。新しいスキームの展開は非常に困難であるため、IRISに新しいスキームを必要としないと、IRISの展開が非常に簡単になります。コンバージョンスキームに依存することは非常に控えめであり、IRIの個別のスキームによって奨励されます。IRISからURISへの変換のために均一な慣習を使用すると、IRIの実装は、実際の新しいスキームの導入に直交します。
Appendix A.2. Character Encodings Other Than UTF-8
付録A.2。UTF-8以外の文字エンコーディング
At an early stage, UTF-7 was considered as an alternative to UTF-8 when IRIs are converted to URIs. UTF-7 would not have needed percent-encoding and in most cases would have been shorter than percent-encoded UTF-8.
初期段階では、UTF-7は、虹彩がURISに変換された場合、UTF-8の代替と見なされていました。UTF-7は必要な割合ではなく、ほとんどの場合、Encoded UTF-8よりも短かったでしょう。
Using UTF-8 avoids a double layering and overloading of the use of the "+" character. UTF-8 is fully compatible with US-ASCII and has therefore been recommended by the IETF, and is being used widely.
UTF-8を使用すると、「」文字の使用の二重層と過負荷が回避されます。UTF-8はUS-ASCIIと完全に互換性があるため、IETFによって推奨されており、広く使用されています。
UTF-7 has never been used much and is now clearly being discouraged. Requiring implementations to convert from UTF-8 to UTF-7 and back would be an additional implementation burden.
UTF-7はあまり使用されたことがなく、今では明らかに落胆しています。UTF-8からUTF-7以下に変換するために実装を要求することは、追加の実装負担になります。
Appendix A.3. New Encoding Convention
付録A.3。新しいエンコーディングコンベンション
Instead of using the existing percent-encoding convention of URIs, which is based on octets, the idea was to create a new encoding convention; for example, to use "%u" to introduce UCS code points.
オクテットに基づいたURIの既存のパーセントをコードする慣習を使用する代わりに、アイデアは新しいエンコード条約を作成することでした。たとえば、「％U」を使用してUCSコードポイントを導入します。
Using the existing octet-based percent-encoding mechanism does not need an upgrade of the URI syntax and does not need corresponding server upgrades.
既存のオクテットベースのパーセントエンコードメカニズムを使用しても、URI構文のアップグレードは必要ありません。また、対応するサーバーのアップグレードは必要ありません。
Appendix A.4. Indicating Character Encodings in the URI/IRI
付録A. 4。URI/IRIの文字エンコーディングを示す
Some proposals suggested indicating the character encodings used in an URI or IRI with some new syntactic convention in the URI itself, similar to the "charset" parameter for e-mails and Web pages. As an example, the label in square brackets in "http://www.example.org/ros[iso-8859-1]é"; indicated that the following "é"; had to be interpreted as iso-8859-1.
いくつかの提案は、電子メールとWebページの「charset」パラメーターと同様に、URI自体にいくつかの新しい構文規則を備えたURIまたはIRIで使用されているキャラクターエンコーディングを示すことを提案しました。例として、「http://www.example.org/ros [iso-8859-1]の正方形の括弧内のラベル」;次の「＆＃xe9」;ISO-8859-1として解釈する必要がありました。
If UTF-8 is used exclusively, an upgrade to the URI syntax is not needed. It avoids potentially multiple labels that have to be copied correctly in all cases, even on the side of a bus or on a napkin, leading to usability problems (and being prohibitively annoying). Exclusively using UTF-8 also reduces transcoding errors and confusion.
UTF-8が排他的に使用される場合、URI構文へのアップグレードは必要ありません。バスの側面やナプキン上であっても、すべての場合に正しくコピーする必要がある潜在的に複数のラベルを避け、使いやすさの問題につながります（そして、やや迷惑です）。UTF-8のみを使用すると、トランスコーディングエラーと混乱も減ります。
Authors' Addresses
著者のアドレス
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) World Wide Web Consortium 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
Martin Duerst（注：可能な限りU-Umlaut、たとえば「D＆＃252; rst」としてu-umlautで「Duerst」を書いてください。
Phone: +81 466 49 1170 Fax: +81 466 49 1171 EMail: duerst@w3.org URI: http://www.w3.org/People/D%C3%BCrst/ (Note: This is the percent-encoded form of an IRI.)
電話：81 466 49 1170 FAX：81 466 49 1171メール：duerst@w3.org uri：http：//www.w3.org/people/d%C3%Bcrst/IRI。）
Michel Suignard Microsoft Corporation One Microsoft Way Redmond, WA 98052 U.S.A.
Michel Suignard Microsoft Corporation One Microsoft Way Redmond、WA 98052 U.S.A.
Phone: +1 425 882-8080
EMail: michelsu@microsoft.com
URI: http://www.suignard.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。