RFC3986 日本語訳
3986 Uniform Resource Identifier (URI): Generic Syntax. T.Berners-Lee, R. Fielding, L. Masinter. January 2005. (Format: TXT=141811 bytes) (Obsoletes RFC2732, RFC2396, RFC1808) (Updates RFC1738) (Also STD0066) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループT.バーナーズ・リー要求をネットワークでつないでください: 3986W3C/MIT STD: 66 R.フィールディングアップデート: 1738年の日のソフトウェアは以下を時代遅れにします。 2732、2396、1808L.Masinterカテゴリ: 標準化過程アドビ・システムズ2005年1月
Uniform Resource Identifier (URI): Generic Syntax
Uniform Resource Identifier(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
Uniform Resource Identifier(URI)は抽象的であるか物理的なリソースを特定するキャラクタのコンパクトな系列です。 この仕様は相対的なフォームにあるかもしれないURI参照を決議するための一般的なURI構文と過程を定義します、インターネットにおけるURIの使用のためのガイドラインとセキュリティ問題と共に。 URI構文はすべての有効なURIのスーパーセットである文法を定義します、実現があらゆる可能な識別子の計画特有の要件を知らないでURI参照の共通成分を分析するのを許容して。 この仕様はURIのために生成文法を定義しません。 そのタスクはそれぞれのURI計画の独特の仕様で実行されます。
Berners-Lee, et al. Standards Track [Page 1] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 URI. . . . . . . . . . . . . . . . . . . . 4 1.1.1の概観。 一般的な構文. . . . . . . . . . . . . . . . . 6 1.1.2。 例. . . . . . . . . . . . . . . . . . . . 7 1.1の.3。 URI、URL、およびつぼ. . . . . . . . . . . . . . . 7 1.2。 問題. . . . . . . . . . . . . . . . . 8 1.2.1を設計してください。 転写. . . . . . . . . . . . . . . . . 8 1.2.2。 相互作用. . . 9 1.2.3と識別を切り離します。 階層的な識別子. . . . . . . . . . . . 10 1.3。 構文記法. . . . . . . . . . . . . . . . . . . . 11 2。 キャラクター. . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1。 パーセントをコード化する.122.2。 予約されたキャラクター. . . . . . . . . . . . . . . . . . 12 2.3。 無遠慮な性格. . . . . . . . . . . . . . . . . 13 2.4。 いつ.142.5をコード化しますか、解読しますか? データ. . . . . . . . . . . . . . . . . . . . 14 3を特定します。 構文コンポーネント. . . . . . . . . . . . . . . . . . . . . . 16 3.1。 .173.2を計画してください。 権威. . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1。 ユーザー情報. . . . . . . . . . . . . . . . 18 3.2.2。 ホスト. . . . . . . . . . . . . . . . . . . . . . 18 3.2.3。 .223.3を移植してください。 経路. . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4。 .233.5について質問してください。 .244を断片化してください。 用法. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1。 URI参照. . . . . . . . . . . . . . . . . . . . . 25 4.2。 相対参照. . . . . . . . . . . . . . . . . . . 26 4.3。 絶対URI. . . . . . . . . . . . . . . . . . . . . . 27 4.4。 同じドキュメント参照. . . . . . . . . . . . . . . . 27 4.5。 接尾語参照. . . . . . . . . . . . . . . . . . . . 27 5。 参照解決. . . . . . . . . . . . . . . . . . . . . 28 5.1。 基地URI. . . . . . . . . . . . . . . . 28 5.1.1を確立します。 .2に内容. . . . . . . . . . 29 5.1に埋め込まれた基地のURI 要約実体. . . . . 29 5.1.3からURIを基礎づけてください。 検索URI. . . . . . . . 30 5.1.4からURIを基礎づけてください。 デフォルト基地のURI. . . . . . . . . . . . . . . . 30 5.2。 相対的な解決. . . . . . . . . . . . . . . . . . 30 5.2.1。 基地のURI. . . . . . . . . . . . . 31 5.2.2をあらかじめ分析してください。 参照. . . . . . . . . . . . . . 31 5.2.3を変えてください。 経路. . . . . . . . . . . . . . . . . . 32 5.2.4を合併してください。 ドットセグメント. . . . . . . . . . . . . . 33 5.3を取り除いてください。 コンポーネントRecomposition. . . . . . . . . . . . . . . . 35 5.4。 参照解決の例. . . . . . . . . . . . . 35 5.4の.1。 正常な例. . . . . . . . . . . . . . . . 36 5.4の.2。 異常な例. . . . . . . . . . . . . . . 36
Berners-Lee, et al. Standards Track [Page 2] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[2ページ]。
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
6. 正常化と比較. . . . . . . . . . . . . . . . . 38 6.1。 等価性. . . . . . . . . . . . . . . . . . . . . . 38 6.2。 比較はしご. . . . . . . . . . . . . . . . . . . 39 6.2.1。 簡単なストリング比較. . . . . . . . . . . . 39 6.2.2。 構文ベースの正常化. . . . . . . . . . . 40 6.2.3。 計画ベースの正常化. . . . . . . . . . . 41 6.2.4。 プロトコルベースの正常化. . . . . . . . . . 42 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 43 7.1。 信頼性と一貫性. . . . . . . . . . . . . . 43 7.2。 悪意がある工事. . . . . . . . . . . . . . . . . 43 7.3。 バックエンドコード変換. . . . . . . . . . . . . . . . . . 44 7.4。 まれなIPアドレス形式. . . . . . . . . . . . . . . . 45 7.5。 機密情報. . . . . . . . . . . . . . . . . 45 7.6。 意味攻撃. . . . . . . . . . . . . . . . . . . . 45 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 46 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 46 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1。 引用規格. . . . . . . . . . . . . . . . . . 46 10.2。 文脈. . . . . . . . . . . . . . . . . 51D.でURIを区切りながら正規表現. . . . . . 50C.とのURI参照を分析するURI. . . . . . . . . . . . . . . . . . . . 49B.のための有益な参照. . . . . . . . . . . . . . . . . 47のA.の集まっているABNFがRFCから変化する、2396、.53D.1 追加. . . . . . . . . . . . . . . . . . . . . . . 53D.2。 変更. . . . . . . . . . . . . . . . . . . . . 53インデックス. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 60の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 61
Berners-Lee, et al. Standards Track [Page 3] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[3ページ]。
1. Introduction
1. 序論
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].
Uniform Resource Identifier(URI)はリソースを特定するための簡単で広げることができる手段を提供します。 URI構文と意味論のこの仕様は、これらの識別子の使用が1990をさかのぼるWWWのグローバルな情報イニシアチブで紹介された概念から得られて、「WWWの普遍的なリソース識別子」[RFC1630]で説明されます。 構文は、「インターネット資料ロケータのための機能的な推薦」[RFC1736]と「一定のリソース名のための機能条件書」[RFC1737]で広げられた推薦を満たすように設計されています。
This document obsoletes [RFC2396], which merged "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URIs. It obsoletes [RFC2732], which introduced syntax for an IPv6 address. It excludes portions of RFC 1738 that defined the specific syntax of individual URI schemes; those portions will be updated as separate documents. The process for registration of new URI schemes is defined separately by [BCP35]. Advice for designers of new URI schemes can be found in [RFC2718]. All significant changes from RFC 2396 are noted in Appendix D.
このドキュメントは[RFC2396]を時代遅れにします。(それは、シングル(すべてのURIのための一般的な構文)を定義するために、「Uniform Resource Locator」[RFC1738]と「相対的なUniform Resource Locator」[RFC1808]を合併しました)。 それは[RFC2732]を時代遅れにします。(それは、IPv6アドレスのために構文を導入しました)。 それは個々のURI計画の特定の構文を定義したRFC1738の一部を除きます。 別々のドキュメントとしてそれらの部分をアップデートするでしょう。 新しいURI計画の登録のための過程は別々に[BCP35]によって定義されます。 [RFC2718]で新しいURI計画のデザイナーのためのアドバイスを見つけることができます。 RFC2396からのすべての著しい変化がAppendix 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"を呼ぶことに代わって「キャラクタコード化」を使用します。
1.1. Overview of URIs
1.1. URIの概観
URIs are characterized as follows:
URIは以下の通り特徴付けられます:
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.
一様性はいくつかの利益を提供します。 それは、異なったタイプに関するリソース識別子が同じ文脈で使用されるのを許容します、それらのリソースにアクセスするのに使用されるメカニズムが異なるかもしれないなら。 それは異なったタイプに関するリソース識別子の向こう側に一般的な構文のコンベンションの一定の意味解釈を許容します。 既存の識別子が使用されている方法を妨げないで、それは新しいタイプに関するリソース識別子の導入を許します。 それは、識別子が多くの異なった文脈で再利用されるのを許容します、その結果、新しいアプリケーションかプロトコルがプレ既存の、そして、大きくて、広く使用されたセットのリソース識別子に投機することを許可します。
Berners-Lee, et al. Standards Track [Page 4] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[4ページ]。
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).
識別子は識別の範囲の中の他のすべてのものと特定されていることを区別するのに必要である情報を具体化します。 私たちの用語「特定」と「特定」の使用は他のすべてのリソースと1つのリソースを区別するこの目的を示します、その目的がどう優れているか(例えば、名前、アドレス、または文脈による)にかかわらず。 識別子が参照をつけられた何に関するアイデンティティを定義するか、または具体化するかという仮定としてこれらの用語を間違うべきではありません、それはいくつかの識別子のためのそうであるかもしれませんが。 また、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
この仕様はリソース(アプリケーションがリソース、またはリソースを特定することのためにURIを使用するかもしれないシステムの種類を示そうとするかもしれない理由)の本質にどんな限界も置きません。 この仕様は、URIが時間がたつにつれて同じリソースを特定することへ持続するのを必要としません、それがすべてのURI計画の一般的な目標ですが。 それにもかかわらず、これで何でもない
Berners-Lee, et al. Standards Track [Page 5] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[5ページ]。
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の部分集合にアプリケーションを防ぎます。
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は使用されるべきです、オンラインヘルプマニュアルが終わりのユーザのファイルシステム(例えば、「ファイル:///etc/hosts」)のファイルを示す時のように。
1.1.1. Generic Syntax
1.1.1. 一般的な構文
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計画の構文のスーパーセットです。
Berners-Lee, et al. Standards Track [Page 6] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[6ページ]。
1.1.2. Examples
1.1.2. 例
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
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
ldap://[2001: db8: : 7]/cはGBと等しいです--objectClass1?
mailto:John.Doe@example.com
mailto: John.Doe@example.com
news:comp.infosystems.www.servers.unix
ニュース: comp.infosystems.www.servers.unix
tel:+1-816-555-1212
tel: +1-816-555-1212
telnet://192.0.2.16:80/
telnet://192.0.2.16: 80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
つぼ:オアシス:名前:仕様:docbook:dtd:xml: 4.1 .2
1.1.3. URI, URL, and URN
1.1.3. URI、URL、およびつぼ
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の部分集合を示します。 用語「一定のリソース名」(URN)は、名前の特性でリソースが存在するのをやめるか、または入手できなくなるときさえ、グローバルにユニークであって、しつこいままであるのに必要である「つぼ」計画[RFC2141]といかなる他のURIとも両方のURIを呼ぶのに歴史的に使用されました。
An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].
個々の計画は「名前」か「ロケータ」の存在ちょうど1として分類される必要はありません。 どんな与えられた計画からのURIの例でも、名前、ロケータまたは両方の特性があるかもしれません、しばしば計画のどんな品質でもというよりむしろ命名権威で識別子の課題における固執と注意によって。 将来の仕様と関連するドキュメンテーションは一般項の「URL」というより制限している用語よりむしろ「ユリ」と「つぼ」[RFC3305]を使用するべきです。
Berners-Lee, et al. Standards Track [Page 7] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[7ページ]。
1.2. Design Considerations
1.2. デザイン問題
1.2.1. Transcription
1.2.1. 転写
The URI syntax has been designed with global transcription as one of its main considerations. A URI is a sequence of characters from a very limited set: the letters of the basic Latin alphabet, digits, and a few special characters. A URI may be represented in a variety of ways; e.g., ink on paper, pixels on a screen, or a sequence of character encoding octets. The interpretation of a URI depends only on the characters used and not on how those characters are represented in a network protocol.
URI構文は主な問題の1つとしてグローバルな転写で設計されています。 URIは非常に限られたセットからのキャラクタの系列です: 基本的なローマ字の手紙、ケタ、およびいくつかの特殊文字。 URIはさまざまな方法で表されるかもしれません。 例えば、紙上のスクリーンの画素、またはキャラクタの系列が八重奏をコード化することでのインク。 URIの解釈はそれらのキャラクタがネットワーク・プロトコルでどう代理をされるかではなく、使用されるキャラクタだけに頼っています。
The goal of transcription can be described by a simple scenario. Imagine two colleagues, Sam and Kim, sitting in a pub at an international conference and exchanging research ideas. Sam asks Kim for a location to get more information, so Kim writes the URI for the research site on a napkin. Upon returning home, Sam takes out the napkin and types the URI into a computer, which then retrieves the information to which Kim referred.
簡単なシナリオは転写の目標について説明できます。 国際会議にパブに座っていて、研究考えを交換して、2人の同僚、サム、およびキムを想像してください。 サムが詳しい情報を得るためにキムに位置を求めるので、キムはナプキンに関する研究サイトにURIを書きます。 家に帰ると、サムは、コンピュータにナプキンを取り出して、URIをタイプします。(次に、それは、キムが参照した情報を検索します)。
There are several design considerations revealed by the scenario:
シナリオによって明らかにされたいくつかのデザイン問題があります:
o A URI is a sequence of characters that is not always represented
as a sequence of octets.
o URIは八重奏の系列としていつも表されるというわけではないキャラクタの系列です。
o A URI might be transcribed from a non-network source and thus
should consist of characters that are most likely able to be
entered into a computer, within the constraints imposed by
keyboards (and related input devices) across languages and
locales.
o URIは、非ネットワークソースから転写されるかもしれなくて、その結果、たぶんコンピュータに入ることができるキャラクタから成るべきです、キーボード(そして、入力装置を関係づける)によって言語と現場の向こう側に課された規制の中で。
o A URI often has to be remembered by people, and it is easier for
people to remember a URI when it consists of meaningful or
familiar components.
o URIはしばしば人々によって覚えていられなければなりません、そして、重要であるか身近なコンポーネントから成るとき、人々がURIを覚えているのは、より簡単です。
These design considerations are not always in alignment. For example, it is often the case that the most meaningful name for a URI component would require characters that cannot be typed into some systems. The ability to transcribe a resource identifier from one medium to another has been considered more important than having a URI consist of the most meaningful of components.
これらのデザイン問題はいつも整列中であるというわけではありません。 例えば、しばしば、URIコンポーネントのための最も重要な名前はいくつかのシステムにタイプできない文字を必要とするでしょう。1つの媒体から別の媒体までリソース識別子を転写する能力はURIが最も重要なコンポーネントから成らせるより重要であると考えられました。
In local or regional contexts and with improving technology, users might benefit from being able to use a wider range of characters; such use is not defined by this specification. Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this
地方の、または、地方の関係と技術を改良するのに、ユーザは、より広い範囲のキャラクタを使用できることから利益を得るかもしれません。 そのような使用はこの仕様で定義されません。 パーセントでコード化された八重奏(セクション2.1)は、これであるなら米国-ASCIIコード化文字集合の範囲の外でキャラクタの代理をするのにURIの中で使用されるかもしれません。
Berners-Lee, et al. Standards Track [Page 8] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[8ページ]。
representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI.
表現は計画の近く、または、URIが参照をつけられるプロトコル要素で許容されています。 そのような定義はURIのためにパーセントによってコード化されている前に、八重奏へのそれらのキャラクタを写像するのに使用されるキャラクタコード化を指定するべきです。
1.2.2. Separating Identification from Interaction
1.2.2. 相互作用と識別を切り離します。
A common misunderstanding of URIs is that they are only used to refer to accessible resources. The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute, or natural language text in which it appears.
URIの一般的な誤解はそれらがアクセス可能なリソースを示すのに使用されるだけであるということです。 URI自体は識別を提供するだけです。 リソースへのアクセスは、URIの存在によって保証されないで、また含意されません。 代わりに、URI参照に関連しているどんな操作もそれが載っているプロトコル要素、データの形式属性、または自然言語テキストによって定義されます。
Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by words such as "access", "update", "replace", or "find attributes". Such operations are defined by the protocols that make use of URIs, not by this specification. However, we do use a few general terms for describing common operations on URIs. URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; this resolution may require several iterations. To use that access mechanism to perform an action on the URI's resource is to "dereference" the URI.
URIを考えて、システムは、リソースにおけるさまざまな操作を実行するのを試みるかもしれません、「アクセス」、「アップデート」、「取り替え」、または「掘り出し物の属性」などの単語によって特徴付けられるかもしれないように。 そのような操作はこの仕様によって定義されるのではなく、URIを利用するプロトコルによって定義されます。 しかしながら、私たちは、URIで一般的な操作について説明するのにいくつかの一般項を使用します。 URI「解決」はアクセス機構を決定する過程であり、反参照に必要な適切なパラメタはURIです。 この決議はいくつかの繰り返しを必要とするかもしれません。 動作を実行するのにそのアクセス機構を使用するために、"反参照"にはURIがURIのリソースに、あります。
When URIs are used within information retrieval systems to identify sources of information, the most common form of URI dereference is "retrieval": making use of a URI in order to retrieve a representation of its associated resource. A "representation" is a sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated. Retrieval is achieved by a process that might include using the URI as a cache key to check for a locally cached representation, resolution of the URI to determine an appropriate access mechanism (if any), and dereference of the URI for the sake of applying a retrieval operation. Depending on the protocols used to perform the retrieval, additional information might be supplied about the resource (resource metadata) and its relation to other resources.
URIが情報筋を特定するのに情報検索システムの中で使用されるとき、URI反参照の最も一般的なフォームは「検索」です: 関連リソースの表現を検索するのに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
情報検索システムにおけるURI参照は遅延バインディングになるように設計されています: アクセスの結果は、それがアクセスされているとき、一般に、断固として、時間の上か相互作用の他の局面のため異なるかもしれません。 これらの参照は将来使用されるために作成されます: 特定されていることは過去に得られた何らかの特定の結果ではなく、将来の結果に本当であると予想されるむしろ何らかの特性です。 そのような場合、URIによって示されたリソースは実際に観測されるように特性の同一性です。
Berners-Lee, et al. Standards Track [Page 9] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[9ページ]。
over time, perhaps elucidated by additional comments or assertions made by the resource provider.
恐らくリソースプロバイダーによってされた追加コメントか主張で解明された時間。
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の決議は1つ以上のプロトコルの使用を必要とするかもしれません(例えば、DNSとHTTPの両方による表現であるときに、"http"にアクセスするのに通常使用されて、URIの起源サーバがローカルなキャッシュで見つけられないということです)。
1.2.3. Hierarchical Identifiers
1.2.3. 階層的な識別子
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の相対的な参照箇所は、ドキュメント木がそれらの位置とアクセス体系から部分的に独立しているのを許容します。 例えば、相対参照でドキュメントが互いについて言及するなら、1セットのハイパーテキストドキュメントがそれぞれの「ファイル」、"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,
相対参照(セクション4.2)は、参照文脈と目標URIの間の階層的な名前スペースの中で違いについて説明することによって、リソースを示します。 参照解決アルゴリズム
Berners-Lee, et al. Standards Track [Page 10] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[10ページ]。
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.
セクションに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つ以上のドットセグメントを含んでいない場合階層的処理が影響を全くオンに与えないので絶対URIが中で参照を使用した、(経路セグメントを完成する、」、」、」、」、中で説明される、セクション3.3) URI体系仕様は、スラッシュキャラクタ、疑問符キャラクタ、およびURI「以下を計画してください。」と「以下を計画してください。」の使用を禁じることによって、不明瞭な識別子を定義できます。
1.3. Syntax Notation
1.3. 構文記法
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]のAugmented BN記法(ABNF)記法を使用します、その仕様で定義された以下のコアABNFシンタックス・ルールを含んでいて: アルファー(手紙)、CR(復帰)、DIGIT(10進数字)、DQUOTE(二重引用文)、HEXDIG(16進数字)、LF(改行)、およびSP(スペース)。 完全なURI構文はAppendix Aに集められます。
2. Characters
2. キャラクター
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
ABNF記法は、米国-ASCIIコード化文字集合[ASCII]に基づく非負の整数(codepoints)になるように端末の値を定義します。 URIがキャラクタの系列であるので、私たちはURI構文を理解するためにその関係を逆にしなければなりません。 したがって
Berners-Lee, et al. Standards Track [Page 11] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[11ページ]。
integer values used by the ABNF must be mapped back to their corresponding characters via US-ASCII in order to complete the syntax rules.
シンタックス・ルールを完成するために米国-ASCIIでABNFによって使用された整数値を彼らの対応する性格に写像して戻さなければなりません。
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の中で構文コンポーネントを区切るのに使用されるかもしれません。
2.1. Percent-Encoding
2.1. パーセントをコード化しています。
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インチは2進の八重奏「00100000」(ABNF: %x20)のためのパーセントコード化です。(米国-ASCIIでは、それは、間隔文字(SP)に対応します)。 セクション2.4は、パーセントコード化と解読がいつであるかを適用されていた状態で説明します。
pct-encoded = "%" HEXDIG HEXDIG
pctによってコード化された=「%」HEXDIG HEXDIG
The uppercase hexadecimal digits 'A' through 'F' are equivalent to the lowercase digits 'a' through 'f', respectively. If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent. For consistency, URI producers and normalizers should use uppercase hexadecimal digits for all percent- encodings.
大文字している16進数字''突き抜ける'F'は'f'を通してそれぞれ小文字のケタ'a'に同等です。 2つのURIがパーセントでコード化された八重奏に使用される16進数字の場合だけにおいて異なるなら、それらは同等です。 一貫性のために、URIプロデューサーと正規化群はすべてのパーセントencodingsのための大文字している16進数字を使用するべきです。
2.2. Reserved Characters
2.2. 予約されたキャラクター
URIs include components and subcomponents that are delimited by characters in the "reserved" set. These characters are called "reserved" because they may (or may not) be defined as delimiters by the generic syntax, by each scheme-specific syntax, or by the implementation-specific syntax of a URI's dereferencing algorithm. If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed.
URIは「予約された」セットにおけるキャラクタによって区切られるコンポーネントとサブコンポーネントを含んでいます。 または、これらのキャラクタが彼らが呼ばれるので「予約されている」と呼ばれる、()、ジェネリック構文、それぞれの体系特有の構文、またはURIの「反-参照をつけ」アルゴリズムの実装特有の構文によるデリミタと定義されるかもしれなくなってください。 URIコンポーネントのためのデータがデリミタとして控え目なキャラクタの目的と衝突するなら、URIが形成される前に闘争データはパーセントでコード化していなければなりません。
Berners-Lee, et al. Standards Track [Page 12] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[12ページ]。
reserved = gen-delims / sub-delims
予約された=delimsに情報を得ている/サブdelims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
「delimsに情報を得ている=」:、」 / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
サブ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.
ジェネリックURIコンポーネントのデリミタがセクション3で説明したように控え目なキャラクタ(delimsに情報を得ている)の部分集合は使用されています。 コンポーネントのABNFシンタックス・ルールは直接予約されたか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コンポーネントで見つけられて、役割を区切らないのがそのキャラクタで知られているなら、米国-ASCIIにおけるそのキャラクタのコード化に対応するデータ八重奏を表しながら、それを解釈しなければなりません。
2.3. Unreserved Characters
2.3. 無遠慮な性格
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.
URIで許容されていますが、予約された目的を持っていないキャラクターは無遠慮であると呼ばれます。 これらは大文字していて小文字の手紙、10進数字、ハイフン、期間、強調、およびティルドを含んでいます。
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
「無遠慮な=アルファー/ DIGIT /「-」/」、」 / "_" / "~"
Berners-Lee, et al. Standards Track [Page 13] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[13ページ]。
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.
対応するパーセントでコード化された米国-ASCII八重奏との無遠慮な性格の交換において異なるURIは同等です: 彼らは同じリソースを特定します。 しかしながら、URI比較実装は比較の前にいつも正常化を実行するというわけではありません(セクション6を見てください)。 一貫性のために、アルファー(%の41%の5Aと%の61%の7A)の範囲でのパーセントでコード化された八重奏(DIGIT(%30%39))が(%2D)をハイフンで結ぶ、以上(%2E)、(%5F)の下線を引いてくださいか、ティルド(%7E)をURIプロデューサーが作成するべきでなくて、URIで見つけると、URI正規化群は彼らの対応する無遠慮な性格に解読するべきです。
2.4. When to Encode or Decode
2.4. いつ、コード化するか、または解読するか。
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インチとしてコード化していなければなりません。 実装は、一度より同じストリングをもう少し何パーセントもコード化してはいけませんし、また解読してはいけません、既に解読されたストリングを解読するのが、パーセントコード化の始まりとしてパーセントデータ八重奏を誤解するのに通じるかもしれないとき、既にパーセントでコード化されたストリングを何パーセントもコード化する場合で逆もまた同様です。
2.5. Identifying Data
2.5. データを特定します。
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
URIキャラクタはそれぞれのURIコンポーネントのためのデータを特定しながら、提供します、システムの間の識別のための外部のインタフェースとして機能して。URI(そして、相互運用性要件の範囲を超えてこの仕様でこのようにして定義される)を使用するクライアントURI生産インタフェースの存在と自然に隠されますが、それはURIキャラクタ問題の解釈における混乱と誤りの頻繁な源です。 Implementersはかかわった複数の文字符号化があるのを意識していなければなりません。
Berners-Lee, et al. Standards Track [Page 14] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[14ページ]。
production and transmission of URIs: local name and data encoding, public interface encoding, URI character encoding, data format encoding, and protocol encoding.
URIの生産と送信: 地方名とzデータの符号化、公衆はコード化、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キャラクタ(予約されて、無遠慮で、パーセントのencodingsの)に変えるでしょう。 それらのキャラクタは参照としてデータの形式(例えば、ドキュメント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コンポーネントの中に現れる無遠慮な性格は、米国-ASCIIにおけるそのキャラクタのコード化に対応するデータ八重奏を表しながら、解釈されます。 URIの消費者は、文字「X」が八重奏「01011000」に対応すると仮定します、そして、その仮定が不正確であるときにさえ、それを作るのにおいて害が全くありません。 一般に、内部的にEBCDICなどの異なった文字符号化の形に識別子を供給するシステムは内部のインタフェースでUTF-8[STD63](または、米国-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.
例えば、情報がHTTPサーバを通してインターネットで局所的にEBCDICベースのファイルシステムを使用することで保存されたデータをクライアントに提供するサービスであると考えてください。そのファイルシステムの上に「ラグナビーチ」という名前がある状態で作者がファイルを作成すると、そのリソースに対応する"http"URIが重要なストリング「ラグナ%20Beach」を含むと予想されます。 しかしながら、そのサーバがひどく安易な生の八重奏マッピングを使用することによってURIを生産するなら、結果は" %D3%81%87%A4%95%81@%C2%85%81%83%88 "を含むURIでしょう。 URIを生産する前に、内部のコード変換インタフェースは米国-ASCIIのスーパーセットへの地方名をコード変換によるこの問題に固定します。 「当然、そのようなインタフェースにおける入って来るURIの適切な解釈は、逆のコード変換が地方名を得るために適用される前にパーセントでコード化された八重奏が解読されるのを(」 例えば、SPへの%20インチ)必要とします。
In some cases, the internal interface between a URI component and the identifying data that it has been crafted to represent is much less direct than a character encoding translation. For example, portions of a URI might reflect a query on non-ASCII data, or numeric
いくつかの場合、それが表すために作られたURIコンポーネントと特定データの間との内部のインタフェースは文字符号化翻訳よりあまりダイレクトではありません。 例えば、URIの部分は非ASCIIデータ、または数値に質問を反映するかもしれません。
Berners-Lee, et al. Standards Track [Page 15] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[15ページ]。
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を生産する前に適用される追加コード化要件でコンポーネントを定義するかもしれません。
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体系がUniversal文字コード[UCS]からキャラクタから成る原文のデータを表すコンポーネントを定義するとき、UTF-8文字符号化[STD63]に従って、データは最初に、八重奏としてコード化されるべきです。 そして、予約していないセットでキャラクタと食い違っているそれらの唯一の八重奏はコード化されたパーセントであるべきです。 %の3ユーロの%の82%のA2"「例えば、キャラクタAは「A」として代理をされて、墓があるキャラクタのラテン語の大文字Aは文字Aが表される」 %C3の%80インチ、およびキャラクタカタカナとして表されるでしょう」。
3. Syntax Components
3. 構文コンポーネント
The generic URI syntax consists of a hierarchical sequence of components referred to as the scheme, authority, path, query, and fragment.
ジェネリックURI構文は体系、権威、経路、質問、および断片と呼ばれたコンポーネントの階層的な系列から成ります。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
「URI=体系」:、」 hier-部分[“?"質問][「#」断片]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
経路絶対か経路根のないか経路権威経路-abempty/空の「hier-部分=」//
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つのスラッシュキャラクタ(「//」)と共に始まることができません。 これらの制限は経路(セクション3.3)への5つの異なったABNF規則をもたらします。その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
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | 体系権威経路質問断片| _____________________|__ /\/\つぼ:例:動物:フェレット:鼻
Berners-Lee, et al. Standards Track [Page 16] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[16ページ]。
3.1. Scheme
3.1. 体系
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.
体系名が手紙、ケタ、および(「+」)のどんな組み合わせも文字で始まって、あとに続いたキャラクタのa系列から成る、以上、(「」、)、または、ハイフン(「-」。) 体系がケース神経が鈍いのですが、標準形が小文字であるので、体系を指定するドキュメントは小文字を処理しなければなりません。 実装は、丈夫さのために大文字が体系名(例えば、"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]によって定義されます。 体系登録は体系名とそれらの仕様の間のマッピングを維持します。 [RFC2718]で新しいURI体系のデザイナーのためのアドバイスを見つけることができます。 URI体系仕様はまた、それらの体系特有の構文に合っているすべてのストリングが<の絶対URIの>文法に合うように、それら自身の構文を定義しなければなりません、セクション4.3で説明されるように。
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)であるとミスリードするために構成されたのを示すかもしれないジェネリック構文の乱用を検出するのを助けます。
3.2. Authority
3.2. 権威
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の終わりまでに終えられます。
Berners-Lee, et al. Standards Track [Page 17] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[17ページ]。
authority = [ userinfo "@" ] host [ ":" port ]
権威=[userinfo"@"]ホスト[「:」 ポート]
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のような時間が「反-参照をつけ」られるまで。
3.2.1. User Information
3.2.1. ユーザー情報
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 / ":" )
userinfoは*と等しいです。「(無遠慮であるかpctによってコード化されたかサブdelimsの/、」、:、」、)
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
userinfoの「ユーザ: パスワード」がさばく形式の使用は推奨しないです。 アプリケーションが最初のコロンの後にクリアテキストとして少しのデータも表すべきでない、(「:」、)、コロン後のデータが空のストリング(パスワードを全く示さないで)でないならuserinfoサブコンポーネントの中で見つけられたキャラクタ。 アプリケーションは、参照の一部としてそれを受け取るとき、そのようなデータを無視するか、または拒絶するのを選ぶかもしれなくて、非暗号化されたフォームにおける、そのようなデータのストレージを拒絶するべきです。 ほとんどすべての場合それが使用されたところでクリアテキストにおける、認証情報の通過はセキュリティリスクであると判明しました。
Applications that render a URI for the sake of user feedback, such as in graphical hypertext browsing, should render userinfo in a way that is distinguished from the rest of a URI, when feasible. Such rendering will assist the user in cases where the userinfo has been misleadingly crafted to look like a trusted domain name (Section 7.6).
グラフィカルなハイパーテキストブラウジングなどのユーザフィードバックのためにURIをレンダリングするアプリケーションはURIの残りと区別される方法でuserinfoをレンダリングするべきです、可能であるときに。 そのようなレンダリングはuserinfoが信じられたドメイン名(セクション7.6)に似るように誤解させて作られたケースにユーザを助けるでしょう。
3.2.2. Host
3.2.2. ホスト
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
権威のホストサブコンポーネントは角括弧の中でカプセル化されたIPリテラル、点を打たされた10進フォームでのIPv4アドレス、または登録名によって特定されます。 ホストサブコンポーネントはケース神経が鈍いです。 URIの中のホストサブコンポーネントの存在は、体系がインターネットの与えられたホストへのアクセスを必要とするのを含意しません。 多くの場合、ホスト構文は目的にだけ使用されます。
Berners-Lee, et al. Standards Track [Page 18] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[18ページ]。
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.
存在を再利用するのにおいて、登録手続は、DNSのために作成して、展開しました、その結果、別の登録を配布する費用のないグローバルにユニークな名前を得ます。 しかしながら、そのような使用はそれ自身のコストと共に来ます: ドメイン名所有権は時間がたつにつれて、URIプロデューサーによって予期されなかった理由を交換するかもしれません。 他の場合では、ホストコンポーネントの中のデータはインターネット・ホストと関係ない登録名を特定します。 それが唯一の目的ではなく、その最も一般的な目的であるので、私たちはABNF規則に「ホスト」という名前を使用します。
host = IP-literal / IPv4address / reg-name
ホストreg=IP-リテラル/IPv4address/名
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-名前を見分けるというわけではないので、ホストのためのシンタックス・ルールはあいまいです。 構文のあいまいさを除くために、私たちは「最初のマッチ勝利」アルゴリズムを適用します: ホストがIPv4addressのための規則に合っているなら、それはreg-名前ではなく、IPv4アドレスリテラルであると考えられるべきです。 ホストは大文字と小文字を区別しないのですが、プロデューサーと正規化群はパーセントencodingsに大文字を使用しているだけである間一様性のために登録名と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 ) "]"
「[「(IPv6address / IPvFuture)」]」というIP-リテラル=
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
「IPvFutureは「v」1*HEXDIG」と等しいです。」 1*「(無遠慮であるかサブ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の文字通りのアドレスによって特定されたホストは前のバージョン旗なしで角括弧で代理をされます。 IPv6の文字通りのアドレスのテキスト定義に関する翻訳がここにあるなら、ABNFは[RFC3513]に提供しました。 この構文はゾーン識別子を扱いながら見られたIPv6をサポートしません。
Berners-Lee, et al. Standards Track [Page 19] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[19ページ]。
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のアドレスの原文の形式で表されるかもしれません。 アドレスの中の連続した無評価された16ビットの1つ以上のつ以上の系列は削除されるかもしれません、発音省略をマークするそれらの場所にそれらのすべてのケタを省略して、まさに連続した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 ] "::"
「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
「ls32が等しい、(h16、」 : 」 h16) /IPv4address。 アドレスの最も最少に重要な32ビット
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
h16は1*4HEXDIGと等しいです。 16進で表されたアドレスの16ビット
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の文字通りのアドレスによって特定されたホストがドット付き10進法で代理をされる、(範囲0〜255の4つの10進数の系列、切り離されて、」、)、中では、[RFC0952]の参照で同じくらい説明されています[RFC1123]。 他のフォームの点を打たされた記法がセクション7.4で説明されるようにいくつかのプラットホームで解釈されるかもしれませんが、4つの八重奏のドット付き10進法フォームだけがこの文法によって許容されていることに注意してください。
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
「IPv4address=DEC社八重奏」 」 DEC社八重奏、」 . 」 DEC社八重奏、」 . 」 DEC社八重奏
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
DEC社八重奏はDIGITと等しいです。 0-9/%x31-39ケタ。 10-99/「1インチの2DIGIT」。 100-199/、「2インチの%x30-34、ケタ、」、。 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
登録名によって特定されたホストは通常、局所的に定義されたホストかサービス名登録の中のルックアップのために意図するキャラクタの系列です、URIの体系特有の意味論が、特定の登録(または、固定ネームテーブル)が代わりに使用されるのを必要とするかもしれませんが。 最も一般的な名前登録メカニズムはドメインネームシステム(DNS)です。 DNSのルックアップのために意図する登録名は構文を使用します。
Berners-Lee, et al. Standards Track [Page 20] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[20ページ]。
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.
[RFC1034]のセクション3.5と[RFC1123]のセクション2.1では、定義されます。 「そのような名前はラベルが分離したドメインの系列から成る」、」、英数字とまた、ことによると「-」キャラクタを含む各ドメインラベル始めと結末。 「シングルはDNSの完全修飾ドメイン名の一番右のドメインラベルのあとに続くかもしれません」。. 」 完全なドメイン名と何らかの局所領域を見分けるのが必要であるかどうかということであるべきです。
reg-name = *( unreserved / pct-encoded / sub-delims )
reg-名前=*(無遠慮であるかpctによってコード化されるかサブdelims)です。
If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid.
ホストサブコンポーネントが未定義であるか、または登録名が空であるときに(ゼロ・レングス)、URI体系がホストのためにデフォルトを定義するなら、そのデフォルトは適用されます。 例えば、「ファイル」URI体系が定義されるので、権威がなく、空のホスト、および"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名の構文を制限しません。 代わりに、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-名前構文は、基本的な名前解決技術から独立している一定の方法で非ASCII登録名を表すためにパーセントでコード化された八重奏を許容します。 UTF-8[STD63]によると、最初に非ASCII文字をコード化しなければなりません、そして、そして、対応するUTF-8系列の各八重奏はURIキャラクタとして表されるためにコード化されたパーセントでなければなりません。 それがUTF-8キャラクタシーケンスを表すのに使用されない場合、URI生産アプリケーションはホストでパーセントコード化を使用してはいけません。 非ASCII登録名が解決のためにDNSを通して意図する国際化ドメイン名を表すとき、名前を名前ルックアップの前に[RFC3490]をコード化するIDNAに変えなければなりません。 URIプロデューサーはパーセントコード化よりむしろIDNAコード化にこれらの登録名を提供するべきです、彼らがレガシーURIレゾルバと共に相互運用性を最大にしたいなら。
Berners-Lee, et al. Standards Track [Page 21] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[21ページ]。
3.2.3. Port
3.2.3. ポート
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.
権威のポートサブコンポーネントがホストに続いて、小数における任意のポートナンバーによって指定されて、1コロンによってそれから区切られる、(「:」、)、キャラクタ。
port = *DIGIT
ポートは*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プロデューサーと正規化群がポートの部品を省略するべきである、それ、」、:、」 ポートがあるなら、デリミタが空になるか、または値であるなら体系のデフォルトのものと同じでしょう。
3.3. Path
3.3. 経路
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.
経路コンポーネントはURIの体系と(もしあれば)の命名権威の範囲の中に非階層的な質問コンポーネント(セクション3.4)におけるデータと共にリソースを特定するのに役立つ通常、階層的なフォームで組織化されたデータを保管しています。 経路は最初の疑問符(“?")かナンバー記号(「#」)キャラクタ、または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参照の中で経路サブストリングに合うでしょう。 私たちは、パーサによってこれらの規則の1つに合わせられた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
経路は経路-abemptyと等しいです。 「」 /で、始まる」か、空であるか、または経路絶対です。 」 //」 /経路-noschemeだけを「」 /で、始まりません」。 非コロンで、経路セグメント/根がない状態で、始まります。 セグメント/が経路空の状態で始まります。 キャラクタがありません。
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
「経路-abemptyは*(「/」セグメント)経路絶対の=と等しく」/」 [セグメント-nz*(「/」セグメント)]経路-noschemeはセグメント-nz-nc*(「/」セグメント)経路根のない=セグメント-nz*(「/」セグメント)経路空の=0<pchar>と等しいです。
Berners-Lee, et al. Standards Track [Page 22] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[22ページ]。
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
セグメント=*pcharセグメント-nzは1*pcharセグメント-nz-nc=1*と等しいです(無遠慮であるかpctによってコード化されたかサブdelimsの/"@")。 「少しもコロンのない非ゼロ・レングスセグメント」:、」
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
「=無遠慮であるかpctによってコード化されたかサブdelimsのpchar/」:、」 / "@"
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が相対参照に文脈として使用されるときだけ、階層構造を示すスラッシュキャラクタの使用が必要です。 <mailto: 例えば、URI fred@example.com 、gt;、<foo://info.example.com?URI fred>には、人影のない経路が" fred@example.com "ありますが、経路を持っています。
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プロデューサーがセグメントを使用するかもしれない、「名前; =1.1インチに対して、別のものはaを使用するかもしれませんが、「名前」のバージョン1.1の参照を示すために、「同じように示す1.1インチという名前」としてそのようなものを区分してください。 パラメータの型は体系特有の意味論によって定義されるかもしれませんが、多くの場合、パラメタの構文はURIの「反-参照をつけ」アルゴリズムの実装に特定です。
3.4. Query
3.4. 質問
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.
質問コンポーネントは経路コンポーネント(セクション3.3)におけるデータと共にURIの体系の範囲の中でリソースを特定するのに役立つ非階層データと(もしあれば)の命名権威を含んでいます。 質問コンポーネントは、ナンバー記号(「#」)キャラクタかURIの終わりまでに最初の疑問符(“?")キャラクタによって示されて、終えられます。
Berners-Lee, et al. Standards Track [Page 23] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[23ページ]。
query = *( pchar / "/" / "?" )
質問=*「(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.
キャラクタスラッシュ(「/」)と疑問符(“?")は質問コンポーネントの中にデータを表すかもしれません。 それが相対参照(セクション5.1)にベースURIとして使用されるとき、いくつかの、より古くて、誤った実装が正しくそのようなデータを扱わないかもしれないのに注意してください、階層的な分離符を探すとき、彼らが経路データと質問データを明らかに区別しないので。 しかしながら、質問コンポーネントが運ぶのに「主要な=値」組の形で情報を特定しながらしばしば使用されて、1つの頻繁に使用された値が別のURIの参照であるので、ユーザビリティは時々それらのキャラクタをコード化するパーセントを避けるほうがよいです。
3.5. Fragment
3.5. 断片
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 / "/" / "?" )
断片=*「(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).
独特のメディアタイプはそのメディアタイプがセカンダリリソースとして身元保証可能な異なったタイプの部分集合を指定するための部分識別子構文の中のそれら自身の制限か構造、視点、または外部参照を定義するかもしれません。 プライマリリソースに複数の表現があるなら、よくあるように、表現が検索要求(通称満足している交渉)の属性に基づいて選択されるリソースのために断片によって特定されることなら何でもそれらの表現のすべての向こう側に一貫しているべきです。 各表現が断片を定義するべきであるので、同じセカンダリリソースに対応しています、それが表されるべきであるか、またはどう未定義の状態で(すなわち、見つけられません)断片を残すべきであるかにかかわらず。
Berners-Lee, et al. Standards Track [Page 24] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[24ページ]。
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).
キャラクタスラッシュ(「/」)と疑問符(“?")は部分識別子の中にデータを表すことができます。 それが相対参照(セクション5.1)にベースURIとして使用されるとき、いくつかの、より古くて、誤った実装が正しくこのデータを扱わないかもしれないのに注意してください。
4. Usage
4. 用法
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に制限します。 私たちは、影響を与えるので、この仕様に基づき最も一般的なフォームの参照構文を定義して、ジェネリック構文のデザインを当てにします、一貫して解釈されるために一定の構文解析アルゴリズムを必要として。
4.1. URI Reference
4.1. URI参照
URI-reference is used to denote the most common usage of a resource identifier.
URI参照は、リソース識別子の最も一般的な用法を指示するのに使用されます。
URI-reference = URI / relative-ref
URI参照は相対的なURI/審判と等しいです。
Berners-Lee, et al. Standards Track [Page 25] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[25ページ]。
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参照パーサの例に関してAppendix Bを見るべきです。
4.2. Relative Reference
4.2. 相対参照
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.
相対参照は、別の階層的なURIの名前スペースに比例してURI参照を言い表すのに、階層的な構文(セクション1.2.3)を利用します。
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
相対的な審判は相対的な部分[“?"質問]と等しいです。[「#」断片]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
経路経路「相対的な部分は」 //と等しい」という権威経路-abempty/絶対の/経路-noscheme/空です。
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.
セクション5の参照解決アルゴリズムを適用することによって、相対参照で言及されたまた、目標URIとして知られているURIを得ます。
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.
相対パス参照の最初のセグメントとしてコロンキャラクタ(例えば、「これ: それ」)を含む経路セグメントは使用できません、それが体系名に間違えられるだろうというとき。 「ドットセグメントがそのようなセグメントに先行しなければならない、(」 . 例えば、/、これ: それ、」、)、親類経路参照をするために。
Berners-Lee, et al. Standards Track [Page 26] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[26ページ]。
4.3. Absolute URI
4.3. 絶対URI
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を定義すると、断片を許容しない絶対URIシンタックス・ルールは求められます。
absolute-URI = scheme ":" hier-part [ "?" query ]
「絶対URI=体系」:、」 hier-部分[“?"質問]
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体系仕様は、また、それらの体系特有の構文に合っているすべてのストリングが<の絶対URIの>文法に合うように、それら自身の構文を定義しなければなりません。体系仕様は部分識別子構文か用法を定義しないでしょう、その体系を通して身元保証可能なリソースへの適用性にかかわらず、断片識別が定義を計画するために直交しているとき。 しかしながら、体系仕様がさまざまな例を含んでいるよう奨励されます、そのような用法がいつ適切であるかを部分識別子がある体系のURIの使用に示す例を含んでいて。
4.4. Same-Document Reference
4.4. 同じドキュメント参照
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(セクション5.1)と同じ状態で断片の部品(もしあれば)は別としてあるURIについて言及するとき、その参照は「同じドキュメント」参照と呼ばれます。 同じドキュメント参照の最も頻繁な例は空であるか、または部分識別子があとに続いたナンバー記号(「#」)分離符だけを含んでいる相対参照です。
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がそうすると仮定するべきでない、()、同じドキュメント参照として、あらゆる与えられたアプリケーションで、解釈されてくださいだろう。
4.5. Suffix Reference
4.5. 接尾語参照
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構文はリソースと伸展性の明白な参照のためにURI体系で設計されています。 しかしながら、URIとして、識別と用法は平凡になりました、(テレビ、ラジオ、新聞、掲示板など)がますます接尾語を使用した伝統的なメディア
Berners-Lee, et al. Standards Track [Page 27] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[27ページ]。
URI as a reference, consisting of only the authority and path portions of the URI, such as
URIと、そのようなものとしての権威と経路部分だけから成る参照としてのURI
www.w3.org/Addressing/
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が全くない場所に制限されます、ダイアログボックスやオフライン広告のように。
5. Reference Resolution
5. 参照解決
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>シンタックス・ルールに合っているストリングです。
5.1. Establishing a Base URI
5.1. 基地の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」が存在するのを含意します。 ベースURIが知られているときだけ、断片だけ参照(セクション4.4)は別として、相対参照は使用可能です。 相対的であるかもしれない構文解析URI参照の前にパーサでベースURIを確立しなければなりません。 ベースURIは<の絶対URIの>シンタックス・ルール(セクション4.3)に従わなければなりません。 URI参照からベースURIを得るなら、その参照は、ベースURIとして絶対フォームに変換して、使用の前にどんな断片の部品も奪い取らなければなりません。
Berners-Lee, et al. Standards Track [Page 28] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[28ページ]。
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:
以下で先任順に議論した4つの方法の1つで参照のベースURIを確立できます。 層で先行の注文を考えることができます。そこでは、最も奥深い定義されたベース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) |
`----------------------------------------------------------'
.----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | .----------------------------------. | | | | | | | | | <相対参照>。| | | | | | | | | `----------------------------------' | | | | | | | | (5.1.1) 内容に埋め込まれた基地のURI| | | | | | | `----------------------------------------' | | | | | | (5.1.2) 要約実体の基地のURI| | | | | | (メッセージ、表現、またはなにも) | | | | | `----------------------------------------------' | | | | (5.1.3) URIは以前はよく実体を検索していました。| | | `----------------------------------------------------' | | (5.1.4) デフォルト基地のURI(アプリケーション依存する)| `----------------------------------------------------------'
5.1.1. Base URI Embedded in Content
5.1.1. 内容に埋め込まれた基地のURI
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を埋め込むことができるかを指定するためにこの仕様の範囲を超えています。 利用可能であるときに、適切な構文はそれぞれのメディアタイプに関連しているデータの形式仕様で説明されます。
5.1.2. Base URI from the Encapsulating Entity
5.1.2. 要約実体からの基地の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です。
Berners-Lee, et al. Standards Track [Page 29] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[29ページ]。
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をメッセージの一部と定義するためのそれら自身の構文を定義するかもしれません。
5.1.3. Base URI from the Retrieval URI
5.1.3. 検索URIからの基地の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であることに注意してください。
5.1.4. Default Base URI
5.1.4. デフォルト基地の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はアプリケーションの文脈によって定義されます。 この定義が必ずアプリケーション依存しているとき、他の方法の1つを使用することによってベース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がよく定義される状況で相対参照を確かに使用できるだけです。
5.2. Relative Resolution
5.2. 相対的な解決
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参照を変換するためのアルゴリズムを説明します。 そして、目標URIを形成するためにセクション5.3で説明されるようにコンポーネントを作り直すことができます。 このアルゴリズムは他の実現の出力をテストするのに使用できる決定的な結果を提供します。 アプリケーションはある他のアルゴリズムを使用することによって、相対参照解決を実行するかもしれません、結果がこれによって与えられるものに合っていれば。
Berners-Lee, et al. Standards Track [Page 30] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[30ページ]。
5.2.1. Pre-parse the Base URI
5.2.1. 基地のURIをあらかじめ分析してください。
The base URI (Base) is established according to the procedure of Section 5.1 and parsed into the five main components described in Section 3. Note that only the scheme component is required to be present in a base URI; the other components may be empty or undefined. A component is undefined if its associated delimiter does not appear in the URI reference; the path component is never undefined, though it may be empty.
ベースURI(基地)は、セクション5.1の手順によって設立されて、セクション3で説明された5つの主なコンポーネントに分析されます。 計画コンポーネントだけをベースURIで存在させているのが必要であることに注意してください。 他のコンポーネントは、空であるか、または未定義であるかもしれません。 関連デリミタがURI参照に現れないなら、コンポーネントは未定義です。 それは空であるかもしれませんが、経路コンポーネントは決して未定義ではありません。
Normalization of the base URI, as described in Sections 6.2.2 and 6.2.3, is optional. A URI reference must be transformed to its target URI before it can be normalized.
ベースURIの正常化は、セクション6.2.2と6.2で.3について説明するので、任意です。 それを正常にすることができる前にURI参照を目標URIに変えなければなりません。
5.2.2. Transform References
5.2.2. 参照を変えてください。
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.計画、R.権威、R.経路、R.質問、R.は断片化します)=は(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;
-- それがベースURIの計画と同じであるなら、非厳しいパーサは参照で計画を無視するかもしれません。 -- そして、(厳しくない)、(R.計画=Base.scheme)) 当時のundefine(R.計画)。 endif。
Berners-Lee, et al. Standards Track [Page 31] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[31ページ]。
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;
定義されるなら(R.計画)、T.計画はR.計画と等しいです。 T.権威はR.権威と等しいです。 T.経路=は_ドット_セグメント(R.経路)を取り除きます。 T. =R.質問を質問してください。 ほかに、定義されるなら(R.権威)、T.権威はR.権威と等しいです。 T.経路=は_ドット_セグメント(R.経路)を取り除きます。 T. =R.質問を質問してください。 ほか、(R.経路=、「「)、次に、T.経路=Base.path;、」 定義されるなら(R.質問)、T.質問はR.質問と等しいです。 ほかのT.質問はBase.queryと等しいです。 endif。 「ほか、(R.経路が」 /から始まる、」、)、次に、T.経路=は_ドット_セグメント(R.経路)を取り除きます。 ほかのT.経路はマージ(Base.path、R.経路)と等しいです。 T.経路=は_ドット_セグメント(T.経路)を取り除きます。 endif。 T. =R.質問を質問してください。 endif。 T.権威はBase.authorityと等しいです。 endif。 T. =Base.schemeを計画してください。 endif。
T.fragment = R.fragment;
T. =R.断片を断片化してください。
5.2.3. Merge Paths
5.2.3. 経路を合併してください。
The pseudocode above refers to a "merge" routine for merging a relative-path reference with the path of the base URI. This is accomplished as follows:
上記の擬似コードはベースURIの経路に相対パス参照を合併するための「マージ」ルーチンを示します。 これは以下の通り達成されます:
o If the base URI has a defined authority component and an empty
path, then return a string consisting of "/" concatenated with the
reference's path; otherwise,
o 「ベースURIに定義された権威コンポーネントと人影のない経路があるなら、」 /のaストリングの成ることを返してください」、参照の経路で、連結されます。 そうでなければ
Berners-Lee, et al. Standards Track [Page 32] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[32ページ]。
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経路がそれであるならいずれも含んでいない、」 /、」、キャラクタ)
5.2.4. Remove Dot Segments
5.2.4. ドットセグメントを取り除いてください。
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.
「また、擬似コードは特別番組を解釈して、取り除くための「_ドット_セグメントを取り除いてください」というルーチンを示します」。. 」 」 . . 」 完全な経路は参照をつけられた経路から区分します。 参照から経路を抽出した後にこれをします、経路が相対的であったか否かに関係なく、目標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. 最終的に、結果として出力バッファを返す、_ドット_セグメントを取り除いてください。
Berners-Lee, et al. Standards Track [Page 33] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[33ページ]。
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における、名前の階層構造に比例して識別子を言い表すことを意図することに注意してください。 _誤りとしてそれらを扱うよりむしろ余分なドットセグメントを取り除くか、またはそれらが反参照実現で誤解されるのを残して、アルゴリズムがその階層構造を尊敬するドット_セグメントを取り除いてください。
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
1 : /a/b/c//。/../g2E: /a /b/c//。/../g2E: /a/b /c//。/../g2E: /a/b/c //。/../g2B: /a/b/c /。/../g2C: /a/b /。/g2C: /a /g2E: /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
1 : 中間の、または、満足している=5/。/6 2E: 中間の、または、満足している=5/。/6 2E: 中間の、または、満足している=5/。/6 2C: 中間の/6 2E: 中間の/6
Some applications may find it more efficient to implement the remove_dot_segments algorithm by using two segment stacks rather than strings.
いくつかのアプリケーションが、それが実行するために、より効率的であることがわかるかもしれない、ストリングよりむしろ2つのセグメントスタックを使用することによって、_ドット_セグメントアルゴリズムを取り除いてください。
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 "/./".
以下に注意してください。 「ベースと参照経路を合併する前にいくつかの、より古くて、誤った実現が経路コンポーネントと参照の質問コンポーネントを切り離さないのに注意してください、質問コンポーネントがストリングを含んでいるなら相互運用性失敗をもたらして」/。」 /「/」か/、」
Berners-Lee, et al. Standards Track [Page 34] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[34ページ]。
5.3. Component Recomposition
5.3. コンポーネントRecomposition
Parsed URI components can be recomposed to obtain the corresponding URI reference string. Using pseudocode, this would be:
対応するURI参照ストリングを入手するために分析されたURIコンポーネントを作り直すことができます。 擬似コードを使用して、これは以下の通りでしょう。
result = ""
結果が等しい、「」
if defined(scheme) then
append scheme to result;
append ":" to result;
endif;
定義されるなら(計画します)、なるように計画を追加してください。 「追加する」:、」 なるように。 endif。
if defined(authority) then
append "//" to result;
append authority to result;
endif;
結果への「定義されるなら(権威)、」 //を追加してください」。 なる権威を追加してください。 endif。
append path to result;
なるように経路を追加してください。
if defined(query) then
append "?" to result;
append query to result;
endif;
定義されるなら(質問します)、なるように“?"を追加してください。 なるように質問を追加してください。 endif。
if defined(fragment) then
append "#" to result;
append fragment to result;
endif;
定義されるなら(断片化します)、なるように「#」を追加してください。 なるように断片を追加してください。 endif。
return result;
結果を返してください。
Note that we are careful to preserve the distinction between a component that is undefined, meaning that its separator was not present in the reference, and a component that is empty, meaning that the separator was present and was immediately followed by the next component separator or the end of the reference.
私たちが分離符が参照に存在していなかったことを意味して、未定義のコンポーネントと、空のコンポーネントの区別を保存するのに慎重であることに注意してください、分離符が存在していて、すぐに次のコンポーネント分離符か参照の終わりまでに従われたことを意味して。
5.4. Reference Resolution Examples
5.4. 参照解決の例
Within a representation with a well defined base URI of
aとの表現で井戸がベースURIを定義した以内
http://a/b/c/d;p?q
http://a/b/c/d;p?q
a relative reference is transformed to its target URI as follows.
相対参照は以下の目標URIに変えられます。
Berners-Lee, et al. Standards Track [Page 35] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[35ページ]。
5.4.1. Normal Examples
5.4.1. 正常な例
"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"
等しい..等しい..等しい = 」 「" 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 "と等しいです。
5.4.2. Abnormal Examples
5.4.2. 異常な例
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.
「パーサは」 . . 」 a相対パス参照における階層レベルがベースユリの経路にあるより多くのセグメントがある取り扱い場合で慎重であるに違いありません。 「それに注意してください、」 . . 」 aユリの権威コンポーネントを変えるのに構文を使用できません。
"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"
"../../..「/g」は" http://a/g "と等しいです。」/../../..「/g」は" http://a/g "と等しいです。
Berners-Lee, et al. Standards Track [Page 36] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[36ページ]。
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"
「「//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"
"./... 「/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"
「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
「http: g」は「http: g」と等しいです。 厳しいパーサ/" http://a/b/c/g "のために。 後方の互換性のために
Berners-Lee, et al. Standards Track [Page 37] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[37ページ]。
6. Normalization and Comparison
6. 正常化と比較
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つは簡単な比較です: 2つのURIがそれらのそれぞれのリソースにアクセスするのに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比較は何らかの特定の目的のために実行されます。 どのくらいの努力がaliased識別子を減らすのに費やされるべきであるかに関して異なる役割のためにURIを比較するプロトコルか実現がしばしば異なったデザイントレードオフを受けることがあるでしょう。 このセクションはそれらの間でURI、トレードオフを比較するのに使用されるかもしれない、様々な方法、およびそれらを使用するかもしれないアプリケーションのタイプについて説明します。
6.1. Equivalence
6.1. 等価性
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が選択するために比較される時、(避ける、)、表現の検索などのネットワーク動作、(もしあれば)の断片の部品は比較から除かれるべきです。
Berners-Lee, et al. Standards Track [Page 38] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[38ページ]。
6.2. Comparison Ladder
6.2. 比較はしご
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.
この範囲の比較練習がはしごであるとみなされると、以下の議論は出世階段を昇るでしょう、安いのですが、有病誤診を作り出すという比較的高い機会を持っている習慣から始めて、より高いコンピュータの費用と有病誤診の下側のリスクを持っているものに続いて。
6.2.1. Simple String Comparison
6.2.1. 簡単なストリング比較
If two URIs, when considered as character strings, are identical, then it is safe to conclude that they are equivalent. This type of equivalence test has very low computational cost and is in wide use in a variety of applications, particularly in the domain of parsing.
文字列であるとみなされると2つのURIが同じであるなら、それらが同等であると結論を下すのは安全です。 このタイプの等価性テストは、非常に低いコンピュータの費用を持って、さまざまなアプリケーションで広く使用中です、特に構文解析のドメインで。
Testing strings for equivalence requires some basic precautions. This procedure is often referred to as "bit-for-bit" or "byte-for-byte" comparison, which is potentially misleading. Testing strings for equality is normally based on pair comparison of the characters that make up the strings, starting from the first and proceeding until both strings are exhausted and all characters are found to be equal, until a pair of characters compares unequal, or until one of the strings is exhausted before the other.
等価性がないかどうかストリングをテストするのはいくつかの基本的な事前注意事項を必要とします。 この手順はしばしば「ビットビット」か「バイトバイト」比較と呼ばれます。(それは、潜在的に紛らわしいです)。 通常、平等がないかどうかストリングをテストするのはストリングを作るキャラクタの組比較に基づいています、1番目から始めて、両方のストリングが疲れ果てていて、すべてのキャラクタが等しいのがわかるまで続いて、1組のキャラクタが不平等な状態で比較するか、またはストリングの1つがもう片方の前に消耗するまで。
This character comparison requires that each pair of characters be put in comparable form. For example, should one URI be stored in a byte array in EBCDIC encoding and the second in a Java String object (UTF-16), bit-for-bit comparisons applied naively will produce errors. It is better to speak of equality on a character-for- character basis rather than on a byte-for-byte or bit-for-bit basis. In practical terms, character-by-character comparisons should be done codepoint-by-codepoint after conversion to a common character encoding.
このキャラクタ比較は、キャラクタの各組が匹敵するフォームに入れられるのを必要とします。 例えば、1つのURIがJava String物(UTF-16)にEBCDICコード化と2番目にバイトアレイに格納されると、ビット比較のための適用されたビットは誤りを純真に起こすでしょう。 キャラクタの上で平等について話すほうがよい、-、バイトバイトかビットビットベースでというよりむしろキャラクタ基礎のために。 実際的な言い方をするなら、キャラクタごとの比較に変換の後に一般的なキャラクタへのcodepointごとにコード化するべきであること。
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参照を中に提供することによって既に正規形(すなわち、正常化が適用されていた後に以下で説明されるように生産されることと同じフォーム)。
Berners-Lee, et al. Standards Track [Page 39] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[39ページ]。
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参照を提供する際に一貫しているか、または少なくとも一貫するという理論に基づいて。
6.2.2. Syntax-Based Normalization
6.2.2. 構文ベースの正常化
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
7D例://a/例://a/b/c/%7Bfoo%/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.
キャッシュされた応答が利用可能であるかどうか決定するとき、ブラウザなどのウェブユーザーエージェントはこのタイプのURI正常化を通常適用します。 構文ベースの正常化はドットセグメントの正常化、パーセントをコード化する正常化、および取り外しをケースに入れるようなテクニックを含んでいます。
6.2.2.1. Case Normalization
6.2.2.1. ケース正常化
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がジェネリック構文の成分を使用すると、コンポーネント構文等価性規則はいつも適用されます。 すなわち、体系とホストに大文字と小文字を区別しなく、したがって、正常にされるべきであるのは小文字で印刷します。 例えば、ユリ<HTTP://www.EXAMPLE.com/>は<http://www.example.com/>に同等です。別の方法で体系によって明確に定義されない場合、他のジェネリック構文コンポーネントが大文字と小文字を区別していると思われます(セクション6.2.3を見てください)。
6.2.2.2. Percent-Encoding Normalization
6.2.2.2. パーセントをコード化する正常化
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で説明されるように。
Berners-Lee, et al. Standards Track [Page 40] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[40ページ]。
6.2.2.3. Path Segment Normalization
6.2.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に説明されるように_ドット_セグメントアルゴリズムを経路に移してください。
6.2.3. Scheme-Based Normalization
6.2.3. 体系ベースの正常化
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:
URIの構文と意味論は体系によって通りに各体系のための定義仕様で説明されるように異なります。 実装は、有病誤診の確率を減少させるのにさらなる加工費に体系特有の規則を使用するかもしれません。 「例えば、"http"体系が権威コンポーネントを利用するのでデフォルトポートを持っている、「80インチ、」 /に相当しているように人影のない経路を定義する、」、以下の4つのURIが同等です:
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
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は」 /の経路に正常にされるべきです。」 そして、「同様である、明白である、」 : ポート、」、ポートがどれであるかが空になるか、または体系のためのデフォルトが1つに同等である、どこ、ポート、それ、」、:、」 デリミタを削除して、その結果、体系ベースの正常化で取り除くべきです。 例えば、上の第2URIは"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
体系でそうするために認可されない場合それらの関連コンポーネントが空であるときに、正常化はデリミタを取り除くべきではありません。
Berners-Lee, et al. Standards Track [Page 41] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[41ページ]。
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.
他の体系特有の正常化は可能です。
6.2.4. Protocol-Based Normalization
6.2.4. プロトコルベースの正常化
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
ウェブクモにとって、有病誤診の発生を減少させるかなりの取り組みがしばしば費用対効果に優れています。 したがって、彼らはURI比較におけるさらに攻撃的なテクニックを実装します。 例えば、彼らはそのa URIを観測します。
http://example.com/data
http://example.com/data
redirects to a URI differing only in the trailing slash
引きずっているスラッシュだけにおける相違をURIに向け直します。
http://example.com/data/
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発生源サーバによるリダイレクションの使用)によって等価性が明確に示されるときだけ、この種類のテクニックは適切です。
Berners-Lee, et al. Standards Track [Page 42] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[42ページ]。
7. Security Considerations
7. セキュリティ問題
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がネットワーク資源へのアクセスのための1つのコンパクト集合の指示を提供するのにおいてしばしば使用されているので、URIの中で適切にデータを解釈して、そのデータが故意でないアクセスを引き起こすのを防いで、プレーンテキストで明らかにされるべきでないデータを含んでいるのを避けるために注意しなければなりません。
7.1. Reliability and Consistency
7.1. 信頼性と一貫性
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体系は追加意味論を定義するかもしれません、名前固執などのように、すべての命名当局がその体系のためにそれらの意味論に要求されるなら。
7.2. Malicious Construction
7.2. 悪意がある工事
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の中のデータはこの他のプロトコルによると、解釈されると予期していなかった操作を引き起こす指示を含んでいます。 そのような乱用の頻繁な例は「その結果ユーザエージェントソフトウェアがSMTPサーバーで故意でないかまねメッセージを送るようにだます25インチ」のポートの部品があるプロトコルベースの体系の使用です。
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がプロトコルと互換性があるということであるプロトコルがそれでウェルノウンポートを予想しなかったなら「ウェルノウンポート」範囲(0--1023)の中でTCPポートナンバーを指定するURIの反参照を防ぐべきです。 IANAはウェルノウンポートの登録を維持しますが、アプリケーションで、そのような制限は新種業務の展開を防ぐのを避けるのにおいてユーザ構成可能になるべきです。
Berners-Lee, et al. Standards Track [Page 43] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[43ページ]。
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キャラクタは議定書を作ります)、トランスミッションの前にそのプロトコルの向こう側にこれらのパーセントencodingsを解読してはいけません。 プロトコルに違反するかもしれないパーセントコード化の転送は許容が兼業かパラメタとして解釈されるために八重奏を解読したほど有害ではありません、恐らく予期していなくてことによると有害なリモート操作の引き金となって。
7.3. Back-End Transcoding
7.3. バックエンドコード変換
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では、例えば、典型的なユーザエージェントは、権威、経路、および質問コンポーネントの中で5個の主要コンポーネントにURIを分析して、権威のサーバにアクセスして、データをそれに送るでしょう。 典型的なサーバは、その情報を取って、キー/値の組にセグメントへの経路と質問を分析して、次に、要求に応じるために実装特有の操作者を呼び出すでしょう。 その結果、別々のコンポーネントへの全体か分裂としてURIを扱うサーバ実装に関する共通の安全保障心配はそのURIの中にキャラクタとパーセントencodingsによって表された八重奏データの適切な解釈です。
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の中のデータのセキュリティチェックは適用されるべきです。 「しかしながら、それに注意してください、」 アプリケーションが、コンポーネントの中に生データを受け取ると予想していないなら、%0インチのパーセントコード化(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経路解釈プロセスがバックエンドファイルシステムか関連系機能の使用にかかわると、特別な注意は払われるべきです。 「ファイルシステムは操作上の意味を特殊文字に通常割り当てます、あれほど、」 /、」、「\」、」、:、」、「[「」、]、」 キャラクタ、特別な装置名に好きである、」、」、」、」, "...", 「補助」、"lpt"など いくつかの場合、そのような名前の存在がないかどうか単にテストするのは、オペレーティングシステムが関係ないシステムコールをポーズするか、または呼び出すことを引き起こすでしょう、サービスと故意でないデータ転送の否定に関して重要な安全上の配慮に通じて。 この仕様がそのようなすべての重要なキャラクタと装置名を記載するのは、不可能でしょう。 Implementersは彼らのアプリケーションに取り付けられるかもしれない記憶装置のタイプのために予約された名前とキャラクタについて研究して、URIコンポーネントからそれに従って、得られたデータの使用を制限するはずです。
Berners-Lee, et al. Standards Track [Page 44] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[44ページ]。
7.4. Rare IP Address Formats
7.4. まれなIPアドレス形式
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構文は一般的なドット付き10進法フォームのIPv4アドレスリテラルを許容するだけですが、URIを処理する多くの実装が、実際のIPアドレスに文字列リテラルを翻訳するのにgethostbyname()やinet_aton()などのプラットホーム依存するシステムルーチンを利用します。 残念ながら、そのようなシステムルーチンは、しばしばセクション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つの番号(例えば、Class Bネットワーク)の点を打たされたフォームを許容します。(最後の部分は、16ビットの量として解釈されて番号でネットワーク・アドレスの最も権利2バイトに置かれます)。 同様に、2つの番号の点を打たされたフォームは、最後の部分が24ビットの量として解釈されてネットワーク・アドレス(クラスA)の最も権利3バイトに置かれて、1つの数(ドットのない)が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アドレスに基づくリソースへのアクセスをフィルターにかけるのを試みるなら、それらはセキュリティ関心になることができます。 このフィルタリングが実行されるなら、リテラルは、数値フォームに変換されて、ストリングフォームの接頭語か接尾語ではなく、数値に基づいてフィルターにかけられるべきです。
7.5. Sensitive Information
7.5. 機密情報
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の部品の中に現れるパスワードは、推奨しなく、'パスワード'パラメタが公共であることを意図するそれらのまれなケース中以外の誤り(または、単に無視される)であると考えられるべきです。
7.6. Semantic Attacks
7.6. 意味攻撃
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サブコンポーネントが権威コンポーネントにめったに使用されないで、ホストの前に現れるので、実際に雑音の後ろに隠された異なった権威を特定している間、権威を命名しながら1つ(信じられる)を特定するように見えることによって人間のユーザをミスリードすることを意図するURIを構成するのにそれを使用できます。 例えば
Berners-Lee, et al. Standards Track [Page 45] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[45ページ]。
ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm
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の意味に関するユーザの先入観に対する攻撃です。 ユーザエージェントがそれらがレンダリングされるときURIの様々なコンポーネントを区別することによってそのような攻撃の影響を減少させることができるかもしれない、そのようなものはもしあればuserinfoをレンダリングするのに異なった色かトーンを使用するように存在しています、万能薬が全くありませんが。 [Siedzik]でURIベースの意味攻撃に関する詳しい情報を見つけることができます。
8. IANA Considerations
8. IANA問題
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で<体系>によって定義されるURI体系名は[BCP35]で定義された手順によると、IANAによって管理される登録された名前空間を形成します。 IANA動作は全くこのドキュメントによって必要とされません。
9. Acknowledgements
9. 承認
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.
RFC2396[RFC2396]、RFC1808[RFC1808]、およびRFC1738[RFC1738]からこの仕様を得ます。 それらのドキュメントにおける承認はまだ適用されています。 また、それはIPv6リテラルのためにホスト構文にアップデートを取り入れます(修正で)、[RFC2732]でロバートM.Hinden、ブライアンE.Carpenter、およびラリーMasinterによって定義されるように。 追加、Gisle Aasによる貢献、リーズAnschultz、ダニエル・バークレー、ティムBray、マイク・ブラウン、ロブキャメロン、ジェレミー・キャロル、ダン・コノリー、アダム・M.コステロ、ジョン・カウァン、ジェイソンDiamond、マーチンDuerst、ステファンEissing、クライヴD.W.Feather、アル・ギルマン、トニー・ハモンド、Elliotteハロルド、パット・ヘイズ、ヘンリー・ホルツマン、イアン・B.ジェイコブズ、マイケル・ケイ、ジョンCで; Klensin、グラハムKlyne、ダン・コーン、ブルース・リリー、アンドリューMain、デーヴMcAlpin、イラ・マクドナルド、マイケルMealling、レイMerkert、スティーブンPollei、ジュリアンReschke、トマスRokicki、Milesセービン、カイSchaetzl、マーク・トムソン、ロナルドTschalaer、Normウォルシュ、マーク・ウォーン、スチュアート・ウィリアムズ、およびヘンリーZongaroは感謝して承認されます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[ASCII]American National Standards Institut、「7コード化文字集合--ビット、情報交換用米国標準コード、」、ANSI X3.4、1986
Berners-Lee, et al. Standards Track [Page 46] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[46ページ]。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[STD63] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[STD63]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[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月。
10.2. Informative References
10.2. 有益な参照
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[BCP19]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[BCP35] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[BCP35]Petke、R.とI.キング、「URL体系名のための登録手順」BCP35、1999年11月のRFC2717。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC0952] HarrenstienとK.とスタール、M.とE.Feinler、「DoDインターネット・ホストテーブル仕様」、RFC952、1985年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535,
October 1993.
[RFC1535] Gavronと、E.と、「広く配布しているDNSソフトウェアとの警備上の問題と提案された修正」、RFC1535、10月1993日
[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]バーナーズ・リー、T.、「WWWの普遍的なリソース識別子:」 「WWWに使用されるNetworkの上のObjectsのNamesとAddressesのExpressionのためのUnifying Syntax」、RFC1630(1994年6月)
[RFC1736] Kunze, J., "Functional Recommendations for Internet
Resource Locators", RFC 1736, February 1995.
[RFC1736] クンツェ、J.、「インターネット資料ロケータのための機能的な推薦」、RFC1736、1995年2月。
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC1737] SollinsとK.とL.Masinter、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995.
[RFC1808] フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、1995年6月。
Berners-Lee, et al. Standards Track [Page 47] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[47ページ]。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、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.、ホワイトヘッド、E.、Faizi、A.、カーター、S.、およびD.ジェンセン、「分配されたオーサリングのためのHTTP拡大--、WEBDAV、」、RFC2518(1999年2月)
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999.
[RFC2557]パルメとJ.とHopmann、A.とN.シェル、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
1999年11月の[RFC2718]MasinterとL.とAlvestrandとH.とZigmond、D.とR.Petke、「新しいURL Schemesのためのガイドライン」RFC2718。
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2732] Hinden、R.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、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] 食事、M.、およびR.Denenbergは「共同W3C/IETF URI計画営利団体から以下を報告します」。 Uniform Resource Identifier(URI)、URL、および一定のリソース名(つぼ): 「明確化と推薦」、RFC3305、8月2002日
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、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/実用的な/gsec/リチャード_Siedzik_GSEC.pdf>。
Berners-Lee, et al. Standards Track [Page 48] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格はURIジェネリック構文2005年1月にRFC3986を追跡します[48ページ]。
Appendix A. Collected ABNF for URI
付録A.はURIのためにABNFを集めました。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
「URI=体系」:、」 hier-部分[“?"質問][「#」断片]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
経路絶対か経路根のないか経路権威経路-abempty/空の「hier-部分=」//
URI-reference = URI / relative-ref
URI参照は相対的なURI/審判と等しいです。
absolute-URI = scheme ":" hier-part [ "?" query ]
「絶対URI=体系」:、」 hier-部分[“?"質問]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
相対的な審判は相対的な部分[“?"質問]と等しいです。[「#」断片]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
経路経路「相対的な部分は」 //と等しい」という権威経路-abempty/絶対の/経路-noscheme/空です。
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
体系=アルファー*「(アルファ/ケタ/「+」/「-」/、」、」、)
authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT
「権威=[userinfo"@"]ホスト[「:」 ポート]userinfoが*と等しい、(無遠慮であるかpctによってコード化されたかサブdelimsの/、」、:、」、)、レッジホスト=IP-リテラル/IPv4address/名のポート=*ケタ
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
「[「(IPv6address / IPvFuture)」]」というIP-リテラル=
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
「IPvFutureは「v」1*HEXDIG」と等しいです。」 1*「(無遠慮であるかサブ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 ] "::"
「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
「h16が1*4HEXDIG ls32=と等しい、(h16、」 : 」 h16) /IPv4address IPv4addressがDEC社八重奏と等しい、」 . 」 DEC社八重奏、」 . 」 DEC社八重奏、」 . 」 DEC社八重奏
Berners-Lee, et al. Standards Track [Page 49] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[49ページ]。
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
DEC社八重奏はDIGITと等しいです。 0-9/%x31-39ケタ。 10-99/「1インチの2DIGIT」。 100-199/、「2インチの%x30-34、ケタ、」、。 200-249/「25インチの%x30-35」。 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
reg-名前=*(無遠慮であるかpctによってコード化されるかサブ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
経路は経路-abemptyと等しいです。 「」 /で、始まる」か、空であるか、または経路絶対です。 」 //」 /経路-noschemeだけを「」 /で、始まりません」。 非コロンで、経路セグメント/根がない状態で、始まります。 セグメント/が経路空の状態で始まります。 キャラクタがありません。
path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar>
「経路-abemptyは*(「/」セグメント)経路絶対の=と等しく」/」 [セグメント-nz*(「/」セグメント)]経路-noschemeはセグメント-nz-nc*(「/」セグメント)経路根のない=セグメント-nz*(「/」セグメント)経路空の=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セグメント-nzは1*pcharセグメント-nz-nc=1*と等しいです(無遠慮であるかpctによってコード化されたかサブdelimsの/"@")。 「少しもコロンのない非ゼロ・レングスセグメント」:、」
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
「=無遠慮であるかpctによってコード化されたかサブdelimsのpchar/」:、」 / "@"
query = *( pchar / "/" / "?" )
質問=*「(pchar/」 /」 /“?")
fragment = *( pchar / "/" / "?" )
断片=*「(pchar/」 /」 /“?")
pct-encoded = "%" HEXDIG HEXDIG
pctによってコード化された=「%」HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
「無遠慮な=アルファー/ DIGIT /「-」/」、」 「/"_"/「~」はdelimsに情報を得ている=delimsに情報を得ているか、サブdelimsの=を予約した」:、」 / "/" / "?" /「#」/「[「/」]」/"@"サブdelimsは“!"と等しいです。 / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
Appendix B. Parsing a URI Reference with a Regular Expression
正規表現とのURI参照を分析する付録B.
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参照をコンポーネントに分解するための正規表現です。
Berners-Lee, et al. Standards Track [Page 50] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[50ページ]。
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12 3 4 5 6 7 8 9
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 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
上のセカンドラインにおける数は単に読み易さを補助することです。 彼らは各「副-表現」(すなわちそれぞれの対にされた挿入句)のために基準点を示します。 私たちは「副-表現」<n>のために$<n>として合わせられた値について言及します。 例えば、上式を合わせること。
http://www.ics.uci.edu/pub/ietf/uri/#Related
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
1ドルはhttpと等しいです: 未定義の>=#関連9ドル8ドル=が関係づけた7ドルの2ドルの=http3ドル=<未定義の>=4//www.ics.uci.eduドルの=www.ics.uci.edu5ドル=/pub/ietf/uri/6ドル=<。
where <undefined> indicates that the component is not present, as is the case for the query component in the above example. Therefore, we can determine the value of the five components as
<未定義であるところで、>は、コンポーネントが存在していないのを示します、上記の例の質問コンポーネントのためのケースのように。 したがって、私たちは5つのコンポーネントの値を決定できます。
scheme = $2
authority = $4
path = $5
query = $7
fragment = $9
計画 = 2ドル権威 = 4ドル経路 = 5ドル質問 = 7ドル断片 = 9ドル
Going in the opposite direction, we can recreate a URI reference from its components by using the algorithm of Section 5.3.
逆コースを行って、私たちは、セクション5.3のアルゴリズムを使用することによって、コンポーネントからのURI参照を休養させることができます。
Appendix C. Delimiting a URI in Context
状況内においてURIを区切る付録C.
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/>さまざまな道、しかし、通常以内か空白を使用することだけで区切られます:
Berners-Lee, et al. Standards Track [Page 51] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[51ページ]。
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を壊すために加えられなければならないかもしれません。 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/パブ/ietf/ユリ/historical.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
Berners-Lee, et al. Standards Track [Page 52] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[52ページ]。
Appendix D. Changes from RFC 2396
RFC2396からの付録D.変化
D.1. Additions
D.1。 追加
An ABNF rule for URI has been introduced to correspond to one common usage of the term: an absolute URI with optional fragment.
用語の1つの一般的な語法に相当するようにURIのためのABNF規則を導入しました: 任意の断片がある絶対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]が残念ながら、IPv6addressのABNF記述を欠いているIPv6の文字通りのアドレスの定義のために[RFC3513]に従うので、私たちは[RFC3513]のセクション2.2によって定義されたテキスト表現に合っているIPv6addressのための新しい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 Technical Architecture Groupの中でティムBrayと議論から入力を使用することによって、完全に書き直されて、広げられました。
D.2. Modifications
D.2。 変更
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:
RFC2396の臨時のBNF構文を[RFC2234]のABNFに取り替えました。 この変化は、以前強調キャラクタを含んでいたすべての規則名が代わりにダッシュで改名されるのを必要としました。 さらに、多くのシンタックス・ルールが、総合的な文法をより分かりやすくするように排除されるか、または簡素化されました。 時代遅れの文法規則を示す仕様は以下のテーブルに応じてそれらの規則を置き換えるのに解釈されるかもしれません:
Berners-Lee, et al. Standards Track [Page 53] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[53ページ]。
+----------------+--------------------------------------------------+
| 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 |
+----------------+--------------------------------------------------+
+----------------+--------------------------------------------------+ | 時代遅れの規則| 翻訳| +----------------+--------------------------------------------------+ | absoluteURI| 絶対URI| | relativeURI| 相対的な部分[“?"質問]| | hier_部分| (「//」権威経路-abempty/| | | 経路絶対的なもの) [“?"質問]| | | | | 不透明な_部分| 経路根がありません[“?"質問]。| | ネットの_経路| 「//」権威経路-abempty| | 腹筋_経路| 経路絶対です。| | rel_経路| 経路根がありません。| | rel_セグメント| セグメント-nz-nc| | reg_名| reg-名前| | サーバ| 権威| | hostport| [「:」 ポート]を接待してください。| | ホスト名| reg-名前| | 経路_セグメント| 経路-abempty| | param| *「<pchar除外」; ">"| | | | | 尿| 「無遠慮な/はpctに/をコード化した」;、」 / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," / "/" | | | | | 尿の_いいえ_スラッシュ| 「無遠慮な/はpctに/をコード化した」;、」 / "?" / ":" | | | / "@" / "&" / "=" / "+" / "$" / "," | | | | | マーク| "-" / "_" / "." / "!" / "~" / "*" / "'" | | | / "(" / ")" | | | | | 逃げられます。| pctによってコード化されています。| | 十六進法| HEXDIG| | alphanum| アルファー/ケタ| +----------------+--------------------------------------------------+
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
セクション2はどんなキャラクタが控え目であるか、そして、彼らがいつ予約されているか、そして、彼らがなぜ予約されているかを説明するためにキャラクタの上で書き直されました、彼らがデリミタとして一般的な構文で使用さえされないとき。 そして、感嘆符(“!")を含んでいて、解読するのが通常危険なマークキャラクタは(「*」)に星をつけます、ただ一つの引用文である、(「'、「)、括弧を開いて、閉じてください、(「(「」、)、」、)、間に予約されていて無遠慮な状態で区別をはっきりさせるために予約されたセットに動かされてくださいといって、最も多くのコモンに答えるために、うまくいけば、計画デザイナーに質問してください、」、' 同様に、パーセントでコード化されたキャラクタの上のセクションを書き直しました、そして、現在、どんなパーセントでコード化された八重奏も解読するライセンスをURI正規化群に与えます。
Berners-Lee, et al. Standards Track [Page 54] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[54ページ]。
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.
無遠慮な性格に対応しています。 一般に、「逃げられ」て、"非エスケープ"であるという用語は、「パーセントでコード化される」と取り替えられて、他のフォームの逃避機制への混乱を抑えるためにそれぞれ「解読されました」。
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パーサにより好意的にして、複雑さを減少させるのが再設計されました。 その結果、構文記述のレイアウトフォームを取り除きました、尿の、そして、尿の_いいえ_スラッシュ、不透明な_部分、ネットの_経路、腹筋_経路、rel_経路、経路_セグメント、rel_セグメント、およびマーク規則と共に。 「不透明な」URIのすべての参照を経路コンポーネントがどう階層構造に不透明であるかもしれないかに関する、より良い記述に取り替えました。 それらがURIの部分集合であるかどうかに関してrelativeURI規則を避けるためには相対的な審判無用の混乱に取り替えました。 URIとしての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と相対的な審判規則の中でセクションに戻りました、絶対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は、経路コンポーネントが空であることを許容するために修正されました。 また、絶対URIがこれで現在のコネのような「計画してください」という習慣の後の無から成る、「dav:」 [RFC2518]と「以下」に関する名前空間 計画は多くのWWWブラウザ実現で内用しました。 権威と経路の間の境界に関するあいまいさは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に提供されて、応用層のそれらのネイティブのキャラクタencodingsでURI処理を超えて処理されて、登録名としてUTF-8キャラクタコード化でIDNAライブラリに向かわれるのを可能にするのに必要であるかをホストコンポーネントをパーセントでコード化された八重奏を含みます。 サーバ、hostport、ホスト名、domainlabel、toplabel、およびalphanum規則を取り外してあります。
The resolving relative references algorithm of [RFC2396] has been rewritten with pseudocode for this revision to improve clarity and fix the following issues:
この改正は、[RFC2396]の決議相対的な参照アルゴリズムは擬似コードで書き直されて、明快を改良して、以下の問題を修理しました:
Berners-Lee, et al. Standards Track [Page 55] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[55ページ]。
o [RFC2396] section 5.2, step 6a, failed to account for a base URI
with no path.
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 参照が人影のない経路と定義された質問コンポーネントを含んでいるなら、目標URIがベースURIの経路コンポーネントを引き継ぐ[RFC1808]の振舞いを復元しました。
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との比較に基づいています。 この仕様に基づく「同じドキュメント」であると考えられる場合、この変化はRFC2396で与えられた規則の下にあるだろうよりさらに多くの参照をもたらすかもしれません、特に正常化が別名を減少させるのに使用されるとき。 しかしながら、それは既存の同じドキュメント参照の状態を変えません。
o Separated the path merge routine into two routines: merge, for
describing combination of the base URI path with a relative-path
reference, and remove_dot_segments, for describing how to remove
the special "." and ".." segments from a composed path. The
remove_dot_segments algorithm is now applied to all URI reference
paths in order to match common implementations and to improve the
normalization of URIs in practice. This change only impacts the
parsing of abnormal references and same-scheme references wherein
the base URI has a non-hierarchical path.
o 経路マージルーチンを2つのルーチンに切り離します: 「ベースURI経路の組み合わせを相対パス参照に説明するために合併してください、そして、_ドット_セグメントを取り除いてください、特別番組を取り除く方法を説明するために」。. 」 」 . . 」 落ち着いた経路から、区分します。 取り外してください。_ドット_セグメントアルゴリズムは、現在、一般的な実現に合って、実際にはURIの正常化を改良するためにすべてのURI参照経路に適用されます。 この変化は異常な参照とベースURIが非階層的な経路を持っている同じ計画参照の構文解析に影響を与えるだけです。
Index
インデックス
A
ABNF 11
absolute 27
absolute-path 26
absolute-URI 27
access 9
authority 17, 18
絶対ABNF11の絶対URI27アクセス9 27絶対パス26権威17、18
B
base URI 28
BベースURI28
C
character encoding 4
character 4
characters 8, 11
coded character set 4
4キャラクタ4つのキャラクタ8、11コード化文字集合4をコード化するCキャラクタ
Berners-Lee, et al. Standards Track [Page 56] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[56ページ]。
D
dec-octet 20
dereference 9
dot-segments 23
D DEC社八重奏20反参照9ドットセグメント23
F
fragment 16, 24
F断片16、24
G
gen-delims 13
generic syntax 6
delimsに情報を得ているG13一般的な構文6
H
h16 20
hier-part 16
hierarchical 10
host 18
H h16 20 hier-部分の16の階層的な10ホスト18
I
identifier 5
IP-literal 19
IPv4 20
IPv4address 19, 20
IPv6 19
IPv6address 19, 20
IPvFuture 19
I識別子5のIP文字通りの19IPv4 20IPv4address19、20IPv6 19IPv6address19、20IPvFuture19
L
locator 7
ls32 20
Lロケータ7ls32 20
M
merge 32
Mは32を合併します。
N
name 7
network-path 26
N名前7ネットワーク経路26
P
path 16, 22, 26
path-abempty 22
path-absolute 22
path-empty 22
path-noscheme 22
path-rootless 22
path-abempty 16, 22, 26
path-absolute 16, 22, 26
path-empty 16, 22, 26
P経路16、22、26の経路絶対の22経路空の22 22経路根のない22経路-abempty経路-abempty22経路-noscheme16、22、26経路絶対的なもの16、22、26は16、22、26を経路で空にします。
Berners-Lee, et al. Standards Track [Page 57] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[57ページ]。
path-rootless 16, 22
pchar 23
pct-encoded 12
percent-encoding 12
port 22
パーセントをコード化する経路根のない16、22pchar23のpctによってコード化された12 12ポート22
Q
query 16, 23
Q質問16、23
R
reg-name 21
registered name 20
relative 10, 28
relative-path 26
relative-ref 26
remove_dot_segments 33
representation 9
reserved 12
resolution 9, 28
resource 5
retrieval 9
相対的なR予約された12解決9、28reg-名前21登録名20 10、28相対パス26が免職する26の相対的な審判_ドット_セグメント33表現9リソース5検索9
S
same-document 27
sameness 9
scheme 16, 17
segment 22, 23
segment-nz 23
segment-nz-nc 23
sub-delims 13
suffix 27
S同じドキュメント27同一性9計画16、17セグメント22、23セグメント-nz23セグメント-nz-nc23サブdelims13接尾語27
T
transcription 8
T転写8
U
uniform 4
unreserved 13
URI grammar
absolute-URI 27
ALPHA 11
authority 18
CR 11
dec-octet 20
DIGIT 11
DQUOTE 11
fragment 24
gen-delims 13
delimsに情報を得ている予約していないU27アルファー11権威18CR11DEC社八重奏20DIGIT11DQUOTE11ユニフォーム4 13URI文法絶対URI断片24 13
Berners-Lee, et al. Standards Track [Page 58] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[58ページ]。
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
h16 20 HEXDIG11hier-部分16が経路絶対の22が経路で空にする19IP文字通りの19IPv4address20のIPv6address20のIPvFuture19LF11ls32 20 OCTET11経路22経路-abempty22を接待する、22の経路-noschemeの22の経路根のない22pchar23のpctによってコード化された12ポート22が予約された24の17の23セグメント-nz23セグメント-nz-nc23SP11のサブdelimsの13の無遠慮な13セグメントURI16URI参照25userinfo18reg-名前21相対的な審判26 13計画URI16URI参照25URL7について質問する、URN7userinfo18
Berners-Lee, et al. Standards Track [Page 59] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[59ページ]。
Authors' Addresses
作者のアドレス
Tim Berners-Lee World Wide Web Consortium Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA
ケンブリッジ、ティム・バーナーズ・リーワールドワイドウェブコンソーシアムマサチューセッツ工科大学77MA02139米国マサチューセッツ通り
Phone: +1-617-253-5702 Fax: +1-617-258-5999 EMail: timbl@w3.org URI: http://www.w3.org/People/Berners-Lee/
以下に電話をしてください。 +1-617-253-5702 Fax: +1-617-258-5999 メールしてください: timbl@w3.org ユリ: http://www.w3.org/People/Berners-Lee/
Roy T. Fielding Day Software 5251 California Ave., Suite 110 Irvine, CA 92617 USA
日のSoftware5251カリフォルニアAveをさばいているロイT.、Suite110カリフォルニア92617アーバイン(米国)
Phone: +1-949-679-2960 Fax: +1-949-679-2972 EMail: fielding@gbiv.com URI: http://roy.gbiv.com/
以下に電話をしてください。 +1-949-679-2960 Fax: +1-949-679-2972 メールしてください: fielding@gbiv.com ユリ: http://roy.gbiv.com/
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
ラリーMasinterアドビ・システムズ株式会社345公園Aveカリフォルニア95110サンノゼ(米国)
Phone: +1-408-536-3024 EMail: LMM@acm.org URI: http://larry.masinter.net/
以下に電話をしてください。 +1-408-536-3024 メールしてください: LMM@acm.org ユリ: http://larry.masinter.net/
Berners-Lee, et al. Standards Track [Page 60] RFC 3986 URI Generic Syntax January 2005
バーナーズ・リー、他 規格は構文2005年1月にRFC3986URIジェネリックを追跡します[60ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Berners-Lee, et al. Standards Track [Page 61]
バーナーズ・リー、他 標準化過程[61ページ]
一覧
スポンサーリンク
