[要約] 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構文とセマンティクスのこの仕様は、World Wide Webグローバル情報イニシアティブによって導入された概念に由来しています。これらの識別子の使用は1990年に始まり、「Universal Resource Identifiers in WWW」[RFC1630]に記述されています。構文は、「Functional Recommendations for Internet Resource Locators」[RFC1736]および「Functional Requirements for Uniform Resource Names」[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の単一の一般的な構文を定義するために、「Uniform Resource Locators」[RFC1738]と「Relative Uniform Resource Locators」[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」と呼ぶものの代わりに「文字符号化（character encoding）」を使用します。
URIs are characterized as follows:
URIは次のように特徴付けられます：
Uniform
統一（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).
識別子は、識別されるものを、その識別の範囲内の他のすべてのものと区別するために必要な情報を具体化します。「識別（identify）」および「識別すること（identifying）」という用語の使用は、その目的がどのように達成されるか（例：名前、住所、またはコンテキストによる）に関係なく、あるリソースを他のすべてのリソースと区別するという目的を指します。これらの用語は、識別子が参照対象のアイデンティティを定義または具体化するという仮定と誤解されるべきではありませんが、一部の識別子の場合はそうです。また、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/」は、その参照を使用するすべてのユーザーに対して同じ解釈を持ちますが、「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に許可される構文の範囲の定義として、この仕様を参照できます。これにより、識別スキームの進化を、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
news: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は、ロケーター、名前、またはその両方としてさらに分類できます。「Uniform Resource Locator」（URL）という用語は、リソースを識別することに加えて、主要なアクセスメカニズム（例：ネットワーク上の「場所」）を記述することでリソースを見つける手段を提供するURIのサブセットを指します。「Uniform Resource Name」（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].
個々のスキームは、「名前」または「ロケーター」のいずれか一方だけに分類される必要はありません。特定のスキームからの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コンポーネントにとって最も意味のある名前に、一部のシステムでは入力できない文字が必要になることがよくあります。リソース識別子をある媒体から別の媒体に転記できる機能は、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が参照されるプロトコル要素によって許可されている場合、US-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の「解決（resolution）」とは、アクセスメカニズムと、URIを逆参照（dereference）するために必要な適切なパラメーターを決定するプロセスです。この解決には、数回の反復が必要になる場合があります。そのアクセスメカニズムを使用してURIのリソースに対してアクションを実行することを、URIを「逆参照（dereference）」すると言います。
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逆参照の最も一般的な形式は「取得（retrieval）」です。つまり、関連するリソースの表現を取得するために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参照は、遅延結合（late-binding）になるように設計されています。アクセスの結果は、一般にアクセス時に決定され、時間の経過や相互作用の他の側面によって変化する可能性があります。これらの参照は、将来使用するために作成されます。識別されているのは、過去に得られた特定の結果ではなく、将来の結果に当てはまると予想されるいくつかの特性です。そのような場合、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がリソースの表現を取得するために使用された場合でも、そのアクセスは、スキーム名に関連するプロトコルに依存しないゲートウェイ、プロキシ、キャッシュ、および名前解決サービスを介して行われる可能性があります。一部のURIの解決では、複数のプロトコルの使用が必要になる場合があります（たとえば、ローカルキャッシュで表現が見つからない場合に「http」URIのオリジンサーバーにアクセスするために、DNSとHTTPの両方が通常使用されます）。
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.
汎用構文は、スラッシュ（ "/"）、疑問符（ "?"）、および番号記号（ "#"）文字を使用して、識別子の汎用パーサーによる階層的解釈に重要なコンポーネントを区切ります。おなじみの構文の一貫した使用を通じてそのような識別子の可読性を支援することに加えて、命名スキーム全体での階層のこの統一された表現により、その階層に対する相対的なスキームに依存しない参照を作成できます。
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参照の大部分は、ツリーの外側ではなく内側のリソースを指しています。同様に、特定のサイトにあるドキュメントは、リモートサイトのリソースよりも、そのサイトの他のリソースを参照する可能性がはるかに高くなります。URIの相対参照により、ドキュメントツリーはその場所とアクセススキームから部分的に独立することができます。たとえば、ドキュメントが相対参照で互いを参照している場合、単一のハイパーテキストドキュメントセットが、「file」、「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を参照する方法ではなくURIのサブセットであることを意味すると誤解したため、この仕様では単にそれらを相対参照と呼んでいます。
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スキーム仕様は、スラッシュ文字、疑問符文字、およびURI「scheme:.」と「scheme:..」の使用を許可しないことにより、不透明な識別子を定義できます。
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.
この仕様では、[RFC2234]の拡張バッカス・ナウア記法（ABNF）表記を使用します。これには、その仕様で定義された次のコアABNF構文ルールが含まれます：ALPHA（文字）、CR（復帰）、DIGIT（10進数字）、DQUOTE（二重引用符）、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進数字「A」から「F」は、それぞれ小文字の数字「a」から「f」に相当します。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には、「予約（reserved）」セットの文字によって区切られたコンポーネントとサブコンポーネントが含まれます。これらの文字は、汎用構文、各スキーム固有の構文、または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の解釈方法を変更します。したがって、予約セットの文字は正規化から保護されており、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構文ルールは、reservedまたは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で許可されているが、予約された目的を持っていない文字は、非予約（unreserved）文字と呼ばれます。これらには、大文字と小文字、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は、同等です。つまり、それらは同じリソースを識別します。ただし、URIの比較実装は、比較前に常に正規化を実行するとは限りません（セクション6を参照）。一貫性のために、ALPHA（%41-%5Aおよび%61-%7A）、DIGIT（%30-%39）、ハイフン（%2D）、ピリオド（%2E）、アンダースコア（%5F）、またはチルダ（%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が逆参照される場合、スキーム固有の逆参照プロセス（ある場合）に重要なコンポーネントとサブコンポーネントは、それらのコンポーネント内のパーセントエンコードされたオクテットを安全にデコードする前に解析および分離されなければなりません。そうしないと、データがコンポーネントの区切り文字と間違えられる可能性があります。唯一の例外は、非予約セットの文字に対応するパーセントエンコードされたオクテットの場合です。これらはいつでもデコードできます。たとえば、チルダ（ "~"）文字に対応するオクテットは、古い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生成アプリケーション（例：オリジンサーバー）は、通常、意味のある名前を作成するための基礎としてローカルエンコーディングを使用します。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」がオクテット "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」をSPに）。
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」として表され、文字LATIN CAPITAL LETTER A WITH GRAVEは「%C3%80」として表され、文字KATAKANA LETTER 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構文は、スキーム、オーソリティ（authority）、パス、クエリ、およびフラグメントと呼ばれるコンポーネントの階層シーケンスで構成されています。
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:
以下は、2つのURIの例とその構成要素です。
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.
オーソリティコンポーネントの前にはダブルスラッシュ（ "//"）があり、次のスラッシュ（ "/"）、疑問符（ "?"）、または番号記号（ "#"）文字、あるいは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サブコンポーネントは、ユーザー名と、オプションで、リソースにアクセスするための許可を取得する方法に関するスキーム固有の情報で構成されている場合があります。ユーザー情報は、存在する場合、ホストからそれを区切るアットマーク（ "@"）が続きます。
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フィールドでの「user:password」形式の使用は非推奨です。アプリケーションは、コロンの後のデータが空の文字列（パスワードがないことを示す）でない限り、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リテラル、ドット区切り10進形式の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とreg-nameを完全に区別しないため、曖昧です。構文の曖昧さを排除するために、「ファーストマッチウィン」アルゴリズムを適用します。ホストがIPv4addressのルールと一致する場合は、reg-nameではなく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リテラルを囲むことによって区別されます（ "[" および "]"）。これは、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]に記載されているように、ドット区切り10進表記（"."で区切られた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スキームがホストのデフォルトを定義する場合、そのデフォルトは、ホストサブコンポーネントが未定義の場合、または登録名が空の場合（長さゼロ）に適用されます。たとえば、「file」URIスキームは、オーソリティなし、空のホスト、および「localhost」がすべてエンドユーザーのマシンを意味するように定義されていますが、「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.
この仕様は、特定の登録名ルックアップテクノロジーを義務付けるものではないため、相互運用性に必要なものを超えて、reg-nameの構文を制限しません。代わりに、登録名の構文適合性の問題をURI解決を実行する各アプリケーションのオペレーティングシステムに委任し、そのオペレーティングシステムはホスト識別の目的で何を許可するかを決定します。URI解決の実装では、DNS、ホストテーブル、イエローページ、NetInfo、WINS、または登録名を検索するためのその他のシステムを使用する場合があります。ただし、DNS完全修飾ドメイン名など、グローバルにスコープされた命名システムは、グローバルな範囲を持つことを目的としたURIに必要です。URIプロデューサーは、DNSの使用がすぐには明らかでない場合でも、DNS構文に準拠する名前を使用すべきであり、これらの名前を長さ255文字以下に制限すべきです。
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を介した解決を目的とした国際化ドメイン名を表す場合、名前をルックアップの前にIDNAエンコーディング[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.
オーソリティのポートサブコンポーネントは、ホストに続く10進数のオプションのポート番号によって指定され、単一のコロン（":"）文字によって区切られます。
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生成アプリケーションは、多くの場合、セグメントで許可されている予約文字を使用して、スキーム固有または逆参照ハンドラー固有のサブコンポーネントを区切ります。たとえば、セミコロン（ ";"）およびイコール（ "="）予約文字は、そのセグメントに適用されるパラメーターとパラメーター値を区切るためによく使用されます。コンマ（ ","）予約文字は、同様の目的に使用されることがよくあります。たとえば、1つのURIプロデューサーは、「name;v=1.1」などのセグメントを使用して「name」のバージョン1.1への参照を示す場合がありますが、別のURIは「name,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.
文字スラッシュ（ "/"）および疑問符（ "?"）は、クエリコンポーネント内のデータを表す場合があります。階層区切り文字を探すときにクエリデータをパスデータと区別できないため、相対参照のベースURIとして使用される場合（セクション5.1）、一部の古い誤った実装ではそのようなデータを正しく処理できない可能性があることに注意してください。ただし、クエリコンポーネントは、「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参照は、URIまたは相対参照のいずれかです。URI参照のプレフィックスが、そのコロン区切り文字が続くスキームの構文と一致しない場合、URI参照は相対参照です。
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参照の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 [ "?" query ] [ "#" fragment ]
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:that"）は、スキーム名と間違われるため、相対パス参照の最初のセグメントとして使用することはできません。このようなセグメントは、相対パス参照を作成するには、ドットセグメント（ "./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の構文ルールが必要です。
absolute-URI = scheme ":" hier-part [ "?" query ]
absolute-URI = scheme ":" hier-part [ "?" query ]
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（Base）は、セクション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のパスとマージするための「merge」ルーチンを指します。これは次のように達成されます。
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パスに「/」文字が含まれていない場合はベース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.
擬似コードは、参照されたパスから特別な「.」および「..」完全パスセグメントを解釈および削除するための「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 = ""
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;
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;
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.
URIで最も一般的な操作の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.
URIはリソースを識別するために存在するため、おそらく同じリソースを識別するときに同等と見なされるべきです。ただし、この等価性の定義は、実装がそれらの完全な知識または制御を持っていない限り、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.
文字列の等価性をテストするには、いくつかの基本的な予防策が必要です。この手順は、多くの場合、「ビット単位」または「バイト単位」の比較と呼ばれ、誤解を招く可能性があります。文字列の等価性テストは通常、文字列を構成する文字のペア比較に基づいています。最初から始まり、両方の文字列が尽きてすべての文字が等しいことが判明するまで、あるいは一対の文字が不一致になるか、一方の文字列が他方より先に尽きるまで続きます。
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は、「/」のパスに正規化する必要があります。同様に、明示的な「:port」は、ポートが空になっているか、スキームのデフォルトであるため、ポートとその「:」区切り文字が省略されるため、スキームベースの正規化によって削除される必要があります。たとえば、上記の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）を指定する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」などの特別なデバイス名にも意味を割り当てます。場合によっては、そのような名前の存在をテストするだけで、オペレーティングシステムが無関係なシステム呼び出しを一時停止または呼び起こし、サービス拒否（DoS）および意図しないデータ転送に関する重大なセキュリティ上の懸念につながります。この仕様がこのような重要な文字とデバイス名をすべてリストすることは不可能です。実装者は、アプリケーションに添付されている可能性のあるストレージデバイスの種類の予約済み名と文字を調査し、それに応じて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アドレスの一般的なドット区切り形式のみを許可しますが、URIを処理する多くの実装は、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ビットの数量として解釈され、ネットワークアドレスの右端の2バイト（クラスBネットワークなど）に配置されます。同様に、2つの数値のドット区切り形式は、最後の部分が24ビットの数量として解釈され、ネットワークアドレスの右端の3バイト（クラスA）に配置され、単一の数値（ドットなし）は32ビットの数量として解釈され、ネットワークアドレスに直接保存されることを意味します。混乱をさらに招くことに、一部の実装では、C言語で指定されているように、各ドット部分を10進数、8進数、または16進数として解釈できます（つまり、先頭の0xまたは0Xは16進数を意味し、先頭の0は8進数を意味し、それ以外の場合は数値は10進数として解釈されます）。
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の<scheme>で定義されている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、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、およびHenry Zongaroの貢献に感謝します。
[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 [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
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
scheme = $2 authority = $4 path = $5 query = $7 fragment = $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/>、または単に空白を使用します。
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が抽出されたときに、空白を無視する必要があります。
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]はIPv6リテラルアドレスの定義を[RFC3513]に委ねていますが、残念ながらIPv6addressのABNF記述がないため、[RFC3513]のセクション2.2で定義されたテキスト表現に一致する新しいABNFルールを作成しました。同様に、IPv4addressの定義は、各10進オクテットを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は、一般的な構文によって区切り文字として使用されていない場合でも、どの文字が予約されているか、予約されている時期、そしてなぜ予約されているのかを説明するために書き直されました。感嘆符（ "!"）、アスタリスク（ "*"）、一重引用符（ "'"）、および開き括弧と閉じ括弧（ "(" と ")"）を含む、通常、デコードに安全でないマーク文字は、予約文字と非予約文字の区別を明確にするために、予約されたセットに移され、できればスキームデザイナーの最も一般的な質問に答えることができます。同様に、パーセントエンコードされた文字のセクションが書き直されており、URIノーマライザーには、非予約文字に対応するパーセントエンコードのオクテットをデコードする許可が与えられました。一般に、「エスケープ（escaped）」と「非エスケープ（unescaped）」という用語は、他の形態のエスケープメカニズムとの混乱を減らすために、それぞれ「パーセントエンコード」と「デコードされた」に置き換えられています。
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へのすべての言及は、パスコンポーネントが階層に対して不透明である可能性のある方法のより良い説明に置き換えられました。relativeURIルールは、それらがURIのサブセットであるかどうかについて不必要な混乱を避けるために、relative-refに置き換えられました。最初のセグメントにコロンを持つURIまたはrelative-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およびrelative-refルール内のセクションに移動されましたが、絶対URIから除外されたままです。番号記号（ "#"）文字は、フラグメント構文の再統合の結果として、予約セットに戻されました。
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:」名前空間[RFC2518]や多くのWWWブラウザ実装で内部的に使用される「about:」スキームで実際に行われているように、「scheme:」の後に何もない絶対URIが可能になります。オーソリティとパスの境界に関する曖昧さは、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つのルーチンに分割しました：merge（ベース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
B
base URI 28
C
character encoding 4
character 4
characters 8, 11
coded character set 4
D
dec-octet 20
dereference 9
dot-segments 23
F
fragment 16, 24
G
gen-delims 13
generic syntax 6
H
h16 20
hier-part 16
hierarchical 10
host 18
I
identifier 5
IP-literal 19
IPv4 20
IPv4address 19, 20
IPv6 19
IPv6address 19, 20
IPvFuture 19
L
locator 7
ls32 20
M
merge 32
N
name 7
network-path 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
Q
query 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
S
same-document 27
sameness 9
scheme 16, 17
segment 22, 23
segment-nz 23
segment-nz-nc 23
sub-delims 13
suffix 27
T
transcription 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
Authors' Addresses
著者の連絡先
Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA
Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 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エディター機能の資金は現在、インターネット協会によって提供されています。