[要約] RFC 3986は、URIの一般的な構文と目的についての標準仕様です。URIの構文と解釈方法を定義し、インターネット上のリソースの一意な識別と参照を可能にします。
Network Working Group T. Berners-Lee
Request for Comments: 3986 W3C/MIT
STD: 66 R. Fielding
Updates: 1738 Day Software
Obsoletes: 2732, 2396, 1808 L. Masinter
Category: Standards Track Adobe Systems
January 2005
Uniform Resource Identifier (URI): Generic Syntax
ユニフォームリソース識別子（URI）：汎用構文
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
概要
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
均一なリソース識別子（URI）は、抽象的または物理的なリソースを識別するコンパクトな文字シーケンスです。この仕様は、一般的なURI構文と、インターネット上でのURIの使用に関するガイドラインとセキュリティに関する考慮事項とともに、相対的な形であるURI参照を解決するためのプロセスを定義します。URI構文は、すべての有効なURIのスーパーセットである文法を定義し、すべての可能な識別子のスキーム固有の要件を知らずに、URI参照の共通コンポーネントを解析できるようにします。この仕様は、URIの生成文法を定義しません。そのタスクは、各URIスキームの個々の仕様によって実行されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview of URIs . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Generic Syntax . . . . . . . . . . . . . . . . . 6
1.1.2. Examples . . . . . . . . . . . . . . . . . . . . 7
1.1.3. URI, URL, and URN . . . . . . . . . . . . . . . 7
1.2. Design Considerations . . . . . . . . . . . . . . . . . 8
1.2.1. Transcription . . . . . . . . . . . . . . . . . 8
1.2.2. Separating Identification from Interaction . . . 9
1.2.3. Hierarchical Identifiers . . . . . . . . . . . . 10
1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . 11
2. Characters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Percent-Encoding . . . . . . . . . . . . . . . . . . . . 12
2.2. Reserved Characters . . . . . . . . . . . . . . . . . . 12
2.3. Unreserved Characters . . . . . . . . . . . . . . . . . 13
2.4. When to Encode or Decode . . . . . . . . . . . . . . . . 14
2.5. Identifying Data . . . . . . . . . . . . . . . . . . . . 14
3. Syntax Components . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Authority . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. User Information . . . . . . . . . . . . . . . . 18
3.2.2. Host . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. Port . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Fragment . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. URI Reference . . . . . . . . . . . . . . . . . . . . . 25
4.2. Relative Reference . . . . . . . . . . . . . . . . . . . 26
4.3. Absolute URI . . . . . . . . . . . . . . . . . . . . . . 27
4.4. Same-Document Reference . . . . . . . . . . . . . . . . 27
4.5. Suffix Reference . . . . . . . . . . . . . . . . . . . . 27
5. Reference Resolution . . . . . . . . . . . . . . . . . . . . . 28
5.1. Establishing a Base URI . . . . . . . . . . . . . . . . 28
5.1.1. Base URI Embedded in Content . . . . . . . . . . 29
5.1.2. Base URI from the Encapsulating Entity . . . . . 29
5.1.3. Base URI from the Retrieval URI . . . . . . . . 30
5.1.4. Default Base URI . . . . . . . . . . . . . . . . 30
5.2. Relative Resolution . . . . . . . . . . . . . . . . . . 30
5.2.1. Pre-parse the Base URI . . . . . . . . . . . . . 31
5.2.2. Transform References . . . . . . . . . . . . . . 31
5.2.3. Merge Paths . . . . . . . . . . . . . . . . . . 32
5.2.4. Remove Dot Segments . . . . . . . . . . . . . . 33
5.3. Component Recomposition . . . . . . . . . . . . . . . . 35
5.4. Reference Resolution Examples . . . . . . . . . . . . . 35
5.4.1. Normal Examples . . . . . . . . . . . . . . . . 36
5.4.2. Abnormal Examples . . . . . . . . . . . . . . . 36
6. Normalization and Comparison . . . . . . . . . . . . . . . . . 38
6.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . 38
6.2. Comparison Ladder . . . . . . . . . . . . . . . . . . . 39
6.2.1. Simple String Comparison . . . . . . . . . . . . 39
6.2.2. Syntax-Based Normalization . . . . . . . . . . . 40
6.2.3. Scheme-Based Normalization . . . . . . . . . . . 41
6.2.4. Protocol-Based Normalization . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7.1. Reliability and Consistency . . . . . . . . . . . . . . 43
7.2. Malicious Construction . . . . . . . . . . . . . . . . . 43
7.3. Back-End Transcoding . . . . . . . . . . . . . . . . . . 44
7.4. Rare IP Address Formats . . . . . . . . . . . . . . . . 45
7.5. Sensitive Information . . . . . . . . . . . . . . . . . 45
7.6. Semantic Attacks . . . . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 47
A. Collected ABNF for URI . . . . . . . . . . . . . . . . . . . . 49
B. Parsing a URI Reference with a Regular Expression . . . . . . 50
C. Delimiting a URI in Context . . . . . . . . . . . . . . . . . 51
D. Changes from RFC 2396 . . . . . . . . . . . . . . . . . . . . 53
D.1. Additions . . . . . . . . . . . . . . . . . . . . . . . 53
D.2. Modifications . . . . . . . . . . . . . . . . . . . . . 53
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
A Uniform Resource Identifier (URI) provides a simple and extensible means for identifying a resource. This specification of URI syntax and semantics is derived from concepts introduced by the World Wide Web global information initiative, whose use of these identifiers dates from 1990 and is described in "Universal Resource Identifiers in WWW" [RFC1630]. The syntax is designed to meet the recommendations laid out in "Functional Recommendations for Internet Resource Locators" [RFC1736] and "Functional Requirements for Uniform Resource Names" [RFC1737].
均一なリソース識別子（URI）は、リソースを識別するためのシンプルで拡張可能な手段を提供します。URI構文とセマンティクスのこの仕様は、1990年からこれらの識別子の使用が「wwwのユニバーサルリソース識別子」[RFC1630]に記載されているWorld Web Global Information Initiativeによって導入された概念から派生しています。構文は、「インターネットリソースロケーターの機能的な推奨事項」[RFC1736]および「ユニフォームリソース名の機能要件」[RFC1737]で定められた推奨事項を満たすように設計されています。
This document obsoletes [RFC2396], which merged "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URIs. It obsoletes [RFC2732], which introduced syntax for an IPv6 address. It excludes portions of RFC 1738 that defined the specific syntax of individual URI schemes; those portions will be updated as separate documents. The process for registration of new URI schemes is defined separately by [BCP35]. Advice for designers of new URI schemes can be found in [RFC2718]. All significant changes from RFC 2396 are noted in Appendix D.
このドキュメントは、すべてのURIの単一の一般的な構文を定義するために、「均一なリソースロケーター」[RFC1738]と「相対均一なリソースロケーター」[RFC1808]を統合した[RFC2396]を廃止しました。IPv6アドレスに構文を導入した廃止[RFC2732]。個々のURIスキームの特定の構文を定義したRFC 1738の一部を除外します。これらの部分は、個別のドキュメントとして更新されます。新しいURIスキームの登録プロセスは、[BCP35]によって個別に定義されます。新しいURIスキームのデザイナーへのアドバイスは、[RFC2718]にあります。RFC 2396からのすべての重要な変更は、付録Dに記載されています。
This specification uses the terms "character" and "coded character set" in accordance with the definitions provided in [BCP19], and "character encoding" in place of what [BCP19] refers to as a "charset".
この仕様では、[BCP19]で提供されている定義に従って「文字」と「コード化された文字セット」という用語を使用し、[BCP19]の代わりに「Charset」と呼ばれるものの代わりに「文字エンコード」を使用します。
URIs are characterized as follows:
urisは次のように特徴付けられます：
Uniform
ユニフォーム
Uniformity provides several benefits. It allows different types of resource identifiers to be used in the same context, even when the mechanisms used to access those resources may differ. It allows uniform semantic interpretation of common syntactic conventions across different types of resource identifiers. It allows introduction of new types of resource identifiers without interfering with the way that existing identifiers are used. It allows the identifiers to be reused in many different contexts, thus permitting new applications or protocols to leverage a pre-existing, large, and widely used set of resource identifiers.
均一性はいくつかの利点を提供します。これらのリソースにアクセスするために使用されるメカニズムが異なる場合でも、さまざまなタイプのリソース識別子を同じコンテキストで使用できます。これにより、さまざまな種類のリソース識別子にわたる一般的な構文規則の均一な意味解釈が可能になります。これにより、既存の識別子が使用される方法を妨げることなく、新しいタイプのリソース識別子を導入できます。識別子をさまざまなコンテキストで再利用できるようにするため、新しいアプリケーションまたはプロトコルが既存の大規模で広く使用されているリソース識別子セットを活用できます。
Resource
リソース
This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity).
この仕様は、リソースである可能性のある範囲を制限するものではありません。むしろ、「リソース」という用語は、URIによって特定される可能性のあるものに対して一般的な意味で使用されます。おなじみの例には、電子文書、画像、一貫した目的を持つ情報源（「ロサンゼルスの今日の天気予報」）、サービス（例：HTTPからSMSゲートウェイなど）、およびその他のコレクションが含まれます。リソース。リソースは必ずしもインターネットからアクセスできるわけではありません。たとえば、図書館の人間、企業、縛られた本もリソースになる可能性があります。同様に、抽象的な概念は、数学的方程式の演算子やオペランド、関係のタイプ（「親」または「従業員」など）、または数値（ゼロ、1つ、無限など）などのリソースです。
Identifier
識別子
An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed. Likewise, the "one" resource identified might not be singular in nature (e.g., a resource might be a named set or a mapping that varies over time).
識別子は、識別の範囲内で他のすべてのものと識別されているものを区別するために必要な情報を具体化します。「識別」と「識別」という用語の使用は、その目的の達成方法に関係なく、他のすべてのリソースと他のすべてのリソースを区別するというこの目的を指します（例えば、名前、住所、またはコンテキスト）。これらの用語は、識別子が参照されているものの身元を定義または具体化するという仮定と誤解されるべきではありませんが、一部の識別子の場合はそうです。また、URIを使用するシステムが特定されたリソースにアクセスすると想定されるべきではありません。多くの場合、URIはアクセスする意図なしにリソースを示すために使用されます。同様に、特定された「1つの」リソースは、本質的には単数形ではない可能性があります（たとえば、リソースは名前のセットまたは時間の経過とともに変化するマッピングである可能性があります）。
A URI is an identifier consisting of a sequence of characters matching the syntax rule named <URI> in Section 3. It enables uniform identification of resources via a separately defined extensible set of naming schemes (Section 3.1). How that identification is accomplished, assigned, or enabled is delegated to each scheme specification.
URIは、セクション3の<uri>という名前の構文ルールと一致する一連の文字で構成される識別子です。これにより、個別に定義された拡張可能な命名スキームセットを介してリソースの均一な識別が可能になります（セクション3.1）。その識別がどのように達成、割り当て、または有効化されているかは、各スキーム仕様に委任されます。
This specification does not place any limits on the nature of a resource, the reasons why an application might seek to refer to a resource, or the kinds of systems that might use URIs for the sake of identifying resources. This specification does not require that a URI persists in identifying the same resource over time, though that is a common goal of all URI schemes. Nevertheless, nothing in this specification prevents an application from limiting itself to particular types of resources, or to a subset of URIs that maintains characteristics desired by that application.
この仕様では、リソースの性質、アプリケーションがリソースを参照しようとする理由、またはリソースを識別するためにURIを使用する可能性のあるシステムの種類に制限はありません。この仕様では、URIが時間の経過とともに同じリソースを識別する際に持続する必要はありませんが、それはすべてのURIスキームの共通の目標です。それにもかかわらず、この仕様では、アプリケーションが特定の種類のリソース、またはそのアプリケーションが望む特性を維持するURIのサブセットにそれ自体を制限することを妨げるものはありません。
URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context. For example, "http://localhost/" has the same interpretation for every user of that reference, even though the network interface corresponding to "localhost" may be different for each end-user: interpretation is independent of access. However, an action made on the basis of that reference will take place in relation to the end-user's context, which implies that an action intended to refer to a globally unique thing must use a URI that distinguishes that resource from all other things. URIs that identify in relation to the end-user's local context should only be used when the context itself is a defining aspect of the resource, such as when an on-line help manual refers to a file on the end-user's file system (e.g., "file:///etc/hosts").
URIはグローバルな範囲を持ち、コンテキストに関係なく一貫して解釈されますが、その解釈の結果はエンドユーザーのコンテキストに関連している可能性があります。たとえば、「http：// localhost/」は、「ローカルホスト」に対応するネットワークインターフェイスがエンドユーザーごとに異なる場合がありますが、その参照のすべてのユーザーに対して同じ解釈があります。解釈はアクセスとは無関係です。ただし、その参照に基づいて行われたアクションは、エンドユーザーのコンテキストに関連して行われます。これは、グローバルにユニークなものを参照することを目的としたアクションが、そのリソースを他のすべてのものと区別するURIを使用する必要があることを意味します。エンドユーザーのローカルコンテキストに関連して識別するURIは、コンテキスト自体がリソースの決定的な側面である場合にのみ使用する必要があります。、「file：/// etc/hosts」）。
Each URI begins with a scheme name, as defined in Section 3.1, that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.
各URIは、セクション3.1で定義されているスキーム名で始まります。これは、そのスキーム内で識別子を割り当てるための仕様を指します。そのため、URI構文は、各スキームの仕様がそのスキームを使用して識別子の構文とセマンティクスをさらに制限する可能性のあるフェデレーションおよび拡張可能な命名システムです。
This specification defines those elements of the URI syntax that are required of all URI schemes or are common to many URI schemes. It thus defines the syntax and semantics needed to implement a scheme-independent parsing mechanism for URI references, by which the scheme-dependent handling of a URI can be postponed until the scheme-dependent semantics are needed. Likewise, protocols and data formats that make use of URI references can refer to this specification as a definition for the range of syntax allowed for all URIs, including those schemes that have yet to be defined. This decouples the evolution of identification schemes from the evolution of protocols, data formats, and implementations that make use of URIs.
この仕様は、すべてのURIスキームに必要な、または多くのURIスキームに共通するURI構文の要素を定義します。したがって、URI参照にスキームに依存しない解析メカニズムを実装するために必要な構文とセマンティクスを定義します。これにより、スキーム依存のセマンティクスが必要になるまで、スキーム依存の処理を延期できます。同様に、URI参照を使用するプロトコルとデータ形式は、この仕様を、まだ定義されていないスキームを含むすべてのURIに許可される構文の範囲の定義として参照できます。これは、URIを使用するプロトコル、データ形式、および実装の進化からの識別スキームの進化を明らかにします。
A parser of the generic URI syntax can parse any URI reference into its major components. Once the scheme is determined, further scheme-specific parsing can be performed on the components. In other words, the URI generic syntax is a superset of the syntax of all URI schemes.
汎用URI構文のパーサーは、任意のURI参照を主要なコンポーネントに解析できます。スキームが決定されると、コンポーネントでスキーム固有の解析をさらに実行できます。言い換えれば、URIジェネリック構文は、すべてのURIスキームの構文のスーパーセットです。
The following example URIs illustrate several URI schemes and variations in their common syntax components:
次の例URIは、一般的な構文コンポーネントのいくつかのURIスキームとバリエーションを示しています。
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
Mailto：john.doe@example.com
news:comp.infosystems.www.servers.unix
ニュース：comp.infosystems.www.servers.unix
tel:+1-816-555-1212
Tel：1-816-555-1212
telnet://192.0.2.16:80/
Telnet：//192.0.2.16：80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.
URIは、ロケーター、名前、またはその両方としてさらに分類できます。「均一なリソースロケーター」（URL）という用語は、リソースを識別することに加えて、主要なアクセスメカニズム（例：ネットワーク「場所」）を記述することでリソースを見つける手段を提供するURISのサブセットを指します。「ユニフォームリソース名」（URN）という用語は、「URN」スキーム[RFC2141]に基づく両方のURIを参照するために歴史的に使用されてきました。これらは、リソースが存在しなくなったり利用できなくなったりしてもグローバルにユニークで持続性を維持する必要があり、名前のプロパティを持つ他のURIに。
An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].
個々のスキームは、「名前」または「ロケーター」の1つであると分類する必要はありません。特定のスキームからのURIのインスタンスには、多くの場合、スキームの品質ではなく、命名当局による識別子の割り当ての持続性とケアに応じて、名前またはロケーター、あるいはその両方の特性があります。将来の仕様と関連するドキュメントは、より制限的な用語「URL」および「URN」[RFC3305]ではなく、一般的な用語「URI」を使用する必要があります。
The URI syntax has been designed with global transcription as one of its main considerations. A URI is a sequence of characters from a very limited set: the letters of the basic Latin alphabet, digits, and a few special characters. A URI may be represented in a variety of ways; e.g., ink on paper, pixels on a screen, or a sequence of character encoding octets. The interpretation of a URI depends only on the characters used and not on how those characters are represented in a network protocol.
URI構文は、その主な考慮事項の1つとしてグローバルな転写で設計されています。URIは、非常に限られたセットのキャラクターのシーケンスです。基本的なラテンアルファベットの文字、数字、いくつかの特殊文字です。URIはさまざまな方法で表される場合があります。たとえば、紙にインク、画面上のピクセル、またはオクテットをコードする一連の文字。URIの解釈は、使用される文字のみに依存し、それらの文字がネットワークプロトコルでどのように表現されるかには依存しません。
The goal of transcription can be described by a simple scenario. Imagine two colleagues, Sam and Kim, sitting in a pub at an international conference and exchanging research ideas. Sam asks Kim for a location to get more information, so Kim writes the URI for the research site on a napkin. Upon returning home, Sam takes out the napkin and types the URI into a computer, which then retrieves the information to which Kim referred.
転写の目標は、簡単なシナリオで説明できます。国際会議でパブに座って研究のアイデアを交換する2人の同僚、サムとキムを想像してください。サムはキムにその場所をより多くの情報を入手するように頼むので、キムはナプキンの研究サイトのURIを書いています。家に帰ると、サムはナプキンを取り出し、URIをコンピューターに入力し、キムが言及した情報を取得します。
There are several design considerations revealed by the scenario:
シナリオで明らかにされたいくつかの設計上の考慮事項があります。
o A URI is a sequence of characters that is not always represented as a sequence of octets.
o URIは、オクテットのシーケンスとして常に表されるとは限らない一連の文字です。
o A URI might be transcribed from a non-network source and thus should consist of characters that are most likely able to be entered into a computer, within the constraints imposed by keyboards (and related input devices) across languages and locales.
o URIはネットワーク以外のソースから転写される可能性があるため、言語とロケールを越えてキーボード（および関連する入力デバイス）によって課される制約内で、コンピューターに入力できる可能性が最も高い文字で構成される必要があります。
o A URI often has to be remembered by people, and it is easier for people to remember a URI when it consists of meaningful or familiar components.
o 多くの場合、URIは人々に覚えておく必要があり、意味のあるコンポーネントや馴染みのあるコンポーネントで構成されている場合、URIを覚えやすくなります。
These design considerations are not always in alignment. For example, it is often the case that the most meaningful name for a URI component would require characters that cannot be typed into some systems. The ability to transcribe a resource identifier from one medium to another has been considered more important than having a URI consist of the most meaningful of components.
これらの設計上の考慮事項は、常に調整されているわけではありません。たとえば、URIコンポーネントの最も意味のある名前には、一部のシステムに入力できない文字が必要な場合があります。リソース識別子を1つの媒体から別の媒体に転写する機能は、URIが最も意味のあるコンポーネントで構成されるよりも重要であると考えられています。
In local or regional contexts and with improving technology, users might benefit from being able to use a wider range of characters; such use is not defined by this specification. Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI.
ローカルまたは地域のコンテキストでは、テクノロジーの改善により、ユーザーはより広い範囲のキャラクターを使用できることから恩恵を受ける可能性があります。このような使用は、この仕様では定義されていません。この表現がスキームまたはURIが参照されるプロトコル要素によって許可されている場合、URI-ASCIIコード化された文字セットの範囲外の文字を表すために、URI内でパーセントエンコードされたオクテット（セクション2.1）を使用できます。このような定義では、URIに対してパーセントエンコードされる前に、それらの文字をオクテットにマッピングするために使用される文字エンコードを指定する必要があります。
A common misunderstanding of URIs is that they are only used to refer to accessible resources. The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute, or natural language text in which it appears.
URIの一般的な誤解は、それらがアクセス可能なリソースを参照するためにのみ使用されることです。URI自体は識別のみを提供します。リソースへのアクセスは、URIの存在によって保証されておらず、暗示されていません。代わりに、URI参照に関連付けられた操作は、プロトコル要素、データ形式属性、または表示される自然言語テキストによって定義されます。
Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by words such as "access", "update", "replace", or "find attributes". Such operations are defined by the protocols that make use of URIs, not by this specification. However, we do use a few general terms for describing common operations on URIs. URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; this resolution may require several iterations. To use that access mechanism to perform an action on the URI's resource is to "dereference" the URI.
URIを考えると、システムは、「アクセス」、「更新」、「交換」、「属性の検索」などの単語によって特徴付けられる可能性があるように、リソース上のさまざまな操作を実行しようとする場合があります。このような操作は、この仕様ではなく、URIを使用するプロトコルによって定義されます。ただし、URIの一般的な操作を説明するために、いくつかの一般的な用語を使用しています。URIの「解像度」とは、アクセスメカニズムを決定するプロセスと、URIの繰り返しに必要な適切なパラメーターです。この解像度には、いくつかの反復が必要になる場合があります。そのアクセスメカニズムを使用してURIのリソースでアクションを実行することは、URIを「拒否」することです。
When URIs are used within information retrieval systems to identify sources of information, the most common form of URI dereference is "retrieval": making use of a URI in order to retrieve a representation of its associated resource. A "representation" is a sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated. Retrieval is achieved by a process that might include using the URI as a cache key to check for a locally cached representation, resolution of the URI to determine an appropriate access mechanism (if any), and dereference of the URI for the sake of applying a retrieval operation. Depending on the protocols used to perform the retrieval, additional information might be supplied about the resource (resource metadata) and its relation to other resources.
情報のソースを特定するために情報検索システム内でURIを使用する場合、URI dereferenceの最も一般的な形式は「検索」です。関連するリソースの表現を取得するためにURIを使用します。「表現」は、表現が生成された時点でのリソースの状態の記録を構成するオクテットを説明する表現メタデータとともに、オクテットのシーケンスです。検索は、URIをキャッシュキーとして使用してローカルにキャッシュされた表現、URIの解像度を確認して適切なアクセスメカニズム（ある場合）を決定すること、およびURIの控除を含むプロセスによって達成されます。検索操作。検索の実行に使用されるプロトコルに応じて、リソース（リソースメタデータ）と他のリソースとの関係に関する追加情報が提供される場合があります。
URI references in information retrieval systems are designed to be late-binding: the result of an access is generally determined when it is accessed and may vary over time or due to other aspects of the interaction. These references are created in order to be used in the future: what is being identified is not some specific result that was obtained in the past, but rather some characteristic that is expected to be true for future results. In such cases, the resource referred to by the URI is actually a sameness of characteristics as observed over time, perhaps elucidated by additional comments or assertions made by the resource provider.
情報検索システムのURI参照は、遅刻するように設計されています。アクセスの結果は、一般にアクセス時に決定され、時間とともに異なる場合があります。これらの参照は、将来使用されるために作成されます。特定されているのは、過去に得られた特定の結果ではなく、将来の結果に当てはまると予想される特徴です。そのような場合、URIによって言及されているリソースは、実際には時間の経過とともに観察される特性の同一性であり、おそらくリソースプロバイダーによって行われた追加のコメントまたはアサーションによって解明されます。
Although many URI schemes are named after protocols, this does not imply that use of these URIs will result in access to the resource via the named protocol. URIs are often used simply for the sake of identification. Even when a URI is used to retrieve a representation of a resource, that access might be through gateways, proxies, caches, and name resolution services that are independent of the protocol associated with the scheme name. The resolution of some URIs may require the use of more than one protocol (e.g., both DNS and HTTP are typically used to access an "http" URI's origin server when a representation isn't found in a local cache).
多くのURIスキームはプロトコルにちなんで命名されていますが、これはこれらのURIを使用すると、指定されたプロトコルを介してリソースにアクセスできることを意味するものではありません。ウリスは、単に識別のために使用されることがよくあります。URIがリソースの表現を取得するために使用された場合でも、そのアクセスは、スキーム名に関連するプロトコルに依存しないゲートウェイ、プロキシ、キャッシュ、および名前解像度サービスを介して行われる可能性があります。一部のURIの解像度では、複数のプロトコルの使用が必要になる場合があります（たとえば、DNSとHTTPの両方が、ローカルキャッシュで表現が見つからない場合に「HTTP」URIのオリジンサーバーにアクセスするために使用されます）。
The URI syntax is organized hierarchically, with components listed in order of decreasing significance from left to right. For some URI schemes, the visible hierarchy is limited to the scheme itself: everything after the scheme component delimiter (":") is considered opaque to URI processing. Other URI schemes make the hierarchy explicit and visible to generic parsing algorithms.
URI構文は階層的に編成されており、コンポーネントが左から右に有意性を低下させる順にリストされています。一部のURIスキームの場合、可視階層はスキーム自体に限定されます。スキームコンポーネントデリミッター（ "："）の後のすべては、URI処理と不透明と見なされます。他のURIスキームにより、階層が一般的な解析アルゴリズムに明示的かつ表示されます。
The generic syntax uses the slash ("/"), question mark ("?"), and number sign ("#") characters to delimit components that are significant to the generic parser's hierarchical interpretation of an identifier. In addition to aiding the readability of such identifiers through the consistent use of familiar syntax, this uniform representation of hierarchy across naming schemes allows scheme-independent references to be made relative to that hierarchy.
一般的な構文は、識別子の一般的なパーサーの階層解釈に重要なコンポーネントを区切るために、スラッシュ（ "/"）、questionmard（ "？"）、およびnumber sign（ "＃"）文字を使用します。おなじみの構文の一貫した使用を通じて、このような識別子の読みやすさを支援することに加えて、命名スキーム全体の階層のこの均一な表現により、スキームに依存しない参照をその階層と比較して作成できます。
It is often the case that a group or "tree" of documents has been constructed to serve a common purpose, wherein the vast majority of URI references in these documents point to resources within the tree rather than outside it. Similarly, documents located at a particular site are much more likely to refer to other resources at that site than to resources at remote sites. Relative referencing of URIs allows document trees to be partially independent of their location and access scheme. For instance, it is possible for a single set of hypertext documents to be simultaneously accessible and traversable via each of the "file", "http", and "ftp" schemes if the documents refer to each other with relative references. Furthermore, such document trees can be moved, as a whole, without changing any of the relative references.
多くの場合、ドキュメントのグループまたは「ツリー」が共通の目的を果たすために構築されている場合があります。これらの文書のURI参照の大部分は、外側ではなくツリー内のリソースを指しています。同様に、特定のサイトにあるドキュメントは、リモートサイトのリソースよりも、そのサイトの他のリソースを参照する可能性がはるかに高くなります。URISの相対的な参照により、ドキュメントツリーはその場所とアクセススキームから部分的に独立しています。たとえば、単一のハイパーテキストドキュメントセットが、「ファイル」、「HTTP」、および「FTP」スキームを介して同時にアクセスし、通信可能である可能性があります。さらに、そのようなドキュメントツリーは、相対的な参照を変更することなく、全体として移動できます。
A relative reference (Section 4.2) refers to a resource by describing the difference within a hierarchical name space between the reference context and the target URI. The reference resolution algorithm, presented in Section 5, defines how such a reference is transformed to the target URI. As relative references can only be used within the context of a hierarchical URI, designers of new URI schemes should use a syntax consistent with the generic syntax's hierarchical components unless there are compelling reasons to forbid relative referencing within that scheme.
相対参照（セクション4.2）は、参照コンテキストとターゲットURIの間の階層名空間内の違いを記述することにより、リソースを指します。セクション5に示されている参照解像度アルゴリズムは、そのような参照がターゲットURIにどのように変換されるかを定義します。相対的な参照は階層URIのコンテキスト内でのみ使用できるため、新しいURIスキームの設計者は、そのスキーム内で相対的な参照を禁止する説得力のある理由がない限り、一般的な構文の階層コンポーネントと一致する構文を使用する必要があります。
NOTE: Previous specifications used the terms "partial URI" and "relative URI" to denote a relative reference to a URI. As some readers misunderstood those terms to mean that relative URIs are a subset of URIs rather than a method of referencing URIs, this specification simply refers to them as relative references.
注：以前の仕様では、「部分URI」と「相対URI」という用語を使用して、URIへの相対的な参照を示していました。一部の読者は、これらの用語を誤解して、相対的なURIがURIを参照する方法ではなくURISのサブセットであることを意味するため、この仕様は単にそれらを相対的な参照と呼んでいます。
All URI references are parsed by generic syntax parsers when used. However, because hierarchical processing has no effect on an absolute URI used in a reference unless it contains one or more dot-segments (complete path segments of "." or "..", as described in Section 3.3), URI scheme specifications can define opaque identifiers by disallowing use of slash characters, question mark characters, and the URIs "scheme:." and "scheme:..".
すべてのURI参照は、使用すると一般的な構文パーサーによって解析されます。ただし、1つ以上のドットセグメント（セクション3.3で説明されているように、「」または「..」の完全なパスセグメント）が含まれていない限り、階層処理は参照で使用される絶対URIに影響を与えないため、URIスキーム仕様はできます。スラッシュ文字、質問マーク文字、およびuris「スキーム：」の使用を許可することにより、不透明な識別子を定義します。および「スキーム：..」。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC2234], including the following core ABNF syntax rules defined by that specification: ALPHA (letters), CR (carriage return), DIGIT (decimal digits), DQUOTE (double quote), HEXDIG (hexadecimal digits), LF (line feed), and SP (space). The complete URI syntax is collected in Appendix A.
この仕様では、その仕様で定義された次のコアABNF構文ルールを含む[RFC2234]の拡張されたバックスノール形式（ABNF）表記を使用します：アルファ（文字）、CR（キャリッジリターン）、桁（10進数）、dquote（double引用）、hexdig（16進数桁）、LF（ラインフィード）、およびSP（スペース）。完全なURI構文は、付録Aに収集されています。
The URI syntax provides a method of encoding data, presumably for the sake of identifying a resource, as a sequence of characters. The URI characters are, in turn, frequently encoded as octets for transport or presentation. This specification does not mandate any particular character encoding for mapping between URI characters and the octets used to store or transmit those characters. When a URI appears in a protocol element, the character encoding is defined by that protocol; without such a definition, a URI is assumed to be in the same character encoding as the surrounding text.
URI構文は、おそらくリソースを識別するために、文字のシーケンスとして識別するために、データをエンコードする方法を提供します。URI文字は、頻繁に輸送またはプレゼンテーションのオクテットとしてエンコードされます。この仕様では、URI文字とそれらの文字の保存または送信に使用されるオクテット間のマッピングのために特定のキャラクターエンコードを義務付けません。URIがプロトコル要素に表示されると、文字エンコードはそのプロトコルによって定義されます。このような定義がなければ、URIは周囲のテキストと同じ文字をエンコードすると想定されています。
The ABNF notation defines its terminal values to be non-negative integers (codepoints) based on the US-ASCII coded character set [ASCII]. Because a URI is a sequence of characters, we must invert that relation in order to understand the URI syntax. Therefore, the integer values used by the ABNF must be mapped back to their corresponding characters via US-ASCII in order to complete the syntax rules.
ABNF表記は、その端子値を、US-ASCIIコード化された文字セット[ASCII]に基づいて、非陰性整数（コードポイント）であると定義しています。URIは文字のシーケンスであるため、URI構文を理解するためにその関係を反転する必要があります。したがって、ABNFで使用される整数値は、構文ルールを完了するために、US-ASCIIを介して対応する文字に戻る必要があります。
A URI is composed from a limited set of characters consisting of digits, letters, and a few graphic symbols. A reserved subset of those characters may be used to delimit syntax components within a URI while the remaining characters, including both the unreserved set and those reserved characters not acting as delimiters, define each component's identifying data.
URIは、数字、文字、いくつかのグラフィックシンボルで構成される限られた文字セットで構成されています。これらの文字の予約されたサブセットを使用して、URI内の構文コンポーネントを区切ることができ、残りのキャラクターは、予約されていないセットとデリミターとして機能しない予約された文字の両方を含め、各コンポーネントの識別データを定義します。
A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. A percent-encoded octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing that octet's numeric value. For example, "%20" is the percent-encoding for the binary octet "00100000" (ABNF: %x20), which in US-ASCII corresponds to the space character (SP). Section 2.4 describes when percent-encoding and decoding is applied.
パーセントエンコードメカニズムは、そのオクテットの対応する文字が許可されたセットの外側にあるか、コンポーネント内または内部で使用されている場合、コンポーネントのデータオクテットを表すために使用されます。パーセントエンコードされたオクテットは、キャラクターのトリプレットとしてエンコードされ、その後のオクテットの数値を表す2つの16進数桁が続くパーセントの文字「％」で構成されます。たとえば、「％20」は、US-ASCIIではスペース文字（SP）に対応するバイナリオクテット "00100000"（ABNF：％x20）のパーセントエンコードです。セクション2.4では、パーセントエンコードとデコードが適用される時期について説明します。
pct-encoded = "%" HEXDIG HEXDIG
pct-encoded = "％" hexdig hexdig
The uppercase hexadecimal digits 'A' through 'F' are equivalent to the lowercase digits 'a' through 'f', respectively. If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent. For consistency, URI producers and normalizers should use uppercase hexadecimal digits for all percent-encodings.
大文字の16進数桁「f」は、それぞれ「f」から「f」を通る小文字の数字「a」に相当します。2つのuriが、エンコードされたオクテットで使用される16進数桁の場合にのみ異なる場合、それらは同等です。一貫性のために、URIプロデューサーとノーマライザーは、すべてのパーセントエンコーディングに大文字の16進数桁を使用する必要があります。
URIs include components and subcomponents that are delimited by characters in the "reserved" set. These characters are called "reserved" because they may (or may not) be defined as delimiters by the generic syntax, by each scheme-specific syntax, or by the implementation-specific syntax of a URI's dereferencing algorithm. If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed.
URIには、「予約済み」セットの文字によって区切られたコンポーネントとサブコンポーネントが含まれます。これらの文字は、一般的な構文、各スキーム固有の構文によって、またはURIのリゼンフェンシングアルゴリズムの実装固有の構文によって、一般的な構文によって区切り文字として定義される可能性がある（またはそうでない場合がない）ため、「予約済み」と呼ばれます。URIコンポーネントのデータが、デリミッターとしての予約されたキャラクターの目的と競合する場合、競合するデータはURIが形成される前にエンコードされなければなりません。
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications. Thus, characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI.
予約されたキャラクターの目的は、URI内の他のデータと区別できる区切り文字のセットを提供することです。予約されたキャラクターの置換がそれに対応するパーセントエンコードのオクテットと異なるウリは同等ではありません。予約された文字をエンコードするパーセント、または予約された文字に対応するパーセントエンコードされたオクテットをデコードすると、ほとんどのアプリケーションでURIがどのように解釈されるかが変わります。したがって、予約されたセットの文字は正規化から保護されているため、URI内のデータサブコンポーネントを区切るためのスキーム固有およびプロデューサー固有のアルゴリズムによって安全に使用できます。
A subset of the reserved characters (gen-delims) is used as delimiters of the generic URI components described in Section 3. A component's ABNF syntax rule will not use the reserved or gen-delims rule names directly; instead, each syntax rule lists the characters allowed within that component (i.e., not delimiting it), and any of those characters that are also in the reserved set are "reserved" for use as subcomponent delimiters within the component. Only the most common subcomponents are defined by this specification; other subcomponents may be defined by a URI scheme's specification, or by the implementation-specific syntax of a URI's dereferencing algorithm, provided that such subcomponents are delimited by characters in the reserved set allowed within that component.
予約された文字のサブセット（Gen-Delims）は、セクション3で説明されている一般的なURIコンポーネントの区切り文字として使用されます。コンポーネントのABNF構文ルールは、予約済みまたはGen-Delimsルール名を直接使用しません。代わりに、各構文ルールは、そのコンポーネント内で許可されている文字をリストします（つまり、それを区切ることはありません）。また、予約されたセットにあるこれらの文字は、コンポーネント内のサブコンポーネントのデリミターとして使用するために「予約されている」ものです。この仕様では、最も一般的なサブコンポーネントのみが定義されます。他のサブコンポーネントは、URIスキームの仕様、またはそのようなサブコンポーネントがそのコンポーネント内で許可されている予約セットの文字によって区切られている場合、URIの繰り返しアルゴリズムの実装固有の構文によって定義される場合があります。
URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.
URIの生産アプリケーションは、これらの文字がURIスキームによってそのコンポーネントのデータを表すために特別に許可されない限り、予約セットの文字に対応するパーセントエンコードデータオクテットが必要です。予約済みの文字がURIコンポーネントに見られる場合、その文字では区切りの役割が知られていない場合、US-ASCIIでのそのキャラクターのエンコードに対応するデータを表すと解釈する必要があります。
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.
URIで許可されているが、予約された目的を持っていないキャラクターは、予約されていないと呼ばれます。これらには、大文字と小文字、10進数桁、ハイフン、ピリオド、アンダースコア、およびチルドが含まれます。
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers.
予約されていないキャラクターの交換がそれに対応するパーセントにエンコードされたUS-ASCIIオクテットと異なるウリは同等です。彼らは同じリソースを識別します。ただし、URIの比較実装は、比較前に常に正規化を実行するとは限りません（セクション6を参照）。一貫性のために、アルファの範囲（％41-％5aおよび％61-％7a）、桁（％30-％39）、ハイフン（％2d）、期間（％2e）、アンダースコア（％（％）の範囲内のパーセントエンコードオクテットのために5f）、またはTilde（％7e）はURIプロデューサーによって作成されないでください。URIで見つかった場合、URIノーマイザーによって対応する未処理のキャラクターにデコードする必要があります。
Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form.
通常の状況では、URI内のオクテットがパーセントエンコードされているのは、コンポーネントパーツからURIを生成するプロセス中です。これは、実装がサブコンポーネントデリミターとして使用する予定の文字のどれを決定し、どのデータとしてデータとして使用できるかを決定する場合です。一度生産されると、URIは常にそのパーセントエンコード形式になります。
When a URI is dereferenced, the components and subcomponents significant to the scheme-specific dereferencing process (if any) must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be mistaken for component delimiters. The only exception is for percent-encoded octets corresponding to characters in the unreserved set, which can be decoded at any time. For example, the octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation.
URIが繰り返される場合、スキーム固有の控除プロセスに重要なコンポーネントとサブコンポーネントは、それらのコンポーネント内の割合でエンコードされたオクテットを安全にデコードする前に、データを安全にデコードする前に解析および分離する必要があります。デリミター。唯一の例外は、予約されていないセットの文字に対応する割合でエンコードされたオクテットの場合です。これはいつでもデコードできます。たとえば、Tilde（ "〜"）文字に対応するオクテットは、古いURI処理の実装によって「％7e」としてエンコードされることがよくあります。「％7e」は、解釈を変更せずに「〜」に置き換えることができます。
Because the percent ("%") character serves as the indicator for percent-encoded octets, it must be percent-encoded as "%25" for that octet to be used as data within a URI. Implementations must not percent-encode or decode the same string more than once, as decoding an already decoded string might lead to misinterpreting a percent data octet as the beginning of a percent-encoding, or vice versa in the case of percent-encoding an already percent-encoded string.
パーセント（「％」）文字は、パーセントエンコードされたオクテットのインジケータとして機能するため、そのオクテットがURI内のデータとして使用されるように、「％25」としてエンコードされている必要があります。既にデコードされた文字列をデコードすると、パーセントエンコードの開始としてパーセントのデータオクテットを誤って解釈する可能性があるため、既にエンコードパーセントの場合、その逆になる可能性があるため、実装は同じ文字列を複数回エンコードまたはデコードしてはなりません。パーセントエンコード文字列。
URI characters provide identifying data for each of the URI components, serving as an external interface for identification between systems. Although the presence and nature of the URI production interface is hidden from clients that use its URIs (and is thus beyond the scope of the interoperability requirements defined by this specification), it is a frequent source of confusion and errors in the interpretation of URI character issues. Implementers have to be aware that there are multiple character encodings involved in the production and transmission of URIs: local name and data encoding, public interface encoding, URI character encoding, data format encoding, and protocol encoding.
URI文字は、各URIコンポーネントの識別データを提供し、システム間の識別のための外部インターフェイスとして機能します。URI生産インターフェイスの存在と性質は、URIを使用するクライアントから隠されていますが（したがって、この仕様で定義される相互運用性要件の範囲を超えています）、URI特性の解釈における混乱とエラーの頻繁な原因です問題。実装者は、URIの生産と送信に関与する複数の文字エンコーディングがあることに注意する必要があります。ローカル名とデータエンコーディング、パブリックインターフェイスエンコーディング、URI文字エンコード、データ形式エンコーディング、およびプロトコルエンコーディング。
Local names, such as file system names, are stored with a local character encoding. URI producing applications (e.g., origin servers) will typically use the local encoding as the basis for producing meaningful names. The URI producer will transform the local encoding to one that is suitable for a public interface and then transform the public interface encoding into the restricted set of URI characters (reserved, unreserved, and percent-encodings). Those characters are, in turn, encoded as octets to be used as a reference within a data format (e.g., a document charset), and such data formats are often subsequently encoded for transmission over Internet protocols.
ファイルシステム名などのローカル名は、ローカル文字エンコードで保存されます。URIの生産アプリケーション（例：Origin Server）は、通常、意味のある名前を作成するための基礎としてローカルエンコードを使用します。URIプロデューサーは、ローカルエンコーディングをパブリックインターフェイスに適したエンコードに変換し、URI文字の制限付きセット（予約済み、非予約、およびパーセントエンコード）にエンコードするパブリックインターフェイスを変換します。これらの文字は、データ形式内の参照として使用されるオクテットとしてエンコードされ（ドキュメントcharsetなど）、そのようなデータ形式は、その後、インターネットプロトコルを介した送信のためにエンコードされることがよくあります。
For most systems, an unreserved character appearing within a URI component is interpreted as representing the data octet corresponding to that character's encoding in US-ASCII. Consumers of URIs assume that the letter "X" corresponds to the octet "01011000", and even when that assumption is incorrect, there is no harm in making it. A system that internally provides identifiers in the form of a different character encoding, such as EBCDIC, will generally perform character translation of textual identifiers to UTF-8 [STD63] (or some other superset of the US-ASCII character encoding) at an internal interface, thereby providing more meaningful identifiers than those resulting from simply percent-encoding the original octets.
ほとんどのシステムでは、URIコンポーネント内に表示される予約されていない文字が、US-ASCIIでのそのキャラクターのエンコードに対応するデータを表すデータと解釈されます。URIの消費者は、「x」という文字がOctet "01011000"に対応していると想定しており、その仮定が間違っている場合でも、それを作ることに害はありません。EBCDICなどの異なる文字エンコードの形で識別子を内部的に提供するシステムは、一般に、UTF-8 [STD63]（または内部でのUS-ASCII文字エンコードの他のスーパーセット）にテキスト識別子の文字翻訳を実行します。インターフェースは、元のオクテットを単純にエンコードするだけで生じるものよりも意味のある識別子を提供します。
For example, consider an information service that provides data, stored locally using an EBCDIC-based file system, to clients on the Internet through an HTTP server. When an author creates a file with the name "Laguna Beach" on that file system, the "http" URI corresponding to that resource is expected to contain the meaningful string "Laguna%20Beach". If, however, that server produces URIs by using an overly simplistic raw octet mapping, then the result would be a URI containing "%D3%81%87%A4%95%81@%C2%85%81%83%88". An internal transcoding interface fixes this problem by transcoding the local name to a superset of US-ASCII prior to producing the URI. Naturally, proper interpretation of an incoming URI on such an interface requires that percent-encoded octets be decoded (e.g., "%20" to SP) before the reverse transcoding is applied to obtain the local name.
たとえば、EBCDICベースのファイルシステムを使用してローカルに保存されているデータを提供する情報サービスを、HTTPサーバーを介してインターネット上のクライアントに検討してください。著者がそのファイルシステムに「Laguna Beach」という名前のファイルを作成すると、そのリソースに対応する「HTTP」URIには、意味のある文字列「Laguna％20Beach」が含まれると予想されます。ただし、そのサーバーが過度に単純化された生のオクテットマッピングを使用してURIを生成する場合、結果は「％d3％81％87％A4％95％81@％C2％85％81％83％88 "を含むURIになります。。内部トランスコーディングインターフェイスは、URIを生成する前にローカル名をus-asciiのスーパーセットにトランスコードすることにより、この問題を修正します。当然のことながら、このようなインターフェイス上の着信URIの適切な解釈では、逆トランスコーディングが適用される前に、エンコードされたオクテットのパーセントをデコードする必要があります（たとえば、「％20」）ローカル名を取得する必要があります。
In some cases, the internal interface between a URI component and the identifying data that it has been crafted to represent is much less direct than a character encoding translation. For example, portions of a URI might reflect a query on non-ASCII data, or numeric coordinates on a map. Likewise, a URI scheme may define components with additional encoding requirements that are applied prior to forming the component and producing the URI.
場合によっては、URIコンポーネントと表現するように作成された識別データとの間の内部インターフェイスは、翻訳をエンコードする文字よりもはるかに直接的ではありません。たとえば、URIの一部は、非ASCIIデータのクエリ、またはマップ上の数値座標を反映している場合があります。同様に、URIスキームは、コンポーネントを形成してURIを生成する前に適用される追加のエンコード要件を持つコンポーネントを定義する場合があります。
When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent-encoded. For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".
新しいURIスキームが、ユニバーサル文字セット[UCS]の文字で構成されるテキストデータを表すコンポーネントを定義する場合、データは最初にUTF-8文字エンコード[STD63]に従ってオクテットとしてエンコードする必要があります。次に、予約されていないセットの文字に対応しないオクテットのみがパーセントエンコードされる必要があります。たとえば、キャラクターAは「A」として表され、キャラクターラテンキャピタルレターAが墓をaが「％C3％80」として表され、キャラクターのカタカナ文字Aは「％E3％82％A2として表されます。「。
The generic URI syntax consists of a hierarchical sequence of components referred to as the scheme, authority, path, query, and fragment.
一般的なURI構文は、スキーム、権限、パス、クエリ、およびフラグメントと呼ばれるコンポーネントの階層シーケンスで構成されています。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The scheme and path components are required, though the path may be empty (no characters). When authority is present, the path must either be empty or begin with a slash ("/") character. When authority is not present, the path cannot begin with two slash characters ("//"). These restrictions result in five different ABNF rules for a path (Section 3.3), only one of which will match any given URI reference.
パスが空になる場合がありますが（文字なし）、スキームとパスコンポーネントが必要です。権限が存在する場合、パスは空であるか、スラッシュ（ "/"）文字から始めなければなりません。権限が存在しない場合、パスは2つのスラッシュ文字（ "//"）で開始できません。これらの制限により、パスの5つの異なるABNFルールが発生します（セクション3.3）。そのうちの1つのみが、特定のURIリファレンスと一致します。
The following are two example URIs and their component parts:
以下は、URISとそのコンポーネントパーツの2つの例です。
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
| _____________________|__
/ \ / \
urn:example:animal:ferret:nose
Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.
各URIは、そのスキーム内で識別子を割り当てるための仕様を指すスキーム名で始まります。そのため、URI構文は、各スキームの仕様がそのスキームを使用して識別子の構文とセマンティクスをさらに制限する可能性のあるフェデレーションおよび拡張可能な命名システムです。
Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.
スキーム名は、文字で始まり、文字、数字、プラス（ ""）、周期（ "）、またはハイフン（" - "）の任意の組み合わせが続く一連の文字で構成されています。スキームはケースに依存しませんが、標準形式は小文字であり、スキームを指定するドキュメントは、小文字でそれを行う必要があります。実装は、堅牢性のために、スキーム名の小文字（たとえば、「http」と「http」を許可する）の小文字に相当するものとして大文字を受け入れる必要がありますが、一貫性のために小文字のスキーム名のみを生成する必要があります。
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
Individual schemes are not specified by this document. The process for registration of new URI schemes is defined separately by [BCP35]. The scheme registry maintains the mapping between scheme names and their specifications. Advice for designers of new URI schemes can be found in [RFC2718]. URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar, as described in Section 4.3.
このドキュメントでは、個々のスキームは指定されていません。新しいURIスキームの登録プロセスは、[BCP35]によって個別に定義されます。スキームレジストリは、スキーム名とその仕様の間のマッピングを維持します。新しいURIスキームのデザイナーへのアドバイスは、[RFC2718]にあります。URIスキームの仕様は、セクション4.3で説明されているように、スキーム固有の構文に一致するすべての文字列も<absolute-uri>文法と一致するように、独自の構文を定義する必要があります。
When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific resolution process should flag the reference as an error rather than ignore the unused parts; doing so reduces the number of equivalent URIs and helps detect abuses of the generic syntax, which might indicate that the URI has been constructed to mislead the user (Section 7.6).
1つ以上のスキーム固有の制限に違反するURIが表示された場合、スキーム固有の解決プロセスは、未使用の部分を無視するのではなく、エラーとして参照にフラグを立てる必要があります。そうすることで、同等のURIの数が減り、一般的な構文の乱用の検出に役立ちます。これは、URIがユーザーを誤解させるために構築されたことを示す可能性があります（セクション7.6）。
Many URI schemes include a hierarchical element for a naming authority so that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further). The generic syntax provides a common means for distinguishing an authority based on a registered name or server address, along with optional port and user information.
多くのURIスキームには、命名当局の階層的要素が含まれているため、残りのURIによって定義された名前スペースのガバナンスがその権限に委任されます（これにより、さらに委任することができます）。汎用構文は、オプションのポートとユーザー情報とともに、登録名またはサーバーアドレスに基づいて権限を区別するための一般的な手段を提供します。
The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.
権限コンポーネントの前には、ダブルスラッシュ（ "//"）が先行し、次のスラッシュ（ "/"）、質問マーク（ "？"）、またはnumber sign（ "＃"）文字、または最後までに終了します。URIの。
authority = [ userinfo "@" ] host [ ":" port ]
URI producers and normalizers should omit the ":" delimiter that separates host from port if the port component is empty. Some schemes do not allow the userinfo and/or port subcomponents.
URIプロデューサーとノーマイザーは、ポートコンポーネントが空の場合、ホストをポートから分離する「：」デリミターを省略する必要があります。一部のスキームでは、userInfoおよび/またはポートサブコンポーネントを許可していません。
If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. Non-validating parsers (those that merely separate a URI reference into its major components) will often ignore the subcomponent structure of authority, treating it as an opaque string from the double-slash to the first terminating delimiter, until such time as the URI is dereferenced.
URIに機関コンポーネントが含まれている場合、パスコンポーネントは空であるか、スラッシュ（ "/"）文字で開始する必要があります。非検証パーサー（URI参照を主要なコンポーネントに単に分離するだけでは）は、多くの場合、権限のサブコンポーネント構造を無視し、URIのような時期になるまで、ダブルスラッシュから最初の終端デリミタまでの不透明なストリングとして扱います。参照されます。
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource. The user information, if present, is followed by a commercial at-sign ("@") that delimits it from the host.
userInfoサブコンポーネントは、ユーザー名と、オプションで、リソースにアクセスするための許可を取得する方法に関するスキーム固有の情報で構成されている場合があります。存在する場合、ユーザー情報の後に、ホストからそれを区切るコマーシャルAT-SIGN（ "@"）が続きます。
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.
userInfoフィールドでの「ユーザー：パスワード」のフォーマットの使用は非推奨です。アプリケーションは、コロンの後のデータが空の文字列でない限り、userinfoサブコンポーネント内にある最初のコロン（ "："）文字の後にデータをクリアテキストとしてレンダリングする必要はありません（パスワードがないことを示します）。アプリケーションは、参照の一部として受信された場合、そのようなデータを無視または拒否することを選択し、暗号化されていない形式でそのようなデータのストレージを拒否する必要があります。クリアテキストでの認証情報の渡されたことは、使用されているほぼすべての場合において、セキュリティリスクであることが証明されています。
Applications that render a URI for the sake of user feedback, such as in graphical hypertext browsing, should render userinfo in a way that is distinguished from the rest of a URI, when feasible. Such rendering will assist the user in cases where the userinfo has been misleadingly crafted to look like a trusted domain name (Section 7.6).
グラフィカルハイパーテキストブラウジングなど、ユーザーフィードバックのためにURIをレンダリングするアプリケーションは、実行可能な場合、URIの残りの部分と区別される方法でuserInfoをレンダリングする必要があります。このようなレンダリングは、UserInfoが信頼できるドメイン名のように見えるように誤解を招くほど作成された場合にユーザーを支援します（セクション7.6）。
The host subcomponent of authority is identified by an IP literal encapsulated within square brackets, an IPv4 address in dotted-decimal form, or a registered name. The host subcomponent is case-insensitive. The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet. In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry. However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer. In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host. We use the name "host" for the ABNF rule because that is its most common purpose, not its only purpose.
権限のホストサブコンポーネントは、四角い括弧内にカプセル化されたIPリテラル、点線程度の形式のIPv4アドレス、または登録名によって識別されます。ホストサブコンポーネントは症例感受性です。URI内のホストサブコンポーネントの存在は、スキームがインターネット上の特定のホストへのアクセスを必要とすることを意味するものではありません。多くの場合、ホストの構文は、DNS用に作成および展開された既存の登録プロセスを再利用するためにのみ使用されるため、別のレジストリを展開するコストなしでグローバルに一意の名前を取得します。ただし、このような使用には独自のコストが伴います。ドメイン名の所有権は、URIプロデューサーが予想していない理由で時間とともに変化する場合があります。それ以外の場合、ホストコンポーネント内のデータは、インターネットホストとは何の関係もない登録名を識別します。ABNFルールに「ホスト」という名前を使用します。これは、唯一の目的ではなく、最も一般的な目的であるためです。
host = IP-literal / IPv4address / reg-name
The syntax rule for host is ambiguous because it does not completely distinguish between an IPv4address and a reg-name. In order to disambiguate the syntax, we apply the "first-match-wins" algorithm: If host matches the rule for IPv4address, then it should be considered an IPv4 address literal and not a reg-name. Although host is case-insensitive, producers and normalizers should use lowercase for registered names and hexadecimal addresses for the sake of uniformity, while only using uppercase letters for percent-encodings.
ホストの構文ルールは、IPv4AddressとregNameを完全に区別しないため、あいまいです。構文を乱用するために、「ファーストマッチウィン」アルゴリズムを適用します。ホストがIPv4Addressのルールと一致する場合は、regNameではなくIPv4アドレスリテラルと見なす必要があります。ホストは症例に依存しないが、生産者とノーマライザーは、均一性のために登録名と16進のアドレスに小文字を使用する必要がありますが、パーセントエンコーディングには大文字を使用する必要があります。
A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the only place where square bracket characters are allowed in the URI syntax. In anticipation of future, as-yet-undefined IP literal address formats, an implementation may use an optional version flag to indicate such a format explicitly rather than rely on heuristic determination.
インターネットプロトコルリテラルアドレスであるバージョン6 [RFC3513]以降で識別されるホストは、正方形のブラケット内にIPリテラルを囲むことによって区別されます（ "[" and "]）。これは、URI構文で四角いブラケット文字が許可される唯一の場所です。将来、まだ未定されていないIPリテラルアドレス形式を見越して、実装はオプションのバージョンフラグを使用して、ヒューリスティックな決定に依存するのではなく、そのような形式を明示的に示すことができます。
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
ip-literal = "["（ipv6address / ipvfuture） "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
The version flag does not indicate the IP version; rather, it indicates future versions of the literal format. As such, implementations must not provide the version flag for the existing IPv4 and IPv6 literal address forms described below. If a URI containing an IP-literal that starts with "v" (case-insensitive), indicating that the version flag is present, is dereferenced by an application that does not know the meaning of that version flag, then the application should return an appropriate error for "address mechanism not supported".
バージョンフラグはIPバージョンを示していません。むしろ、リテラル形式の将来のバージョンを示します。そのため、実装は、以下に説明する既存のIPv4およびIPv6リテラルアドレスフォームのバージョンフラグを提供してはなりません。バージョンフラグが存在することを示す「V」（ケース非感受性）で始まるIPリテラルを含むURIが、そのバージョンフラグの意味を知らないアプリケーションによって提示される場合、アプリケーションは返品する必要があります。「サポートされていないアドレスメカニズム」の適切なエラー。
A host identified by an IPv6 literal address is represented inside the square brackets without a preceding version flag. The ABNF provided here is a translation of the text definition of an IPv6 literal address provided in [RFC3513]. This syntax does not support IPv6 scoped addressing zone identifiers.
IPv6リテラルアドレスによって識別されるホストは、前のバージョンフラグなしで四角い括弧内に表されます。ここで提供されるABNFは、[RFC3513]で提供されるIPv6リテラルアドレスのテキスト定義の翻訳です。この構文は、IPv6スコープアドレス指定ゾーン識別子をサポートしていません。
A 128-bit IPv6 address is divided into eight 16-bit pieces. Each piece is represented numerically in case-insensitive hexadecimal, using one to four hexadecimal digits (leading zeroes are permitted). The eight encoded pieces are given most-significant first, separated by colon characters. Optionally, the least-significant two pieces may instead be represented in IPv4 address textual format. A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision.
128ビットIPv6アドレスは、8つの16ビットピースに分割されます。各ピースは、1〜4匹の16進数桁を使用して、ケースに依存しない16進数で数値的に表されます（先行ゼロは許可されています）。8つのエンコードされたピースには、コロン文字で区切られた最も重要な最初のピースが与えられます。オプションで、代わりに最も重要でない2つのピースをIPv4アドレスのテキスト形式で表現できます。アドレス内の1つ以上の連続したゼロ値の16ビットピースのシーケンスを排除し、すべての数字を省略し、排出をマークするためにその代わりに2つの連続したコロンを残します。
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 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
A host identified by an IPv4 literal address is represented in dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."), as described in [RFC1123] by reference to [RFC0952]. Note that other forms of dotted notation may be interpreted on some platforms, as described in Section 7.4, but only the dotted-decimal form of four octets is allowed by this grammar.
IPv4リテラルアドレスによって識別されるホストは、[RFC0952]を参照して[RFC1123]に記載されているように、点線 - 255の範囲0〜255の4つの10進数のシーケンス）で表されます。セクション7.4で説明されているように、他の形式の点線表記は一部のプラットフォームで解釈される場合がありますが、この文法では4つのオクテットの点線形式のみが許可されています。
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
A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS). A registered name intended for lookup in the DNS uses the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.
登録名で識別されるホストは、通常、ローカルで定義されたホストまたはサービス名レジストリ内のルックアップを対象とした一連の文字ですが、URIのスキーム固有のセマンティクスでは、代わりに特定のレジストリ（または固定名テーブル）を使用する必要があります。最も一般的な名前レジストリメカニズムは、ドメイン名システム（DNS）です。DNSのルックアップを目的とした登録名は、[RFC1034]のセクション3.5で定義されている構文を使用し、[RFC1123]のセクション2.1を使用します。このような名前は、「」で区切られたドメインラベルのシーケンスで構成されています。各ドメインラベルは、英数字の文字で始まり、場合によっては「 - 」文字も含まれています。DNSの完全に適格なドメイン名の右端のドメインラベルの後に、単一の「」が続く場合があります。また、完全なドメイン名とローカルドメインを区別する必要がある場合はそうです。
reg-name = *( unreserved / pct-encoded / sub-delims )
If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid.
URIスキームがホストのデフォルトを定義する場合、そのデフォルトは、ホストサブコンポーネントが未定義の場合、または登録名が空の場合（長さゼロ）に適用されます。たとえば、「ファイル」URIスキームは、権限、空のホスト、および「ローカルホスト」がすべてエンドユーザーのマシンを意味しないように定義されていますが、「HTTP」スキームは不足している権限または空のホストが無効と見なされます。
This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length.
この仕様は、特定の登録名Lookupテクノロジーを義務付けるものではないため、相互運用性に必要なものを超えて、reg名の構文を制限しません。代わりに、登録名の構文の問題をURI解像度を実行する各アプリケーションのオペレーティングシステムに委任し、そのオペレーティングシステムはホスト識別の目的で何ができるかを決定します。URI解像度の実装では、DNS、ホストテーブル、イエローページ、NetINFO、WINS、または登録名を検索するためのその他のシステムを使用する場合があります。ただし、DNS完全資格のドメイン名など、グローバルにスコープされた命名システムは、グローバルな範囲を持つことを目的としたURIに必要です。URIプロデューサーは、DNSの使用がすぐには明らかではなく、これらの名前を長さ255文字以下に制限する場合でも、DNS構文に準拠する名前を使用する必要があります。
The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology. Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent-encoded to be represented as URI characters. URI producing applications must not use percent-encoding in host unless it is used to represent a UTF-8 character sequence. When a non-ASCII registered name represents an internationalized domain name intended for resolution via the DNS, the name must be transformed to the IDNA encoding [RFC3490] prior to name lookup. URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding, if they wish to maximize interoperability with legacy URI resolvers.
reg-name構文は、根本的な名前解像度テクノロジーに依存しない均一な方法で非ASCII登録名を表すために、パーセントエンコードされたオクテットを許可します。非ASCII文字は最初にUTF-8 [STD63]に従ってエンコードする必要があり、次に、対応するUTF-8シーケンスの各オクテットは、URI文字として表すためにパーセントエンコードされなければなりません。URIの生産アプリケーションは、UTF-8文字シーケンスを表すために使用されない限り、ホストでパーセントエンコードを使用してはなりません。非ASCII登録名がDNSを介した解像度を目的とした国際化ドメイン名を表す場合、名前をルックアップの前に[RFC3490]エンコード[RFC3490]に変換する必要があります。URIプロデューサーは、レガシーURIリゾルバーとの相互運用性を最大化する場合は、パーセントエンコードではなく、IDNAエンコードでこれらの登録名を提供する必要があります。
The port subcomponent of authority is designated by an optional port number in decimal following the host and delimited from it by a single colon (":") character.
権限のポートサブコンポーネントは、ホストに続く小数のオプションのポート番号によって指定され、単一のコロン（ "："）文字によって区切られています。
port = *DIGIT
A scheme may define a default port. For example, the "http" scheme defines a default port of "80", corresponding to its reserved TCP port number. The type of port designated by the port number (e.g., TCP, UDP, SCTP) is defined by the URI scheme. URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default.
スキームは、デフォルトのポートを定義する場合があります。たとえば、「HTTP」スキームは、予約されたTCPポート番号に対応する「80」のデフォルトポートを定義します。ポート番号（TCP、UDP、SCTPなど）で指定されたポートのタイプは、URIスキームによって定義されます。URIプロデューサーとノーマイザーは、ポートコンポーネントとその「：」ポートが空の場合、またはその値がスキームのデフォルトの値と同じである場合は、デリミターを省略する必要があります。
The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The path is terminated by the first question mark ("?") or number sign ("#") character, or by the end of the URI.
パスコンポーネントには、通常は階層形式で編成されるデータが含まれており、非階層クエリコンポーネント（セクション3.4）のデータとともに、URIのスキームと命名当局の範囲内でリソースを特定するのに役立ちます（もしあれば）。パスは、最初の疑問符（ "？"）または数字記号（ "＃"）文字、またはURIの終わりによって終了します。
If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//"). In addition, a URI reference (Section 4.1) may be a relative-path reference, in which case the first path segment cannot contain a colon (":") character. The ABNF requires five separate rules to disambiguate these cases, only one of which will match the path substring within a given URI reference. We use the generic term "path component" to describe the URI substring matched by the parser to one of these rules.
URIに機関コンポーネントが含まれている場合、パスコンポーネントは空であるか、スラッシュ（ "/"）文字で開始する必要があります。URIに機関のコンポーネントが含まれていない場合、パスは2つのスラッシュ文字（ "//"）で開始できません。さらに、URI参照（セクション4.1）は相対パスの参照である場合があります。この場合、最初のパスセグメントにはコロン（ "："）文字を含めることはできません。ABNFは、これらのケースを乱用するために5つの個別のルールを必要としますが、そのうちの1つのみが特定のURI参照内のパスサブストリングと一致します。一般的な用語「パスコンポーネント」を使用して、これらのルールのいずれかにパーサーと一致するURIサブストリングを記述します。
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
A path consists of a sequence of path segments separated by a slash ("/") character. A path is always defined for a URI, though the defined path may be empty (zero length). Use of the slash character to indicate hierarchy is only required when a URI will be used as the context for relative references. For example, the URI <mailto:fred@example.com> has a path of "fred@example.com", whereas the URI <foo://info.example.com?fred> has an empty path.
パスは、スラッシュ（ "/"）文字で区切られた一連のパスセグメントで構成されています。定義されたパスは空（ゼロの長さ）である可能性がありますが、URIのパスは常に定義されます。階層を示すためにスラッシュ文字を使用することは、URIが相対的な参照のコンテキストとして使用される場合にのみ必要です。たとえば、uri <mailto：fred@example.com>には「fred@example.com」のパスがありますが、uri <foo：//info.example.com？fred>には空のパスがあります。
The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative-path reference (Section 4.2) to indicate relative position within the hierarchical tree of names. This is similar to their role within some operating systems' file directory structures to indicate the current directory and parent directory, respectively. However, unlike in a file system, these dot-segments are only interpreted within the URI path hierarchy and are removed as part of the resolution process (Section 5.2).
パスセグメント「」。ドットセグメントとも呼ばれる「..」は、パス名階層内の相対的な参照のために定義されます。それらは、相対パス参照（セクション4.2）の開始時に使用することを目的としており、名前の階層ツリー内の相対的な位置を示しています。これは、一部のオペレーティングシステムのファイルディレクトリ構造内の役割に似ており、それぞれ現在のディレクトリと親ディレクトリを示すものです。ただし、ファイルシステムとは異なり、これらのドットセグメントはURIパス階層内でのみ解釈され、解像度プロセスの一部として削除されます（セクション5.2）。
Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.
階層パスのドットセグメントは別として、汎用構文によってパスセグメントが不透明と見なされます。URIの生産アプリケーションは、多くの場合、セグメントで許可されている予約されたキャラクターを使用して、スキーム固有またはデレファレンスハンドラー固有のサブコンポーネントを区切ります。たとえば、Semicolon（ ";"）およびEquals（ "="）予約文字は、そのセグメントに適用されるパラメーターとパラメーター値を区切るためによく使用されます。コンマ（ "、"）予約されたキャラクターは、同様の目的に使用されることがよくあります。たとえば、1つのURIプロデューサーは、「名前; v = 1.1」などのセグメントを使用して「名前」のバージョン1.1への参照を示す場合がありますが、別のURIは「名前、1.1」などのセグメントを使用して同じことを示す場合があります。パラメータータイプはスキーム固有のセマンティクスによって定義される場合がありますが、ほとんどの場合、パラメーターの構文はURIの控除アルゴリズムの実装に固有です。
The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.
クエリコンポーネントには、パスコンポーネント内のデータとともに、URIのスキームと命名当局（もしあれば）の範囲内でリソースを特定するのに役立つ非階層データが含まれています。クエリコンポーネントは、最初の質問マーク（ "？"）文字で示され、数字サイン（ "＃"）文字またはURIの終わりによって終了します。
query = *( pchar / "/" / "?" )
The characters slash ("/") and question mark ("?") may represent data within the query component. Beware that some older, erroneous implementations may not handle such data correctly when it is used as the base URI for relative references (Section 5.1), apparently because they fail to distinguish query data from path data when looking for hierarchical separators. However, as query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI, it is sometimes better for usability to avoid percent-encoding those characters.
文字は、クエリコンポーネント内のデータを表す場合があります。階層分離器を探すときにクエリデータをPATHデータと区別できないようです。ただし、クエリコンポーネントは、「key = value」ペアの形で識別情報を携帯するためによく使用されるため、頻繁に使用される値は別のURIへの参照であるため、ユーザビリティがそれらのキャラクターをエンコードすることを避けることができる場合があります。
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.
URIのフラグメント識別子コンポーネントは、主要なリソースと追加の識別情報を参照することにより、二次リソースの間接的な識別を可能にします。特定された二次リソースは、主要なリソースの一部またはサブセット、主要なリソースの表現に関するある程度の見解、またはそれらの表現によって定義または説明されている他のリソースである場合があります。フラグメント識別子コンポーネントは、数字サイン（ "＃"）文字の存在によって示され、URIの終わりまでに終了します。
fragment = *( pchar / "/" / "?" )
The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.
フラグメント識別子のセマンティクスは、主要なリソースの検索アクションから生じる可能性のある表現セットによって定義されます。したがって、フラグメントの形式と解像度は、潜在的に検索された表現のメディアタイプ[RFC2046]に依存しますが、そのような検索は、URIが控除された場合にのみ実行されます。そのような表現が存在しない場合、フラグメントのセマンティクスは不明であると見なされ、効果的に制約されていません。フラグメント識別子セマンティクスはURIスキームに依存しないため、スキーム仕様で再定義することはできません。
Individual media types may define their own restrictions on or structures within the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations. Each representation should either define the fragment so that it corresponds to the same secondary resource, regardless of how it is represented, or should leave the fragment undefined (i.e., not found).
個々のメディアタイプは、そのメディアタイプによって二次リソースとして識別可能なさまざまなタイプのサブセット、ビュー、または外部参照を指定するためのフラグメント識別子構文内の独自の制限または構造を定義する場合があります。プライマリリソースに複数の表現がある場合、検索要求の属性（別名、コンテンツネゴシエーション）に基づいて表現が選択されるリソースの場合が多い場合、フラグメントによって識別されるものはすべて、これらすべての表現で一貫しているはずです。各表現は、それがどのように表現されているかに関係なく、同じ二次リソースに対応するようにフラグメントを定義するか、フラグメントを未定義のままにする（つまり、見つかりません）のいずれかを定義する必要があります。
As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place. A URI with a fragment identifier may be used to refer to the secondary resource without any implication that the primary resource is accessible or will ever be accessed.
他のURIと同様に、フラグメント識別子コンポーネントの使用は、検索アクションが行われることを意味するものではありません。フラグメント識別子を備えたURIを使用して、主要なリソースにアクセスできるか、アクセスできることを示すことなく、二次リソースを参照することができます。
Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing, allowing an author to specifically identify aspects of an existing resource that are only indirectly provided by the resource owner. As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively. Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification.
フラグメント識別子は、クライアント側の間接参照の主要な形式として情報検索システムに特別な役割を果たし、著者がリソース所有者によって間接的にのみ提供される既存のリソースの側面を具体的に特定できるようにします。そのため、フラグメント識別子は、URIのスキーム固有の処理では使用されません。代わりに、フラグメント識別子は、控除の前にURIの残りの部分から分離されているため、フラグメント自体内の識別情報は、URIスキームに関係なく、ユーザーエージェントのみが参照されます。この個別の取り扱いは、特にリソースが時間の経過とともに移動するため、特にリソースの正確なリダイレクトのために情報の損失であると認識されることがよくありますが、情報プロバイダーが参照著者がリソース内の情報を選択的に参照する権利を否定するのを防ぐのにも役立ちます。間接的な参照は、新しいメディアタイプが新しい識別スキームよりも定義および展開しやすいため、URIを使用するシステムに追加の柔軟性と拡張性を提供します。
The characters slash ("/") and question mark ("?") are allowed to represent data within the fragment identifier. Beware that some older, erroneous implementations may not handle this data correctly when it is used as the base URI for relative references (Section 5.1).
キャラクターのスラッシュ（ "/"）および質問マーク（ "？"）は、フラグメント識別子内のデータを表すことが許可されています。一部の古い誤った実装は、相対参照のベースURIとして使用されている場合、このデータを正しく処理できない場合があることに注意してください（セクション5.1）。
When applications make reference to a URI, they do not always use the full form of reference defined by the "URI" syntax rule. To save space and take advantage of hierarchical locality, many Internet protocol elements and media type formats allow an abbreviation of a URI, whereas others restrict the syntax to a particular form of URI. We define the most common forms of reference syntax in this specification because they impact and depend upon the design of the generic syntax, requiring a uniform parsing algorithm in order to be interpreted consistently.
アプリケーションがURIを参照する場合、「URI」構文ルールで定義された参照の完全な形式を常に使用するとは限りません。スペースを節約し、階層的なローカリティを活用するために、多くのインターネットプロトコル要素とメディアタイプ形式によりURIの略語が可能になりますが、他の人は特定の形式のURIに制限します。一般的な構文の設計に影響を及ぼし、一貫して解釈するために均一な解析アルゴリズムを必要とするため、この仕様で参照構文の最も一般的な形式を定義します。
URI-reference is used to denote the most common usage of a resource identifier.
URI-Referenceは、リソース識別子の最も一般的な使用法を示すために使用されます。
URI-reference = URI / relative-ref
A URI-reference is either a URI or a relative reference. If the URI-reference's prefix does not match the syntax of a scheme followed by its colon separator, then the URI-reference is a relative reference.
URI-referenceは、URIまたは相対参照のいずれかです。URI-Referenceのプレフィックスが、そのコロン分離器が続くスキームの構文と一致しない場合、URI-Referenceは相対的な参照です。
A URI-reference is typically parsed first into the five URI components, in order to determine what components are present and whether the reference is relative. Then, each component is parsed for its subparts and their validation. The ABNF of URI-reference, along with the "first-match-wins" disambiguation rule, is sufficient to define a validating parser for the generic syntax. Readers familiar with regular expressions should see Appendix B for an example of a non-validating URI-reference parser that will take any given string and extract the URI components.
URIの参照は、通常、最初に5つのURIコンポーネントに解析され、どのコンポーネントが存在するか、参照が相対的かどうかを判断します。次に、各コンポーネントはサブパートとその検証に対して解析されます。Uri-ReferenceのABNFは、「最初の試合」の曖昧性状態ルールとともに、一般的な構文の検証パーサーを定義するのに十分です。正規表現に精通している読者は、特定の文字列を使用してURIコンポーネントを抽出する、検証されていないURI参照パーサーの例については、付録Bを参照する必要があります。
A relative reference takes advantage of the hierarchical syntax (Section 1.2.3) to express a URI reference relative to the name space of another hierarchical URI.
相対的な参照は、階層構文（セクション1.2.3）を利用して、別の階層URIの名前空間に対するURI参照を表現します。
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-ref = relative-part ["？"クエリ] ["＃"フラグメント]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
The URI referred to by a relative reference, also known as the target URI, is obtained by applying the reference resolution algorithm of Section 5.
ターゲットURIとも呼ばれる相対参照によって言及されるURIは、セクション5の参照解像度アルゴリズムを適用することにより取得されます。
A relative reference that begins with two slash characters is termed a network-path reference; such references are rarely used. A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference.
2つのスラッシュ文字から始まる相対的な参照は、ネットワークパスリファレンスと呼ばれます。このような参照はめったに使用されません。単一のスラッシュ文字から始まる相対的な参照は、絶対パス参照と呼ばれます。スラッシュ文字から始まらない相対的な参照は、相対パス参照と呼ばれます。
A path segment that contains a colon character (e.g., "this:that") cannot be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name. Such a segment must be preceded by a dot-segment (e.g., "./this:that") to make a relative-path reference.
コロン文字を含むパスセグメント（たとえば、 "this：this"）は、スキーム名と間違われるため、相対パス参照の最初のセグメントとして使用することはできません。このようなセグメントは、相対パスの参照を作成するには、ドットセグメント（ "./this：that"）が先行する必要があります。
Some protocol elements allow only the absolute form of a URI without a fragment identifier. For example, defining a base URI for later use by relative references calls for an absolute-URI syntax rule that does not allow a fragment.
一部のプロトコル要素は、フラグメント識別子のないURIの絶対形式のみを許可します。たとえば、後で使用するためにベースURIを定義する相対参照で使用すると、フラグメントを許可しない絶対尿の構文ルールが必要です。
absolute-URI = scheme ":" hier-part [ "?" query ]
Absolute-uri = scheme "：" Hier-Part ["？"クエリ]
URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar. Scheme specifications will not define fragment identifier syntax or usage, regardless of its applicability to resources identifiable via that scheme, as fragment identification is orthogonal to scheme definition. However, scheme specifications are encouraged to include a wide range of examples, including examples that show use of the scheme's URIs with fragment identifiers when such usage is appropriate.
URIスキームの仕様は、スキーム固有の構文に一致するすべての文字列が<absolute-uri>文法にも一致するように、独自の構文を定義する必要があります。スキームの仕様は、フラグメント識別がスキーム定義に直交するため、そのスキームで識別可能なリソースへの適用性に関係なく、フラグメント識別子の構文または使用法を定義しません。ただし、スキームの仕様は、そのような使用法が適切な場合にスキームのURIをフラグメント識別子で使用することを示す例を含む、幅広い例を含めることをお勧めします。
When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a "same-document" reference. The most frequent examples of same-document references are relative references that are empty or include only the number sign ("#") separator followed by a fragment identifier.
URI参照がURIを指し、つまり、そのフラグメントコンポーネント（存在する場合）を除いて、ベースURI（セクション5.1）と同一である場合、その参照は「同じドキュメント」参照と呼ばれます。同じドキュメント参照の最も頻繁な例は、空の相対的な参照であるか、数字記号（ "＃"）セパレーターのみがフラグメント識別子のみが含まれます。
When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action.
同じドキュメントリファレンスが検索アクションのために参照される場合、その参照のターゲットは、参照と同じエンティティ（表現、ドキュメント、またはメッセージ）内にあると定義されます。したがって、逆方向に新しい検索アクションにつながるべきではありません。
Normalization of the base and target URIs prior to their comparison, as described in Sections 6.2.2 and 6.2.3, is allowed but rarely performed in practice. Normalization may increase the set of same-document references, which may be of benefit to some caching applications. As such, reference authors should not assume that a slightly different, though equivalent, reference URI will (or will not) be interpreted as a same-document reference by any given application.
セクション6.2.2および6.2.3で説明されているように、比較前のベースとターゲットURIの正規化は許可されていますが、実際にはめったに実行されません。正規化は、同じドキュメント参照のセットを増やす可能性があり、これは一部のキャッシュアプリケーションにとって有益な場合があります。そのため、参照著者は、同等のものですが、参照URIは、特定のアプリケーションによって同じドキュメントリファレンスとして解釈される（またはそうでない）ことがわずかに異なると仮定すべきではありません。
The URI syntax is designed for unambiguous reference to resources and extensibility via the URI scheme. However, as URI identification and usage have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used a suffix of the URI as a reference, consisting of only the authority and path portions of the URI, such as
URI構文は、URIスキームを介したリソースへの明確な参照と拡張性のために設計されています。ただし、URIの識別と使用法が一般的になっているため、従来のメディア（テレビ、ラジオ、新聞、看板など）は、URIの権限とパス部分のみで構成されるURIの接尾辞を参照としてますます使用しています。として
www.w3.org/Addressing/
or simply a DNS registered name on its own. Such references are primarily intended for human interpretation rather than for machines, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., most registered names beginning with "www" are likely to have a URI prefix of "http://"). Although there is no standard set of heuristics for disambiguating a URI suffix, many client implementations allow them to be entered by the user and heuristically resolved.
または、単にDNS登録名だけです。このような参照は、主にマシンではなく人間の解釈を目的としています。コンテキストベースのヒューリスティックがURIを完了するのに十分であるという仮定（たとえば、「www」から始まるほとんどの登録名には、「http：/」のURIプレフィックスがある可能性があります。/"）。URIの接尾辞を掘り下げるための標準的なヒューリスティックセットはありませんが、多くのクライアントの実装により、ユーザーが入力し、ヒューリスティックな解決を可能にします。
Although this practice of using suffix references is common, it should be avoided whenever possible and should never be used in situations where long-term references are expected. The heuristics noted above will change over time, particularly when a new URI scheme becomes popular, and are often incorrect when used out of context. Furthermore, they can lead to security issues along the lines of those described in [RFC1535].
接尾辞参照を使用するこの慣行は一般的ですが、可能な限り避けるべきであり、長期的な参照が予想される状況では使用しないでください。上記のヒューリスティックは、特に新しいURIスキームが一般的になり、コンテキストから使用すると不正確になることが多い場合、時間とともに変化します。さらに、[RFC1535]に記載されているものの方針に沿ってセキュリティ問題につながる可能性があります。
As a URI suffix has the same syntax as a relative-path reference, a suffix reference cannot be used in contexts where a relative reference is expected. As a result, suffix references are limited to places where there is no defined base URI, such as dialog boxes and off-line advertisements.
URIの接尾辞には相対パス参照と同じ構文があるため、相対参照が予想されるコンテキストでは、接尾辞参照を使用することはできません。その結果、サフィックス参照は、ダイアログボックスやオフライン広告など、定義されたベースURIがない場所に限定されます。
This section defines the process of resolving a URI reference within a context that allows relative references so that the result is a string matching the <URI> syntax rule of Section 3.
このセクションでは、相対参照を許可するコンテキスト内でURI参照を解決するプロセスを定義して、結果がセクション3の<uri>構文ルールに一致する文字列になります。
The term "relative" implies that a "base URI" exists against which the relative reference is applied. Aside from fragment-only references (Section 4.4), relative references are only usable when a base URI is known. A base URI must be established by the parser prior to parsing URI references that might be relative. A base URI must conform to the <absolute-URI> syntax rule (Section 4.3). If the base URI is obtained from a URI reference, then that reference must be converted to absolute form and stripped of any fragment component prior to its use as a base URI.
「相対」という用語は、「ベースURI」が存在し、相対参照が適用されることを意味します。フラグメントのみの参照（セクション4.4）は別として、相対的な参照は、ベースURIが既知の場合にのみ使用可能です。相対的なURI参照を解析する前に、ベースURIをパーサーによって確立する必要があります。ベースURIは、<absolute-uri>構文ルール（セクション4.3）に準拠する必要があります。ベースURIがURI参照から取得される場合、その参照は、ベースURIとして使用する前に、絶対形式に変換され、フラグメントコンポーネントを剥がす必要があります。
The base URI of a reference can be established in one of four ways, discussed below in order of precedence. The order of precedence can be thought of in terms of layers, where the innermost defined base URI has the highest precedence. This can be visualized graphically as follows:
参照のベースURIは、4つの方法のいずれかで確立できます。優先順位は、最も内側の定義されたベースURIが最も優先されるレイヤーの観点から考えることができます。これは、次のようにグラフィカルに視覚化できます。
.----------------------------------------------------------.
| .----------------------------------------------------. |
| | .----------------------------------------------. | |
| | | .----------------------------------------. | | |
| | | | .----------------------------------. | | | |
| | | | | <relative-reference> | | | | |
| | | | `----------------------------------' | | | |
| | | | (5.1.1) Base URI embedded in content | | | |
| | | `----------------------------------------' | | |
| | | (5.1.2) Base URI of the encapsulating entity | | |
| | | (message, representation, or none) | | |
| | `----------------------------------------------' | |
| | (5.1.3) URI used to retrieve the entity | |
| `----------------------------------------------------' |
| (5.1.4) Default Base URI (application-dependent) |
`----------------------------------------------------------'
Within certain media types, a base URI for relative references can be embedded within the content itself so that it can be readily obtained by a parser. This can be useful for descriptive documents, such as tables of contents, which may be transmitted to others through protocols other than their usual retrieval context (e.g., email or USENET news).
特定のメディアタイプ内では、相対参照のベースURIをコンテンツ自体に埋め込むことができ、パーサーによって容易に取得できます。これは、通常の検索コンテキスト以外のプロトコル（電子メールやUsenetニュースなど）を介して他の人に送信できる内容の表などの説明文書に役立ちます。
It is beyond the scope of this specification to specify how, for each media type, a base URI can be embedded. The appropriate syntax, when available, is described by the data format specification associated with each media type.
この仕様の範囲を超えて、各メディアタイプについて、ベースURIをどのように埋め込むことができるかを指定します。適切な構文は、利用可能な場合、各メディアタイプに関連付けられたデータ形式の仕様によって説明されます。
If no base URI is embedded, the base URI is defined by the representation's retrieval context. For a document that is enclosed within another entity, such as a message or archive, the retrieval context is that entity. Thus, the default base URI of a representation is the base URI of the entity in which the representation is encapsulated.
ベースURIが埋め込まれていない場合、ベースURIは表現の検索コンテキストによって定義されます。メッセージやアーカイブなどの別のエンティティ内に囲まれているドキュメントの場合、検索コンテキストはそのエンティティです。したがって、表現のデフォルトのベースURIは、表現がカプセル化されているエンティティのベースURIです。
A mechanism for embedding a base URI within MIME container types (e.g., the message and multipart types) is defined by MHTML [RFC2557]. Protocols that do not use the MIME message header syntax, but that do allow some form of tagged metadata to be included within messages, may define their own syntax for defining a base URI as part of a message.
MIMEコンテナタイプ（メッセージやマルチパートタイプなど）にベースURIを埋め込むメカニズムは、MHTML [RFC2557]によって定義されます。Mimeメッセージヘッダーの構文を使用していないが、何らかの形のタグ付きメタデータをメッセージに含めることができるプロトコルは、ベースURIをメッセージの一部として定義するための独自の構文を定義する場合があります。
If no base URI is embedded and the representation is not encapsulated within some other entity, then, if a URI was used to retrieve the representation, that URI shall be considered the base URI. Note that if the retrieval was the result of a redirected request, the last URI used (i.e., the URI that resulted in the actual retrieval of the representation) is the base URI.
ベースURIが埋め込まれておらず、表現が他のエンティティ内にカプセル化されていない場合、URIを使用して表現を取得した場合、URIはベースURIと見なされます。検索がリダイレクトされた要求の結果である場合、使用された最後のURI（つまり、表現の実際の検索をもたらしたURI）がベースURIであることに注意してください。
If none of the conditions described above apply, then the base URI is defined by the context of the application. As this definition is necessarily application-dependent, failing to define a base URI by using one of the other methods may result in the same content being interpreted differently by different types of applications.
上記の条件のいずれも適用されない場合、ベースURIはアプリケーションのコンテキストによって定義されます。この定義は必然的にアプリケーションに依存しているため、他のメソッドのいずれかを使用してベースURIを定義できない場合、同じコンテンツが異なるタイプのアプリケーションによって異なって解釈される場合があります。
A sender of a representation containing relative references is responsible for ensuring that a base URI for those references can be established. Aside from fragment-only references, relative references can only be used reliably in situations where the base URI is well defined.
相対的な参照を含む表現の送信者は、それらの参照のベースURIを確立できることを保証する責任があります。フラグメントのみの参照とは別に、相対的な参照は、ベースURIが明確に定義されている状況でのみ確実に使用できます。
This section describes an algorithm for converting a URI reference that might be relative to a given base URI into the parsed components of the reference's target. The components can then be recomposed, as described in Section 5.3, to form the target URI. This algorithm provides definitive results that can be used to test the output of other implementations. Applications may implement relative reference resolution by using some other algorithm, provided that the results match what would be given by this one.
このセクションでは、特定のベースURIに関連する可能性のあるURI参照を、参照のターゲットの解析コンポーネントに変換するためのアルゴリズムについて説明します。セクション5.3で説明されているように、コンポーネントを再構成して、ターゲットURIを形成できます。このアルゴリズムは、他の実装の出力をテストするために使用できる決定的な結果を提供します。結果がこれによって与えられるものと一致する場合、アプリケーションは他のアルゴリズムを使用して相対的な参照解像度を実装する場合があります。
The base URI (Base) is established according to the procedure of Section 5.1 and parsed into the five main components described in Section 3. Note that only the scheme component is required to be present in a base URI; the other components may be empty or undefined. A component is undefined if its associated delimiter does not appear in the URI reference; the path component is never undefined, though it may be empty.
ベースURI（ベース）は、セクション5.1の手順に従って確立され、セクション3で説明されている5つの主要コンポーネントに解析されます。スキームコンポーネントのみがベースURIに存在する必要があることに注意してください。他のコンポーネントは空または未定義の場合があります。関連するデリミッターがURIリファレンスに表示されない場合、コンポーネントは未定義です。パスコンポーネントは不明確ではありませんが、空の可能性があります。
Normalization of the base URI, as described in Sections 6.2.2 and 6.2.3, is optional. A URI reference must be transformed to its target URI before it can be normalized.
セクション6.2.2および6.2.3で説明されているように、ベースURIの正規化はオプションです。URI参照は、正規化する前にターゲットURIに変換する必要があります。
For each URI reference (R), the following pseudocode describes an algorithm for transforming R into its target URI (T):
各URI参照（R）について、次の擬似コードは、rをターゲットURI（t）に変換するためのアルゴリズムを説明しています。
-- The URI reference is parsed into the five URI components -- (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
-URI参照は5つのURIコンポーネントに解析されます - （R.Scheme、R.Authority、R.Path、R.Query、R.Fragment）= parse（r）;
-- A non-strict parser may ignore a scheme in the reference
-- if it is identical to the base URI's scheme.
--
if ((not strict) and (R.scheme == Base.scheme)) then
undefine(R.scheme);
endif;
if defined(R.scheme) then
T.scheme = R.scheme;
T.authority = R.authority;
T.path = remove_dot_segments(R.path);
T.query = R.query;
else
if defined(R.authority) then
T.authority = R.authority;
T.path = remove_dot_segments(R.path);
T.query = R.query;
else
if (R.path == "") then
T.path = Base.path;
if defined(R.query) then
T.query = R.query;
else
T.query = Base.query;
endif;
else
if (R.path starts-with "/") then
T.path = remove_dot_segments(R.path);
else
T.path = merge(Base.path, R.path);
T.path = remove_dot_segments(T.path);
endif;
T.query = R.query;
endif;
T.authority = Base.authority;
endif;
T.scheme = Base.scheme;
endif;
T.fragment = R.fragment;
T.Fragment = R.Fragment;
The pseudocode above refers to a "merge" routine for merging a relative-path reference with the path of the base URI. This is accomplished as follows:
上記の擬似コードは、相対パスの参照をベースURIの経路と統合するための「マージ」ルーチンを指します。これは次のように達成されます。
o If the base URI has a defined authority component and an empty path, then return a string consisting of "/" concatenated with the reference's path; otherwise,
o ベースURIに定義された権限コンポーネントと空のパスがある場合、参照パスと連結された「/」で構成される文字列を返します。さもないと、
o return a string consisting of the reference's path component appended to all but the last segment of the base URI's path (i.e., excluding any characters after the right-most "/" in the base URI path, or excluding the entire base URI path if it does not contain any "/" characters).
o 基本URIのパスの最後のセグメント以外のすべてに追加された参照のパスコンポーネントで構成される文字列を返します（つまり、ベースURIパスの適切な "/"の後に任意の文字を除外するか、ベースURIパス全体を除外します。「/」文字が含まれていません）。
The pseudocode also refers to a "remove_dot_segments" routine for interpreting and removing the special "." and ".." complete path segments from a referenced path. This is done after the path is extracted from a reference, whether or not the path was relative, in order to remove any invalid or extraneous dot-segments prior to forming the target URI. Although there are many ways to accomplish this removal process, we describe a simple method using two string buffers.
PSEUDOCODEは、スペシャルを解釈および削除するための「remove_dot_segments」ルーチンを指します。および「..」参照されたパスからの完全なパスセグメント。これは、ターゲットURIを形成する前に無効または外部のドットセグメントを除去するために、パスが相対的であるかどうかにかかわらず、パスが参照から抽出された後に行われます。この削除プロセスを達成するには多くの方法がありますが、2つの文字列バッファーを使用した簡単な方法について説明します。
1. The input buffer is initialized with the now-appended path components and the output buffer is initialized to the empty string.
1. 入力バッファーは、現在添付されたパスコンポーネントで初期化され、出力バッファーは空の文字列に初期化されます。
2. While the input buffer is not empty, loop as follows:
2. 入力バッファーは空ではありませんが、次のようにループします。
A. If the input buffer begins with a prefix of "../" or "./", then remove that prefix from the input buffer; otherwise,
A.入力バッファが「../」または「./」のプレフィックスで始まる場合、入力バッファーからそのプレフィックスを削除します。さもないと、
B. if the input buffer begins with a prefix of "/./" or "/.", where "." is a complete path segment, then replace that prefix with "/" in the input buffer; otherwise,
B.入力バッファが「/./」または「/」のプレフィックスで始まる場合、 "" "。完全なパスセグメントであり、そのプレフィックスを入力バッファーの「/」に置き換えます。さもないと、
C. if the input buffer begins with a prefix of "/../" or "/..", where ".." is a complete path segment, then replace that prefix with "/" in the input buffer and remove the last segment and its preceding "/" (if any) from the output buffer; otherwise,
C.入力バッファが「/../」または「/..」のプレフィックスで始まる場合、ここで、「..」は完全なパスセグメントです。そのプレフィックスを入力バッファーの「/」に置き換え、最後のセグメントとその前の「/」（存在する場合）出力バッファーから。さもないと、
D. if the input buffer consists only of "." or "..", then remove that from the input buffer; otherwise,
D.入力バッファーが「。」のみが構成されている場合または「..」、次に入力バッファーからそれを削除します。さもないと、
E. move the first path segment in the input buffer to the end of the output buffer, including the initial "/" character (if any) and any subsequent characters up to, but not including, the next "/" character or the end of the input buffer.
E.入力バッファーの最初のパスセグメントを出力バッファーの端まで移動します。これには、初期の「/」文字（もしあれば）および次の文字を含むが次の文字が含まれていません。入力バッファーの。
3. Finally, the output buffer is returned as the result of remove_dot_segments.
3. 最後に、remove_dot_segmentsの結果として出力バッファーが返されます。
Note that dot-segments are intended for use in URI references to express an identifier relative to the hierarchy of names in the base URI. The remove_dot_segments algorithm respects that hierarchy by removing extra dot-segments rather than treat them as an error or leaving them to be misinterpreted by dereference implementations.
ドットセグメントは、URI参照で使用することを目的としており、ベースURIの名前の階層と比較して識別子を表現します。remove_dot_segmentsアルゴリズムは、それらをエラーとして扱うのではなく、追加のドットセグメントを削除するか、控除の実装によって誤って解釈されるようにすることにより、その階層を尊重します。
The following illustrates how the above steps are applied for two examples of merged paths, showing the state of the two buffers after each step.
以下は、マージされたパスの2つの例に上記の手順がどのように適用されるかを示しており、各ステップの後に2つのバッファーの状態を示しています。
STEP OUTPUT BUFFER INPUT BUFFER
ステップ出力バッファー入力バッファー
1 : /a/b/c/./../../g
2E: /a /b/c/./../../g
2E: /a/b /c/./../../g
2E: /a/b/c /./../../g
2B: /a/b/c /../../g
2C: /a/b /../g
2C: /a /g
2E: /a/g
STEP OUTPUT BUFFER INPUT BUFFER
ステップ出力バッファー入力バッファー
1 : mid/content=5/../6
2E: mid /content=5/../6
2E: mid/content=5 /../6
2C: mid /6
2E: mid/6
Some applications may find it more efficient to implement the remove_dot_segments algorithm by using two segment stacks rather than strings.
一部のアプリケーションでは、文字列ではなく2つのセグメントスタックを使用して、remove_dot_segmentsアルゴリズムを実装する方が効率的である場合があります。
Note: Beware that some older, erroneous implementations will fail to separate a reference's query component from its path component prior to merging the base and reference paths, resulting in an interoperability failure if the query component contains the strings "/../" or "/./".
注：いくつかの古い誤った実装は、基本パスと参照パスをマージする前に、参照のクエリコンポーネントをパスコンポーネントから分離できないため、クエリコンポーネントに文字列「/../」が含まれている場合、相互運用性の障害になります。/./ "。
Parsed URI components can be recomposed to obtain the corresponding URI reference string. Using pseudocode, this would be:
解析されたURIコンポーネントを再構成して、対応するURI参照文字列を取得できます。擬似コードを使用すると、これは次のとおりです。
result = ""
結果= ""
if defined(scheme) then
append scheme to result;
append ":" to result;
endif;
if defined(authority) then
append "//" to result;
append authority to result;
endif;
append path to result;
結果へのパスを追加します。
if defined(query) then
append "?" to result;
append query to result;
endif;
if defined(fragment) then
append "#" to result;
append fragment to result;
endif;
return result;
返品結果;
Note that we are careful to preserve the distinction between a component that is undefined, meaning that its separator was not present in the reference, and a component that is empty, meaning that the separator was present and was immediately followed by the next component separator or the end of the reference.
未定義のコンポーネントの区別を保存するように注意していることに注意してください。つまり、そのセパレーターは参照に存在せず、空のコンポーネントはセパレーターが存在し、すぐに次のコンポーネントセパレーターまたはその後に続いたことを意味します。参照の終わり。
Within a representation with a well defined base URI of
明確に定義されたベースURIを持つ表現内
http://a/b/c/d;p?q
a relative reference is transformed to its target URI as follows.
相対的な参照は、次のようにターゲットURIに変換されます。
"g:h" = "g:h"
"g" = "http://a/b/c/g"
"./g" = "http://a/b/c/g"
"g/" = "http://a/b/c/g/"
"/g" = "http://a/g"
"//g" = "http://g"
"?y" = "http://a/b/c/d;p?y"
"g?y" = "http://a/b/c/g?y"
"#s" = "http://a/b/c/d;p?q#s"
"g#s" = "http://a/b/c/g#s"
"g?y#s" = "http://a/b/c/g?y#s"
";x" = "http://a/b/c/;x"
"g;x" = "http://a/b/c/g;x"
"g;x?y#s" = "http://a/b/c/g;x?y#s"
"" = "http://a/b/c/d;p?q"
"." = "http://a/b/c/"
"./" = "http://a/b/c/"
".." = "http://a/b/"
"../" = "http://a/b/"
"../g" = "http://a/b/g"
"../.." = "http://a/"
"../../" = "http://a/"
"../../g" = "http://a/g"
Although the following abnormal examples are unlikely to occur in normal practice, all URI parsers should be capable of resolving them consistently. Each example uses the same base as that above.
次の異常な例は通常の診療では起こりそうにありませんが、すべてのURIパーサーはそれらを一貫して解決できるはずです。それぞれの例は、上記と同じベースを使用します。
Parsers must be careful in handling cases where there are more ".." segments in a relative-path reference than there are hierarchical levels in the base URI's path. Note that the ".." syntax cannot be used to change the authority component of a URI.
パーサーは、ベースURIのパスに階層レベルがあるよりも、相対パス参照にもっと多くの「..」セグメントがある場合に注意する必要があります。「..」構文は、URIの権限コンポーネントを変更するために使用できないことに注意してください。
"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"
Similarly, parsers must remove the dot-segments "." and ".." when they are complete components of a path, but not when they are only part of a segment.
同様に、パーサーはドットセグメントを削除する必要があります。「..」は、パスの完全なコンポーネントであるが、セグメントの一部にすぎない場合はそうではありません。
"/./g" = "http://a/g"
"/../g" = "http://a/g"
"g." = "http://a/b/c/g."
".g" = "http://a/b/c/.g"
"g.." = "http://a/b/c/g.."
"..g" = "http://a/b/c/..g"
Less likely are cases where the relative reference uses unnecessary or nonsensical forms of the "." and ".." complete path segments.
相対的な参照が「」の不必要または無意味な形式を使用する場合は、および「..」完全なパスセグメント。
"./../g" = "http://a/b/g"
"./g/." = "http://a/b/c/g/"
"g/./h" = "http://a/b/c/g/h"
"g/../h" = "http://a/b/c/h"
"g;x=1/./y" = "http://a/b/c/g;x=1/y"
"g;x=1/../y" = "http://a/b/c/y"
Some applications fail to separate the reference's query and/or fragment components from the path component before merging it with the base path and removing dot-segments. This error is rarely noticed, as typical usage of a fragment never includes the hierarchy ("/") character and the query component is not normally used within relative references.
一部のアプリケーションは、参照のクエリおよび/またはフラグメントコンポーネントをパスコンポーネントから分離してから、ベースパスとマージしてドットセグメントを削除しません。フラグメントの典型的な使用法には階層（ "/"）文字が含まれず、クエリコンポーネントは相対的な参照内では通常使用されないため、このエラーはめったに気付かれません。
"g?y/./x" = "http://a/b/c/g?y/./x"
"g?y/../x" = "http://a/b/c/g?y/../x"
"g#s/./x" = "http://a/b/c/g#s/./x"
"g#s/../x" = "http://a/b/c/g#s/../x"
Some parsers allow the scheme name to be present in a relative reference if it is the same as the base URI scheme. This is considered to be a loophole in prior specifications of partial URI [RFC1630]. Its use should be avoided but is allowed for backward compatibility.
一部のパーサーでは、ベースURIスキームと同じ場合、スキーム名が相対参照に存在することを許可します。これは、部分的なURIの以前の仕様の抜け穴であると考えられています[RFC1630]。その使用は避けるべきですが、後方互換性のために許可されています。
"http:g" = "http:g" ; for strict parsers
/ "http://a/b/c/g" ; for backward compatibility
One of the most common operations on URIs is simple comparison: determining whether two URIs are equivalent without using the URIs to access their respective resource(s). A comparison is performed every time 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 URIs is often used by spiders and indexing engines to prune a search space or to reduce duplication of request actions and response storage.
URISで最も一般的な操作の1つは、単純な比較です。URIを使用してそれぞれのリソースにアクセスすることなく、2つのURIが同等であるかどうかを判断することです。応答キャッシュにアクセスするたびに比較が実行されます。ブラウザは履歴をチェックしてリンクを色付けするか、XMLパーサープロセスタグを名前空間内にプロセスします。URIの比較前の広範な正規化は、クモとインデックスエンジンによってよく使用され、検索スペースを剪定したり、リクエストアクションと応答ストレージの重複を減らしたりします。
URI comparison is performed for some particular purpose. Protocols or implementations that compare URIs 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 URIs, the trade-offs between them, and the types of applications that might use them.
URIの比較は、特定の目的のために実行されます。さまざまな目的でURIを比較するプロトコルまたは実装は、多くの場合、エイリアスの識別子を減らすためにどれだけの努力を費やすべきかに関して、異なる設計トレードオフの対象となります。このセクションでは、URI、それらの間のトレードオフ、およびそれらを使用する可能性のあるアプリケーションの種類を比較するために使用できるさまざまな方法について説明します。
Because URIs 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 URIs 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.
urisはリソースを識別するために存在するため、おそらく同じリソースを識別するときに同等と見なされるべきです。ただし、この等価性の定義は、実装が完全に使用されていないため、2つのリソースを完全に知識または制御しない限り、2つのリソースを比較する方法がないため、あまり実用的ではありません。このため、URIの等価性または違いの決定は、文字列比較に基づいており、おそらくURIスキーム定義によって提供される追加のルールを参照することにより増強されます。「異なる」と「同等の」という用語を使用して、そのような比較の可能な結果を記述しますが、同等性のアプリケーション依存バージョンはたくさんあります。
Even though it is possible to determine that two URIs are equivalent, URI comparison is not sufficient to determine whether two URIs 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 URIs. Therefore, comparison methods are designed to minimize false negatives while strictly avoiding false positives.
2つのURIが同等であると判断することは可能ですが、URIの比較は2つのURIが異なるリソースを識別するかどうかを判断するのに十分ではありません。たとえば、2つの異なるドメイン名の所有者は、両方から同じリソースを提供することを決定し、2つの異なるURIになります。したがって、比較方法は、誤検知を厳密に回避しながら、偽陰性を最小限に抑えるように設計されています。
In testing for equivalence, applications should not directly compare relative references; the references should be converted to their respective target URIs before comparison. When URIs 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.
同等性のテストでは、アプリケーションは相対的な参照を直接比較してはなりません。参照は、比較前にそれぞれのターゲットURIに変換する必要があります。URIが表現の取得などのネットワークアクションを選択（または回避する）と比較した場合、フラグメントコンポーネント（ある場合）を比較から除外する必要があります。
A variety of methods are used in practice to test URI 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.
実際には、URIの等価性をテストするためにさまざまな方法が使用されています。これらの方法は、必要な処理量と偽陰性の確率が低下する程度によって区別される範囲に分類されます。上記のように、偽のネガを排除することはできません。実際には、それらの確率を減らすことができますが、この削減にはより多くの処理が必要であり、すべてのアプリケーションで費用対効果が高くありません。
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 URIs, 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.
2つのURIがキャラクター文字列と見なされる場合、同一である場合、それらが同等であると結論付けるのは安全です。このタイプの同等性テストは、計算コストが非常に低く、特に解析の領域ではさまざまなアプリケーションで広く使用されています。
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 form. For example, should one URI be stored in a byte array in EBCDIC encoding and the second in a Java String object (UTF-16), bit-for-bit comparisons applied naively will produce errors. It is better to speak of equality on a character-for-character basis 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.
このキャラクターの比較では、各ペアの文字を同等の形式にする必要があります。たとえば、1つのURIをEBCDICエンコーディングのバイト配列に保存し、2番目のURIがJava Stringオブジェクト（UTF-16）に保存された場合、ビットビット比較をナイーワブに適用するとエラーが発生します。バイトのバイトやビットベースではなく、キャラクター用のキャラクターベースで平等について話す方が良いことです。実際には、文字ごとの比較は、共通の文字エンコードへの変換後にコードポイントごとに作成する必要があります。
False negatives are caused by the production and use of URI aliases. Unnecessary aliases can be reduced, regardless of the comparison method, by consistently providing URI references in an already-normalized form (i.e., a form identical to what would be produced after normalization is applied, as described below).
偽のネガは、URIエイリアスの生産と使用によって引き起こされます。比較方法に関係なく、不必要なエイリアスは、既に通常の形式でURI参照を一貫して提供することで削減できます（つまり、以下に説明するように、正規化後に生成されるものと同一の形式）。
Protocols and data formats often limit some URI comparisons to simple string comparison, based on the theory that people and implementations will, in their own best interest, be consistent in providing URI references, or at least consistent enough to negate any efficiency that might be obtained from further normalization.
プロトコルとデータ形式は、多くの場合、URIの比較を単純な文字列比較と制限することがよくあります。これは、人々と実装が自分自身の最大の関心事で、URI参照を提供することに一貫しているか、少なくとも得られる効率を無効にするのに十分な一貫性があるという理論に基づいています。さらなる正規化から。
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 URIs equivalent:
実装は、この仕様で提供された定義に基づいてロジックを使用して、偽のネガの確率を低下させる場合があります。この処理は、キャラクターフォーキャラクターの文字列比較よりも中程度にコストが高くなっています。たとえば、このアプローチを使用するアプリケーションは、次の2つのURIに相当するものを合理的に考慮することができます。
example://a/b/c/%7Bfoo%7D eXAMPLE://a/./b/../b/%63/%7bfoo%7d
例：// a/b/c/％7bfoo％7d例：//a/./b/../b/%63/%7bfoo%7d
Web user agents, such as browsers, typically apply this type of URI normalization when determining whether a cached response is available. Syntax-based normalization includes such techniques as case normalization, percent-encoding normalization, and removal of dot-segments.
ブラウザなどのWebユーザーエージェントは、通常、キャッシュされた応答が利用可能かどうかを判断するときに、このタイプのURI正規化を適用します。構文ベースの正規化には、ケースの正規化、パーセントエンコード正規化、ドットセグメントの除去などの手法が含まれます。
For all URIs, 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.
すべてのURIの場合、パーセントエンコードトリプレット内の16進数（たとえば、 "％3a"対 "％3a"）は大文字と小文字を区別するため、数字a-fに大文字を使用するように正規化する必要があります。
When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and 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/>. The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme (see Section 6.2.3).
URIが一般的な構文のコンポーネントを使用する場合、コンポーネント構文の等価ルールが常に適用されます。すなわち、スキームとホストは症例に依存しないため、小文字に正規化する必要があります。たとえば、uri <http://www.example.com/>は<http://www.example.com/>に相当します。他の一般的な構文コンポーネントは、スキームによって特別に定義されていない限り、症例に敏感であると想定されています（セクション6.2.3を参照）。
The percent-encoding mechanism (Section 2.1) is a frequent source of variance among otherwise identical URIs. In addition to the case normalization issue noted above, some URI producers percent-encode octets that do not require percent-encoding, resulting in URIs that are equivalent to their non-encoded counterparts. These URIs should be normalized by decoding any percent-encoded octet that corresponds to an unreserved character, as described in Section 2.3.
パーセントエンコードメカニズム（セクション2.1）は、それ以外の場合は同一のURIの間で頻繁に分散源です。上記の場合の正規化の問題に加えて、一部のURIプロデューサーはパーセントエンコードを必要としないパーセントエンコードのオクテットであり、その結果、非エンコードされていない対応物と同等のURIが生じます。これらのURIは、セクション2.3で説明されているように、予約されていない文字に対応するパーセントエンコードのオクテットをデコードすることにより正規化する必要があります。
The complete path segments "." and ".." are intended only for use within relative references (Section 4.1) and are removed as part of the reference resolution process (Section 5.2). However, some deployed implementations incorrectly assume that reference resolution is not necessary when the reference is already a URI and thus fail to remove dot-segments when they occur in non-relative paths. URI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in Section 5.2.4.
完全なパスセグメント」。および「..」は、相対参照内でのみ使用することを目的としており（セクション4.1）、参照解決プロセスの一部として削除されます（セクション5.2）。ただし、一部の展開された実装では、参照がすでにURIである場合、参照解像度は必要ないため、非関連パスで発生した場合にドットセグメントを削除できないと誤って想定しています。URIノーマイザーは、セクション5.2.4で説明されているように、remove_dot_segmentsアルゴリズムをパスに適用して、ドットセグメントを削除する必要があります。
The syntax and semantics of URIs 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 URIs are equivalent:
URISの構文とセマンティクスは、各スキームの定義仕様で説明されているように、スキームごとに異なります。実装では、さらに処理コストでスキーム固有のルールを使用して、偽のネガの可能性を減らすことができます。たとえば、「HTTP」スキームは機関コンポーネントを使用し、デフォルトのポート「80」を持ち、空のパスを「/」に相当すると定義するため、次の4つのURIは同等です。
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
In general, a URI 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 URI above is the normal form for the "http" scheme.
一般に、空のパスを持つ権威に一般的な構文を使用するURIは、「/」のパスに正規化する必要があります。同様に、明示的な「：ポート」は、ポートが空になっているか、スキームのデフォルトであるため、ポートとその "："デリミッターが排除されるため、スキームベースの正規化によって削除される必要があります。たとえば、上記の2番目のURIは、「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 a URI 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」またはエンドユーザーのホストに相当すると考えられています。スキームが当局のデフォルトを定義し、そのデフォルトへのURI参照が望ましい場合、均一性、簡潔さ、国際化のために、参照は空の権限に正規化する必要があります。ただし、userInfoまたはポートサブコンポーネントのいずれかが空でない場合、デフォルトと一致する場合でも、ホストを明示的に指定する必要があります。
Normalization should not remove delimiters when their associated component is empty unless licensed to do so by the scheme specification. For example, the URI "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 URIs that differ only by the suffix "#" are considered different regardless of the scheme.
スキームの仕様によってライセンスを取得しない限り、関連するコンポーネントが空である場合、正規化はデリミターを削除しないでください。たとえば、uri "http://example.com/？"上記の例のいずれかと同等であると想定することはできません。同様に、userinfoサブコンポーネント内の区切り文字の有無は通常、その解釈にとって重要です。フラグメントコンポーネントは、スキームベースの正規化の対象ではありません。したがって、接尾辞「＃」によってのみ異なる2つのURIは、スキームに関係なく異なると見なされます。
Some schemes define additional subcomponents that consist of case-insensitive data, giving an implicit license to normalizers to convert this data to a common case (e.g., all lowercase). For example, URI schemes that define a subcomponent of path to contain an Internet hostname, such as the "mailto" URI scheme, cause that subcomponent to be case-insensitive and thus subject to case normalization (e.g., "mailto:Joe@Example.COM" is equivalent to "mailto:Joe@example.com", even though the generic syntax considers the path component to be case-sensitive).
一部のスキームは、ケースに依存しないデータで構成される追加のサブコンポーネントを定義し、このデータを一般的なケース（すべての小文字など）に変換するためにノーマイザーに暗黙のライセンスを提供します。たとえば、「Mailto」URIスキームなどのインターネットホスト名を含むパスのサブコンポーネントを定義するURIスキームは、そのサブコンポーネントがケース非感受性であり、したがってケースの正規化を受けます（例： "mailto：joe@example。com "は、汎用構文がパスコンポーネントをケースに敏感であると見なしているにもかかわらず、「mailto：joe@example.com」に相当します。
Other scheme-specific normalizations are possible.
他のスキーム固有の正常化が可能です。
Substantial effort to reduce the incidence of false negatives is often cost-effective for web spiders. Therefore, they implement even more aggressive techniques in URI comparison. For example, if they observe that a URI such as
偽陰性の発生率を減らすための実質的な努力は、多くの場合、Webスパイダーにとって費用対効果が高くなります。したがって、彼らはURI比較にさらに積極的な手法を実装します。たとえば、彼らが次のようなURIが
http://example.com/data
redirects to a URI differing only in the trailing slash
トレーリングスラッシュでのみ異なるURIにリダイレクト
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起源サーバーによるリダイレクトの使用）。
A URI does not in itself pose a security threat. However, as URIs are often used to provide a compact set of instructions for access to network resources, care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text.
URIはそれ自体がセキュリティの脅威をもたらさない。ただし、URIはネットワークリソースへのアクセスのためのコンパクトな一連の手順を提供するためによく使用されるため、URI内のデータを適切に解釈し、そのデータが意図しないアクセスを引き起こすのを防ぎ、そうでないデータを含めることを避けるために注意する必要があります。平易なテキストで明らかにされます。
There is no guarantee that once a URI has been used to retrieve information, the same information will be retrievable by that URI in the future. Nor is there any guarantee that the information retrievable via that URI in the future will be observably similar to that retrieved in the past. The URI syntax does not constrain how a given scheme or authority apportions its namespace or maintains it over time. Such guarantees can only be obtained from the person(s) controlling that namespace and the resource in question. A specific URI scheme may define additional semantics, such as name persistence, if those semantics are required of all naming authorities for that scheme.
URIが情報を取得するために使用されると、同じ情報が将来そのURIが取得できるという保証はありません。また、将来のURIを介して取得できる情報が過去に取得したものと観察的に類似しているという保証もありません。URI構文は、特定のスキームまたは権限が名前空間をどのように評価するか、または時間の経過とともに維持する方法を制約しません。このような保証は、その名前空間と問題のリソースを制御する人からのみ取得できます。特定のURIスキームは、そのスキームのすべての命名当局にそれらのセマンティクスが必要な場合、名前の永続性などの追加のセマンティクスを定義する場合があります。
It is sometimes possible to construct a URI so that an attempt to perform a seemingly harmless, idempotent operation, such as the retrieval of a representation, will in fact cause a possibly damaging remote operation. The unsafe URI is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site running a different protocol service, and data within the URI contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. A frequent example of such abuse has been the use of a protocol-based scheme with a port component of "25", thereby fooling user agent software into sending an unintended or impersonating message via an SMTP server.
URIを構築して、表現の検索など、一見無害で等身操作を実行しようとすることが、実際にはリモート操作の損傷を引き起こす可能性があります。安全でないURIは、通常、問題のネットワークプロトコルに予約されているポート番号以外のポート番号を指定することにより構築されます。クライアントは無意識のうちに異なるプロトコルサービスを実行しているサイトに連絡し、URI内のデータには、この他のプロトコルに従って解釈された場合、予期しない操作を引き起こす指示が含まれています。このような虐待の頻繁な例は、「25」のポートコンポーネントを備えたプロトコルベースのスキームの使用であり、それによりユーザーエージェントソフトウェアをだまして、SMTPサーバーを介して意図しないまたはなりすましのメッセージを送信します。
Applications should prevent dereference of a URI that specifies a TCP port number within the "well-known port" range (0 - 1023) unless the protocol being used to dereference that URI is compatible with the protocol expected on that well-known port. Although IANA maintains a registry of well-known ports, applications should make such restrictions user-configurable to avoid preventing the deployment of new services.
アプリケーションは、URIがその有名なポートで予想されるプロトコルと互換性があることを抑制するためにプロトコルが使用されない限り、「よく知られているポート」範囲内のTCPポート番号（0-1023）内のTCPポート番号を指定するURIの控除を防ぐ必要があります。IANAはよく知られているポートのレジストリを維持していますが、アプリケーションは、新しいサービスの展開を防ぐのを防ぐために、このような制限をユーザー構成可能にする必要があります。
When a URI contains percent-encoded octets that match the delimiters for a given resolution or dereference protocol (for example, CR and LF characters for the TELNET protocol), these percent-encodings must not be decoded before transmission across that protocol. Transfer of the percent-encoding, which might violate the protocol, is less harmful than allowing decoded octets to be interpreted as additional operations or parameters, perhaps triggering an unexpected and possibly harmful remote operation.
URIに、特定の解像度または繰り返しプロトコル（たとえば、TelnetプロトコルのCRおよびLF文字）の区切り文字と一致するパーセントエンコードオクテットを含む場合、これらのパーセントエンコーディングは、そのプロトコルを介して送信する前にデコードしてはなりません。プロトコルに違反する可能性のあるパーセントエンコードの転送は、デコードされたオクテットを追加の操作またはパラメーターとして解釈できるようにするよりも有害ではなく、おそらく予期しない有害なリモート操作をトリガーします。
When a URI is dereferenced, the data within it is often parsed by both the user agent and one or more servers. In HTTP, for example, a typical user agent will parse a URI into its five major components, access the authority's server, and send it the data within the authority, path, and query components. A typical server will take that information, parse the path into segments and the query into key/value pairs, and then invoke implementation-specific handlers to respond to the request. As a result, a common security concern for server implementations that handle a URI, either as a whole or split into separate components, is proper interpretation of the octet data represented by the characters and percent-encodings within that URI.
URIが再参入されると、その中のデータは、ユーザーエージェントと1つ以上のサーバーの両方によって解析されることがよくあります。たとえば、HTTPでは、典型的なユーザーエージェントがURIを5つの主要なコンポーネントに解析し、当局のサーバーにアクセスし、当局、パス、クエリコンポーネント内のデータを送信します。典型的なサーバーは、その情報を取得し、パスをセグメントとキー/値のペアにクエリに解析し、実装固有のハンドラーを呼び出してリクエストに応答します。その結果、URIを処理するサーバーの実装に関する一般的なセキュリティの懸念は、全体として、または個別のコンポーネントに分割され、そのURI内の文字とパーセントエンコーディングによって表されるオクテットデータの適切な解釈です。
Percent-encoded octets must be decoded at some point during the dereference process. Applications must split the URI into its components and subcomponents prior to decoding the octets, as otherwise the decoded octets might be mistaken for delimiters. Security checks of the data within a URI should be applied after decoding the octets. Note, however, that the "%00" percent-encoding (NUL) may require special handling and should be rejected if the application is not expecting to receive raw data within a component.
パーセントにエンコードされたオクテットは、控除プロセス中のある時点でデコードする必要があります。アプリケーションは、オクテットをデコードする前にURIをコンポーネントとサブコンポーネントに分割する必要があります。そうしないと、デコードされたオクテットが区切り文字と間違っている可能性があります。URI内のデータのセキュリティチェックは、オクテットをデコードした後に適用する必要があります。ただし、「％00」パーセントエンコード（NUL）には特別な取り扱いが必要になる場合があり、アプリケーションがコンポーネント内で生データを受け取ると予想していない場合は拒否されるべきであることに注意してください。
Special care should be taken when the URI path interpretation process involves the use of a back-end file system or related system functions. File systems typically assign an operational meaning to special characters, such as the "/", "\", ":", "[", and "]" characters, and to special device names like ".", "..", "...", "aux", "lpt", etc. In some cases, merely testing for the existence of such a name will cause the operating system to pause or invoke unrelated system calls, leading to significant security concerns regarding denial of service and unintended data transfer. It would be impossible for this specification to list all such significant characters and device names. Implementers should research the reserved names and characters for the types of storage device that may be attached to their applications and restrict the use of data obtained from URI components accordingly.
URIパス解釈プロセスにバックエンドファイルシステムまたは関連システム機能の使用が含まれる場合、特別な注意が必要です。ファイルシステムは、通常、「/」、「\」、「」： "、"、 "" "などの特殊文字に操作上の意味を割り当てます。、 "..."、 "aux"、 "lpt"など。場合によっては、そのような名前の存在をテストするだけで、オペレーティングシステムが無関係なシステム呼び出しを一時停止または呼び起こし、否定に関する重大なセキュリティ上の懸念につながりますサービスおよび意図しないデータ転送。この仕様がこのような重要な文字とデバイス名をすべてリストすることは不可能です。実装者は、アプリケーションに添付されている可能性のあるストレージデバイスの種類の予約済み名と文字を調査し、それに応じてURIコンポーネントから取得したデータの使用を制限する必要があります。
Although the URI syntax for IPv4address only allows the common dotted-decimal form of IPv4 address literal, many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address. Unfortunately, such system routines often allow and process a much larger set of formats than those described in Section 3.2.2.
IPv4AddressのURI構文は、IPv4アドレスの一般的な点線の形式のみを許可しますが、urisを処理する多くの実装は、gethostbyname（）やinet_aton（）などのプラットフォーム依存システムルーチンを処理し、文字列を文字列に変換します。実際のIPアドレス。残念ながら、このようなシステムルーチンは、セクション3.2.2で説明したものよりもはるかに大きな形式のセットを許可および処理することがよくあります。
For example, many implementations allow dotted forms of three numbers, wherein the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address (e.g., a Class B network). Likewise, a dotted form of two numbers means that the last part is interpreted as a 24-bit quantity and placed in the right-most three bytes of the network address (Class A), and a single number (without dots) is interpreted as a 32-bit quantity and stored directly in the network address. Adding further to the confusion, some implementations allow each dotted part to be interpreted as decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the number is interpreted as decimal).
たとえば、多くの実装では、3つの数値の点線が許可されています。最後の部分は16ビットの数量として解釈され、ネットワークアドレスの右バイト（クラスBネットワークなど）に配置されます。同様に、2つの数値の点線は、最後の部分が24ビットの数量として解釈され、ネットワークアドレスの右バイト（クラスA）に配置され、単一の数値（ドットなし）に配置されることを意味します。32ビットの数量とネットワークアドレスに直接保存されます。混乱をさらに追加すると、一部の実装により、各点線をC言語で指定して指定されているように、小数点、octal、または六十分子として解釈されることができます（つまり、先頭の0xまたは0xは16進数を意味します。小数点と解釈されます）。
These additional IP address formats are not allowed in the URI syntax due to differences between platform implementations. However, they can become a security concern if an application attempts to filter access to resources based on the IP address in string literal format. If this filtering is performed, literals should be converted to numeric form and filtered based on the numeric value, and not on a prefix or suffix of the string form.
これらの追加のIPアドレス形式は、プラットフォームの実装間の違いにより、URI構文では許可されていません。ただし、アプリケーションが文字列リテラル形式のIPアドレスに基づいてリソースへのアクセスをフィルタリングしようとする場合、セキュリティの懸念になる可能性があります。このフィルタリングが実行される場合、リテラルは数値形式に変換され、数値に基づいてフィルタリングされ、文字列形式の接頭辞または接尾辞ではありません。
URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies). A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public.
URIプロデューサーは、秘密になることを目的としたユーザー名またはパスワードを含むURIを提供すべきではありません。URIは、ブラウザによって頻繁に表示され、クリアテキストブックマークに保存され、ユーザーエージェントの履歴と中間アプリケーション（プロキシ）によって記録されます。userInfoコンポーネント内に表示されるパスワードは非推奨であり、「パスワード」パラメーターが公開されることを目的としているまれな場合を除き、エラーと見なされる（または単に無視される）必要があります。
Because the userinfo subcomponent is rarely used and appears before the host in the authority component, it can be used to construct a URI intended to mislead a human user by appearing to identify one (trusted) naming authority while actually identifying a different authority hidden behind the noise. For example
userInfoサブコンポーネントはめったに使用されず、当局コンポーネントのホストの前に表示されるため、実際に（信頼できる）命名権を特定することにより、人間のユーザーを誤解させることを目的としたURIを構築するために使用できます。ノイズ。例えば
ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm
might lead a human user to assume that the host is 'cnn.example.com', whereas it is actually '10.0.0.1'. Note that a misleading userinfo subcomponent could be much longer than the example above.
人間のユーザーがホストが「cnn.example.com」であると想定しているのに対し、実際には'10 .0.0.1 'であると導くかもしれません。誤解を招くuserInfoサブコンポーネントは、上記の例よりもはるかに長くなる可能性があることに注意してください。
A misleading URI, such as that above, is an attack on the user's preconceived notions about the meaning of a URI rather than an attack on the software itself. User agents may be able to reduce the impact of such attacks by distinguishing the various components of the URI when they are rendered, such as by using a different color or tone to render userinfo if any is present, though there is no panacea. More information on URI-based semantic attacks can be found in [Siedzik].
上記のような誤解を招くURIは、ソフトウェア自体への攻撃ではなく、URIの意味についてのユーザーの先入観に対する攻撃です。ユーザーエージェントは、異なる色やトーンを使用して存在する場合はuserinfoをレンダリングすることにより、パナセアがありません。URIベースのセマンティック攻撃の詳細については、[Siedzik]をご覧ください。
URI scheme names, as defined by <scheme> in Section 3.1, form a registered namespace that is managed by IANA according to the procedures defined in [BCP35]. No IANA actions are required by this document.
セクション3.1の<schleme>で定義されているURIスキーム名は、[BCP35]で定義されている手順に従ってIANAによって管理される登録名空間を形成します。このドキュメントではIANAアクションは必要ありません。
This specification is derived from RFC 2396 [RFC2396], RFC 1808 [RFC1808], and RFC 1738 [RFC1738]; the acknowledgements in those documents still apply. It also incorporates the update (with corrections) for IPv6 literals in the host syntax, as defined by Robert M. Hinden, Brian E. Carpenter, and Larry Masinter in [RFC2732]. In addition, contributions by Gisle Aas, Reese Anschultz, Daniel Barclay, Tim Bray, Mike Brown, Rob Cameron, Jeremy Carroll, Dan Connolly, Adam M. Costello, John Cowan, Jason Diamond, Martin Duerst, Stefan Eissing, Clive D.W. Feather, Al Gilman, Tony Hammond, Elliotte Harold, Pat Hayes, Henry Holtzman, Ian B. Jacobs, Michael Kay, John C. Klensin, Graham Klyne, Dan Kohn, Bruce Lilly, Andrew Main, Dave McAlpin, Ira McDonald, Michael Mealling, Ray Merkert, Stephen Pollei, Julian Reschke, Tomas Rokicki, Miles Sabin, Kai Schaetzl, Mark Thomson, Ronald Tschalaer, Norm Walsh, Marc Warne, Stuart Williams, and Henry Zongaro are gratefully acknowledged.
この仕様は、RFC 2396 [RFC2396]、RFC 1808 [RFC1808]、およびRFC 1738 [RFC1738]から派生しています。これらのドキュメントの謝辞は引き続き適用されます。また、ロバートM.ヒンデン、ブライアンE.カーペンター、および[RFC2732]のラリーマシンスターによって定義されているように、ホスト構文のIPv6リテラルの更新（修正付き）が組み込まれています。さらに、Gisle AAS、Reese Anschultz、Daniel Barclay、Tim Bray、Mike Brown、Rob Cameron、Jeremy Carroll、Dan Connollyによる貢献フェザー、アル・ギルマン、トニー・ハモンド、エリオット・ハロルド、パット・ヘイズ、ヘンリー・ホルツマン、イアン・B・ジェイコブス、マイケル・ケイ、ジョン・C・クレンシン、グラハム・クリーン、ダン・コーン、ブルース・リリー、アンドリュー・メイン、デイブ・マクルピン、イラ・マクドナルド、マイケル・ミールリング、レイ・メルカート、スティーブン・ポリイ、ジュリアン・レシュケ、トマス・ロキッキ、マイルズ・サビン、カイ・シェッツル、マーク・トムソン、ロナルド・ツェラエル、ノルム・ウォルシュ、マーク・ワーン、スチュアート・ウィリアムズ、ヘンリー・ゾンガロは感謝されている。
[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。
[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月。
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[Std63] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[UCS] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO/IEC 10646:2003, December 2003.
[UCS]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS）」、ISO/IEC 10646：2003、2003年12月。
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[BCP19] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[BCP35] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[BCP35] Petke、R。およびI. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DODインターネットホストテーブル仕様」、RFC 952、1985年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535] Gavron、E。、「セキュリティ問題と広く展開されたDNSソフトウェアによる修正の提案」、RFC 1535、1993年10月。
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, June 1994.
[RFC1630] Berners-Lee、T。、「wwwのユニバーサルリソース識別子：世界的なWebで使用されているネットワーク上のオブジェクトの名前とアドレスの表現の統一構文」、RFC 1630、1994年6月。
[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.
[RFC1736] Kunze、J。、「インターネットリソースロケーターの機能的推奨」、RFC 1736、1995年2月。
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[RFC1737] Sollins、K。およびL. Masinter、「統一リソース名の機能要件」、RFC 1737、1994年12月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]フィールディング、R。、「相対均一な資源ロケーター」、RFC 1808、1995年6月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。
[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月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[RFC2557] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集計文書のMIMEカプセル化」、RFC 2557、1999年3月。
[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月。
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2732] Hinden、R.、Carpenter、B。、およびL. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.
[RFC3305] Mealling、M。and R. Denenberg、「共同W3C/IETF URI計画関心グループからのレポート：ユニフォームリソース識別子（URI）、URL、およびユニフォームリソース名（URNS）：明確化と推奨事項」、RFC 3305、2002年8月。
[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月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[Siedzik] Siedzik, R., "Semantic Attacks: What's in a URL?", April 2001, <http://www.giac.org/practical/gsec/ Richard_Siedzik_GSEC.pdf>.
[Siedzik] Siedzik、R。、「セマンティック攻撃：URLには何がありますか？」、2001年4月、<http://www.giac.org/practical/gsec/ richard_siedzik_gsec.pdf>。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
Absolute-uri = scheme "：" Hier-Part ["？"クエリ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-ref = relative-part ["？"クエリ] ["＃"フラグメント]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
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
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
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
pct-encoded = "％" hexdig hexdig
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
As the "first-match-wins" algorithm is identical to the "greedy" disambiguation method used by POSIX regular expressions, it is natural and commonplace to use a regular expression for parsing the potential five components of a URI reference.
「最初の試合」アルゴリズムは、POSIXの正規表現で使用される「貪欲な」非曖昧性使用方法と同一であるため、URI参照の潜在的な5つのコンポーネントを解析するために正規表現を使用することは自然でありふれたものです。
The following line is the regular expression for breaking-down a well-formed URI reference into its components.
次の行は、そのコンポーネントによく形成されたURI参照を破壊するための正規表現です。
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12 3 4 5 6 7 8 9
The numbers in the second line above are only to assist readability; they indicate the reference points for each subexpression (i.e., each paired parenthesis). We refer to the value matched for subexpression <n> as $<n>. For example, matching the above expression to
上記の2行目の数字は、読みやすさを支援するためだけです。それらは、各サブエクスペッションの基準点を示します（つまり、各ペアの括弧）。サブエクスペッション<n>の一致した値を$ <n>と呼びます。たとえば、上記の式をに一致させます
http://www.ics.uci.edu/pub/ietf/uri/#Related
results in the following subexpression matches:
次のサブエクスポンションの一致で結果が得られます。
$1 = http:
$2 = http
$3 = //www.ics.uci.edu
$4 = www.ics.uci.edu
$5 = /pub/ietf/uri/
$6 = <undefined>
$7 = <undefined>
$8 = #Related
$9 = Related
where <undefined> indicates that the component is not present, as is the case for the query component in the above example. Therefore, we can determine the value of the five components as
上記の例のクエリコンポーネントの場合のように、<未定義>はコンポーネントが存在しないことを示します。したがって、5つのコンポーネントの値を次のように決定できます
scheme = $2 authority = $4 path = $5 query = $7 fragment = $9
スキーム= $ 2機関= 4ドルのパス= 5ドルクエリ= $ 7フラグメント= $ 9
Going in the opposite direction, we can recreate a URI reference from its components by using the algorithm of Section 5.3.
反対の方向に進むと、セクション5.3のアルゴリズムを使用して、コンポーネントからURI参照を再現できます。
URIs are often transmitted through formats that do not provide a clear context for their interpretation. For example, there are many occasions when a URI is included in plain text; examples include text sent in email, USENET news, and on printed paper. In such cases, it is important to be able to delimit the URI from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URI.
URIは、多くの場合、解釈の明確なコンテキストを提供しない形式を介して送信されます。たとえば、URIがプレーンテキストに含まれる場合が多くあります。例には、電子メール、usenetニュース、印刷用紙に送信されたテキストが含まれます。そのような場合、テキストの残りの部分、特にURIの一部と間違えられる可能性のある句読点からURIを区切ることができることが重要です。
In practice, URIs are delimited in a variety of ways, but usually within double-quotes "http://example.com/", angle brackets <http://example.com/>, or just by using whitespace:
実際には、URIはさまざまな方法で区切られていますが、通常は「http://example.com/」、角度ブラケット<http://example.com/>、またはWhitespaceを使用して、ダブルクォート内にあります。
http://example.com/
These wrappers do not form part of the URI.
これらのラッパーはURIの一部を形成しません。
In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted.
場合によっては、余分な空白（スペース、ラインブレイク、タブなど）を追加する必要がある場合があります。URIが抽出されたときに、Whitespaceを無視する必要があります。
No whitespace should be introduced after a hyphen ("-") character. Because some typesetters and printers may (erroneously) introduce a hyphen at the end of line when breaking it, the interpreter of a URI containing a line break immediately after a hyphen should ignore all whitespace around the line break and should be aware that the hyphen may or may not actually be part of the URI.
ハイフン（ " - "）文字の後に導入する必要はありません。一部のタイプセッターとプリンターは、それを壊すときにラインの端にハイフンを（誤って）導入する可能性があるため、ハイフンの直後にラインブレークを含むURIの通訳は、ラインブレーク周辺のすべての白人を無視する必要があり、ハイフンができることに注意する必要があります。または、実際にはURIの一部ではないかもしれません。
Using <> angle brackets around each URI is especially recommended as a delimiting style for a reference that contains embedded whitespace.
各URIの周りに<>角度ブラケットを使用することは、埋め込まれた空白を含むリファレンスの描写スタイルとして特に推奨されます。
The prefix "URL:" (with or without a trailing space) was formerly recommended as a way to help distinguish a URI from other bracketed designators, though it is not commonly used in practice and is no longer recommended.
接頭辞「URL：」（トレーリングスペースの有無にかかわらず）は、URIを他のブラケット指定者と区別するのに役立つ方法として以前推奨されていましたが、実際には一般的に使用されておらず、推奨されなくなりました。
For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace.
堅牢性のために、ユーザー型のURIを受け入れるソフトウェアは、デリミターと組み込みの両方のホワイトスペースを認識して剥ぎ取ろうとする必要があります。
For example, the text
たとえば、テキスト
Yes, Jim, I found it under "http://www.w3.org/Addressing/", but you can probably pick it up from <ftp://foo.example. com/rfc/>. Note the warning in <http://www.ics.uci.edu/pub/ ietf/uri/historical.html#WARNING>.
はい、ジム、「http://www.w3.org/addressing/」で見つけましたが、おそらく<ftp：//foo.exampleから拾うことができます。com/rfc/>。<http://www.ics.uci.edu/pub/ ietf/uri/Historal.html＃警告>の警告に注意してください。
contains the URI references
URI参照が含まれています
http://www.w3.org/Addressing/ ftp://foo.example.com/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING
http://www.w3.org/addressing/ ftp://foo.example.com/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#warning
An ABNF rule for URI has been introduced to correspond to one common usage of the term: an absolute URI with optional fragment.
URIのABNFルールは、この用語の1つの一般的な使用法に対応するために導入されています。オプションのフラグメントを持つ絶対URIです。
IPv6 (and later) literals have been added to the list of possible identifiers for the host portion of an authority component, as described by [RFC2732], with the addition of "[" and "]" to the reserved set and a version flag to anticipate future versions of IP literals. Square brackets are now specified as reserved within the authority component and are not allowed outside their use as delimiters for an IP literal within host. In order to make this change without changing the technical definition of the path, query, and fragment components, those rules were redefined to directly specify the characters allowed.
IPv6（および後の）リテラルは、[RFC2732]で説明されているように、当局コンポーネントのホスト部分の可能な識別子のリストに追加され、予約セットとバージョンフラグに「["と"]が追加されています。IPリテラルの将来のバージョンを予測する。正方形の括弧は、当局コンポーネント内に予約されていると指定されており、ホスト内のIPリテラルのデリミターとして使用することは許可されていません。パス、クエリ、およびフラグメントコンポーネントの技術的な定義を変更せずにこの変更を行うために、これらのルールを再定義して、許可された文字を直接指定しました。
As [RFC2732] defers to [RFC3513] for definition of an IPv6 literal address, which, unfortunately, lacks an ABNF description of IPv6address, we created a new ABNF rule for IPv6address that matches the text representations defined by Section 2.2 of [RFC3513]. Likewise, the definition of IPv4address has been improved in order to limit each decimal octet to the range 0-255.
[RFC2732]が[RFC2732]を[RFC3513]に扱い、IPV6AddressのABNF説明がないIPv6リテラルアドレスの定義のために、[RFC3513]のセクション2.2で定義されたテキスト表現に一致する新しいABNFルールを作成しました。同様に、IPv4Addressの定義は、各小桁のオクテットを0〜255の範囲に制限するために改善されました。
Section 6, on URI normalization and comparison, has been completely rewritten and extended by using input from Tim Bray and discussion within the W3C Technical Architecture Group.
URIの正規化と比較に関するセクション6は、W3Cテクニカルアーキテクチャグループ内のティムブレイからの入力と議論を使用することにより、完全に書き直され、拡張されました。
The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of [RFC2234]. This change required all rule names that formerly included underscore characters to be renamed with a dash instead. In addition, a number of syntax rules have been eliminated or simplified to make the overall grammar more comprehensible. Specifications that refer to the obsolete grammar rules may be understood by replacing those rules according to the following table:
RFC 2396のアドホックBNF構文は、[RFC2234]のABNFに置き換えられました。この変更には、以前はアンダースコア文字を含めていたすべてのルール名が代わりにダッシュで変更される必要がありました。さらに、全体的な文法をより理解しやすくするために、多くの構文ルールが排除または簡素化されています。時代遅れの文法規則を参照する仕様は、次の表に従ってこれらのルールを置き換えることで理解できます。
+----------------+--------------------------------------------------+
| obsolete rule | translation |
+----------------+--------------------------------------------------+
| absoluteURI | absolute-URI |
| relativeURI | relative-part [ "?" query ] |
| hier_part | ( "//" authority path-abempty / |
| | path-absolute ) [ "?" query ] |
| | |
| opaque_part | path-rootless [ "?" query ] |
| net_path | "//" authority path-abempty |
| abs_path | path-absolute |
| rel_path | path-rootless |
| rel_segment | segment-nz-nc |
| reg_name | reg-name |
| server | authority |
| hostport | host [ ":" port ] |
| hostname | reg-name |
| path_segments | path-abempty |
| param | *<pchar excluding ";"> |
| | |
| uric | unreserved / pct-encoded / ";" / "?" / ":" |
| | / "@" / "&" / "=" / "+" / "$" / "," / "/" |
| | |
| uric_no_slash | unreserved / pct-encoded / ";" / "?" / ":" |
| | / "@" / "&" / "=" / "+" / "$" / "," |
| | |
| mark | "-" / "_" / "." / "!" / "~" / "*" / "'" |
| | / "(" / ")" |
| | |
| escaped | pct-encoded |
| hex | HEXDIG |
| alphanum | ALPHA / DIGIT |
+----------------+--------------------------------------------------+
Use of the above obsolete rules for the definition of scheme-specific syntax is deprecated.
スキーム固有の構文の定義のための上記の時代遅れのルールの使用は非推奨です。
Section 2, on characters, has been rewritten to explain what characters are reserved, when they are reserved, and why they are reserved, even when they are not used as delimiters by the generic syntax. The mark characters that are typically unsafe to decode, including the exclamation mark ("!"), asterisk ("*"), single-quote ("'"), and open and close parentheses ("(" and ")"), have been moved to the reserved set in order to clarify the distinction between reserved and unreserved and, hopefully, to answer the most common question of scheme designers. Likewise, the section on percent-encoded characters has been rewritten, and URI normalizers are now given license to decode any percent-encoded octets corresponding to unreserved characters. In general, the terms "escaped" and "unescaped" have been replaced with "percent-encoded" and "decoded", respectively, to reduce confusion with other forms of escape mechanisms.
キャラクターのセクション2は、一般的な構文によって区切り文字として使用されていない場合でも、どの文字が予約されているか、予約されている時期、そしてなぜ予約されているのかを説明するために書き直されました。感嘆符（ "！"）、アスタリスク（ "*"）、single-quote（ "'"）、および閉じた括弧（ "（" and "）"を含む、通常、デコードに安全でないマーク文字、予約されたものと非予約されていない区別を明確にするために、予約されたセットに移され、できればスキームデザイナーの最も一般的な質問に答えることができます。同様に、パーセントエンコードされた文字のセクションが書き直されており、URIノーマイザーには、予約されていない文字に対応するパーセントエンコードのオクテットをデコードするライセンスが与えられました。一般に、「脱出」と「覆い隠されていない」という用語は、他の形態の脱出メカニズムとの混乱を減らすために、それぞれ「パーセントエンコード」と「デコードされた」に置き換えられています。
The ABNF for URI and URI-reference has been redesigned to make them more friendly to LALR parsers and to reduce complexity. As a result, the layout form of syntax description has been removed, along with the uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, and mark rules. All references to "opaque" URIs have been replaced with a better description of how the path component may be opaque to hierarchy. The relativeURI rule has been replaced with relative-ref to avoid unnecessary confusion over whether they are a subset of URI. The ambiguity regarding the parsing of URI-reference as a URI or a relative-ref with a colon in the first segment has been eliminated through the use of five separate path matching rules.
URIとURIの参照のABNFは、LALRパーサーに対してより友好的になり、複雑さを軽減するために再設計されています。その結果、URIC、uric_no_slash、opaque_part、net_path、abs_path、rel_path、path_segments、rel_segment、およびmarkルールとともに、構文の説明形式が削除されました。「不透明」ウリスへのすべての言及は、パスコンポーネントが階層に不透明である可能性のある方法のより良い説明に置き換えられています。相対的なルールは、それらがURIのサブセットであるかどうかについて不必要な混乱を避けるために、相対REFに置き換えられました。最初のセグメントにコロンを持つURIまたは相対REFとしてのURI参照の解析に関する曖昧さは、5つの別々のパスマッチングルールを使用することにより排除されました。
The fragment identifier has been moved back into the section on generic syntax components and within the URI and relative-ref rules, though it remains excluded from absolute-URI. The number sign ("#") character has been moved back to the reserved set as a result of reintegrating the fragment syntax.
フラグメント識別子は、汎用構文コンポーネントのセクションおよびURIおよび相対REFルール内のセクションに移動されましたが、絶対URIから除外されたままです。Number Sign（ "＃"）文字は、フラグメント構文の再統合の結果として、予約セットに戻されました。
The ABNF has been corrected to allow the path component to be empty. This also allows an absolute-URI to consist of nothing after the "scheme:", as is present in practice with the "dav:" namespace [RFC2518] and with the "about:" scheme used internally by many WWW browser implementations. The ambiguity regarding the boundary between authority and path has been eliminated through the use of five separate path matching rules.
ABNFは、パスコンポーネントを空にするために修正されました。また、これにより、「dav： "namespace [rfc2518]と「about：about」スキームが多くのWWWブラウザーの実装で使用される「dav：" "namespace [rfc2518]が実際に存在するように、「スキーム：」の後に絶対的な尿が何もないことが可能になります。権威とパスの境界に関するあいまいさは、5つの別々のパスマッチングルールを使用することにより排除されました。
Registry-based naming authorities that use the generic syntax are now defined within the host rule. This change allows current implementations, where whatever name provided is simply fed to the local name resolution mechanism, to be consistent with the specification. It also removes the need to re-specify DNS name formats here. Furthermore, it allows the host component to contain percent-encoded octets, which is necessary to enable internationalized domain names to be provided in URIs, processed in their native character encodings at the application layers above URI processing, and passed to an IDNA library as a registered name in the UTF-8 character encoding. The server, hostport, hostname, domainlabel, toplabel, and alphanum rules have been removed.
一般的な構文を使用するレジストリベースの命名当局は、ホストルール内で定義されます。この変更により、現在の実装が可能になります。ここでは、提供された名前が単にローカル名解像度メカニズムに単純に供給され、仕様と一致します。また、ここでDNS名形式を再指定する必要性も削除されます。さらに、ホストコンポーネントは、URIで国際化されたドメイン名を提供し、URI処理を超えるアプリケーションレイヤーでネイティブキャラクターエンコーディングで処理され、IDNAライブラリに渡されるために必要なパーセントエンコードオクテットを含めることができます。UTF-8文字エンコードの登録名。サーバー、ホストポート、ホスト名、ドメインラベル、トップラベル、およびアルファナムルールが削除されました。
The resolving relative references algorithm of [RFC2396] has been rewritten with pseudocode for this revision to improve clarity and fix the following issues: o [RFC2396] section 5.2, step 6a, failed to account for a base URI with no path.
[RFC2396]の解決相対参照アルゴリズムは、明確さを改善し、次の問題を修正するために、この改訂のために擬似コードで書き換えられました。O[RFC2396]セクション5.2、ステップ6Aは、パスのないベースURIを説明できませんでした。
o Restored the behavior of [RFC1808] where, if the reference contains an empty path and a defined query component, the target URI inherits the base URI's path component.
o [RFC1808]の動作を復元しました。ここで、参照に空のパスと定義されたクエリコンポーネントが含まれている場合、ターゲットURIはベースURIのパスコンポーネントを継承します。
o The determination of whether a URI reference is a same-document reference has been decoupled from the URI parser, simplifying the URI processing interface within applications in a way consistent with the internal architecture of deployed URI processing implementations. The determination is now based on comparison to the base URI after transforming a reference to absolute form, rather than on the format of the reference itself. This change may result in more references being considered "same-document" under this specification than there would be under the rules given in RFC 2396, especially when normalization is used to reduce aliases. However, it does not change the status of existing same-document references.
o URI参照が同じドキュメント参照であるかどうかの決定は、URIパーサーから分離されており、展開されたURI処理実装の内部アーキテクチャと一致する方法で、アプリケーション内のURI処理インターフェイスを簡素化します。この決定は、参照自体の形式ではなく、基準を絶対フォームに変換した後のベースURIとの比較に基づいています。この変更により、特にエイリアスを削減するために正規化が使用される場合、RFC 2396で与えられたルールの下であるよりも、この仕様の下で「同じ文書」と見なされる参照が増える可能性があります。ただし、既存の同じドキュメント参照のステータスは変更されません。
o Separated the path merge routine into two routines: merge, for describing combination of the base URI path with a relative-path reference, and remove_dot_segments, for describing how to remove the special "." and ".." segments from a composed path. The remove_dot_segments algorithm is now applied to all URI reference paths in order to match common implementations and to improve the normalization of URIs in practice. This change only impacts the parsing of abnormal references and same-scheme references wherein the base URI has a non-hierarchical path.
o パスを分離したルーチンを2つのルーチンにマージします。マージ、ベースURIパスと相対パス参照の組み合わせとremove_dot_segments、特別なものを削除する方法を説明するために。」および「..」構成されたパスからのセグメント。remove_dot_segmentsアルゴリズムは、一般的な実装を一致させ、実際にURIの正規化を改善するために、すべてのURI参照パスに適用されるようになりました。この変化は、異常な参照とベースのURIに非階層パスを持つ同じ=シーム参照の解析にのみ影響します。
Index
索引
A ABNF 11 absolute 27 absolute-path 26 absolute-URI 27 access 9 authority 17, 18
A abnf 11 Absolute 27 Absolute-Path 26 Absolute-uri 27 Access 9 Authority 17、18
B base URI 28
BベースURI 28
C character encoding 4 character 4 characters 8, 11 coded character set 4
C 4文字4文字をエンコードするC文字8、11コード化された文字セット4
D dec-octet 20 dereference 9 dot-segments 23
D Dec-OCTET 20控除9ドットセグメント23
F fragment 16, 24
Fフラグメント16、24
G gen-delims 13 generic syntax 6
G gen-delims 13ジェネリック構文6
H h16 20 hier-part 16 hierarchical 10 host 18
H H16 20 Hier-Part 16 Hierarchical 10ホスト18
I identifier 5 IP-literal 19 IPv4 20 IPv4address 19, 20 IPv6 19 IPv6address 19, 20 IPvFuture 19
I IDIFIER 5 IP-RITERAL 19 IPv4 20 IPv4Address 19、20 IPv6 19 IPv6Address 19、20 IPVFuture 19
L locator 7 ls32 20
Lロケーター7 LS32 20
M merge 32
mマージ32
N name 7 network-path 26
n名前7ネットワークパス26
P path 16, 22, 26 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 path-abempty 16, 22, 26 path-absolute 16, 22, 26 path-empty 16, 22, 26 path-rootless 16, 22 pchar 23 pct-encoded 12 percent-encoding 12 port 22
Pパス16、22、26パスアビーム22 22パスアブソルテ22パスエンプ空22 22パスノスケメ22パスルートレス22パスアビーム16、22、26パスアブソルテ16、22、26パスエンプティ16、22、26 Path-Rootless 16、22 PCHAR 23 PCTエンコード12パーセントエンコード12ポート22
Q query 16, 23
Qクエリ16、23
R reg-name 21 registered name 20 relative 10, 28 relative-path 26 relative-ref 26 remove_dot_segments 33 representation 9 reserved 12 resolution 9, 28 resource 5 retrieval 9
r reg-name 21登録名20相対10、28相対パス26相対ref 26 remove_dot_segments 33表現9予約12解像度9、28リソース5検索9
S same-document 27 sameness 9 scheme 16, 17 segment 22, 23 segment-nz 23 segment-nz-nc 23 sub-delims 13 suffix 27
s同じドキュメント27同一性9スキーム16、17セグメント22、23セグメント-NZ 23セグメント-NZ-NC 23サブデリム13サフィックス27
T transcription 8
T転写8
U uniform 4 unreserved 13 URI grammar absolute-URI 27 ALPHA 11 authority 18 CR 11 dec-octet 20 DIGIT 11 DQUOTE 11 fragment 24 gen-delims 13 h16 20 HEXDIG 11 hier-part 16 host 19 IP-literal 19 IPv4address 20 IPv6address 20 IPvFuture 19 LF 11 ls32 20 OCTET 11 path 22 path-abempty 22 path-absolute 22 path-empty 22 path-noscheme 22 path-rootless 22 pchar 23 pct-encoded 12 port 22 query 24 reg-name 21 relative-ref 26 reserved 13 scheme 17 segment 23 segment-nz 23 segment-nz-nc 23 SP 11 sub-delims 13 unreserved 13 URI 16 URI-reference 25 userinfo 18 URI 16 URI-reference 25 URL 7 URN 7 userinfo 18
Uユニフォーム4未返信13 URI文法27アルファ11 Authority 18 Cr 11 Dec-Octet 20 Digit 11 Dquote 11 Fragment 24 Gen-Delims 13 H16 20 Hexdig 11 Hier-Part 16 Host 19 IP-LITRAL 19 IPV4ADDRESS 20 IPV6ADDRESS 20 IPVFUTURE19 LF 11 LS32 20オクテット11パス22パスアビーム22パスアブソルート22パスエンプテン22パスノスケメ22パスルートレス22 PCHAR 23 PCT-ENCODED 12ポート22クエリ24 REGNAME 21 RECATION-REF 26予約13スキーム17セグメント23セグメント-NZ 23セグメント-NZ-NC 23 SP 11サブデリム13 UNRESSERVET 13 URI 16 URI-REFERENCE 25 USERINFO 18 URI 16 URI-REFERENCE 25 URL 7 URN 7 USERINFO 18
Authors' Addresses
著者のアドレス
Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA
ティムバーナーズリーワールドワイドウェブコンソーシアムマサチューセッツ工科大学77マサチューセッツアベニューケンブリッジ、マサチューセッツ州02139 USA
Phone: +1-617-253-5702
Fax: +1-617-258-5999
EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/
Roy T. Fielding Day Software 5251 California Ave., Suite 110 Irvine, CA 92617 USA
Roy T. Fielding Day Software 5251 California Ave.、Suite 110 Irvine、CA 92617 USA
Phone: +1-949-679-2960
Fax: +1-949-679-2972
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 USA
Phone: +1-408-536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net/
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エディター機能の資金は現在、インターネット協会によって提供されています。