3.1. Scheme

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 は scheme 名で始まります。 Scheme 名はその scheme 内に識別子を割当てる仕様を参照しています。そのため URI の構文は各 scheme の仕様がその scheme を使う識別子の構文や意味を更に制限できる、 連合的で拡張可能な命名システムとなっています。

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.

Scheme 名は文字 (letter) で始まり、その後に文字、数字、 正 (+), 句点 (.), ハイフン (-) の任意の組合せが続く列です。 Scheme は大文字・小文字を区別しませんが、 正準系は小文字であり、 scheme を規定する文書は小文字で規定しなければなりません。 実装は頑強性のため scheme 名の大文字を小文字と同値なものとして受け入れるべきです (例えば HTTP を http 同様に認めるべきです) が、一貫性のため小文字の scheme 名のみを生成するべきです。

• 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.

具体的な scheme はこの文書では規定しません。新しい URI scheme を登録する手続きは別に BCP 35 で定義されています。 Scheme 登録簿は scheme 名と scheme の仕様の写像を管理します。 新しい URI scheme の設計者への助言が RFC 2718 にあります。 URI scheme 仕様は、 scheme 規定の構文に一致する文字列がすべて4.3節の absolute-URI 文法にも一致するように構文を定義しなければなりません。

When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific resolution process should flag the reference as an error rather than ignore the unused parts; doing so reduces the number of equivalent URIs and helps detect abuses of the generic syntax, which might indicate that the URI has been constructed to mislead the user (Section 7.6).

URI が scheme 規定の制限に違反する場合は、 scheme 規定の解決処理は未使用の部分を無視するのではなく、 その参照は誤りであると印をつけるべきです。そうすることで同値な URI の数を減らすことができ、一般的構文の乱用を発見するのを助けることができ、 その URI が利用者を誤解させるように構築されていると示すことができるかもしれません。

3.2. Authority

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 scheme は階層的要素として命名権者を含めており、 URI の残りの部分の名前空間の支配をその命名権者に委譲しています。 (そして命名権者が更に委譲するかもしれません。) 一般構文は登録名や鯖番地, 省略可能なポート情報や利用者情報によって命名権者を区別する共通の方法を提供します。

The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.

命名権者部品は二重斜線 (//) が前に来て、 次の斜線文字 /, 疑問符 (?), 数字符 (#) または URI の終わりが終端となります。

• authority = [ userinfo "@" ] host [ ":" port ]

URI producers and normalizers should omit the ":" delimiter that separates host from port if the port component is empty. Some schemes do not allow the userinfo and/or port subcomponents.

URI の生成器と正規化器は、ポート部品が空であれば、ホストとポートを分ける : 区切子を省略するべきです。 Scheme によっては部分部品 userinfo 及び/又は部分部品 port の使用を認めていません。

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.3. Path

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.

path 部品はデータを含みます。 データは通常階層によって組織化されており、 非階層的な query 部品と共に、 URI の scheme と (あれば) 命名権者による範囲の中で資源を識別する役目を担っています。 path は、最初の疑問符 (?) か数字符 (#) か 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 が authority 部品を含む時は、 path 部品は空であるか、または斜線文字 (/) で始まらなければなりません。 URI が authority 部品を含まない時は、 path は斜線文字2つ (//) で始まることができません。また、 URI 参照は relative-path 参照であっても構いませんが、その場合最初の path segment はコロン文字 (:) を含むことができません。 ABNF はこれらの場合を区別するため 5つの規則が必要ですが、ある URI 参照の path 部分はそのうちの1つにだけ一致します。一般語path 部品は構文解析器が 5つの規則のどれかと一致させる URI の一部分を指して使います。

•       path          = path-abempty    ; begins with "/" or is empty
                      / path-absolute   ; begins with "/" but not "//"
                      / path-noscheme   ; begins with a non-colon segment
                      / path-rootless   ; begins with a segment
                      / path-empty      ; zero characters
  >
  -      path-abempty  = *( "/" segment )
  -      path-absolute = "/" [ segment-nz *( "/" segment ) ] 
  -      path-noscheme = segment-nz-nc *( "/" segment )
  -      path-rootless = segment-nz *( "/" segment )
  -      path-empty    = 0<pchar>
  >
  -      segment       = *pchar
  -      segment-nz    = 1*pchar
  -
        segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                      ; non-zero-length segment without any colon ":"
  >
  -      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

A path consists of a sequence of path segments separated by a slash ("/") character. A path is always defined for a URI, though the defined path may be empty (zero length). Use of the slash character to indicate hierarchy is only required when a URI will be used as the context for relative references. For example, the URI mailto:fred@example.com has a path of "fred@example.com", whereas the URI foo://info.example.com?fred has an empty path.

/ は斜線文字 (/) で分離した path segment の列です。 path は空 (長さ零) かもしれませんが、すべての URI で必ず定義されます。 階層を表すために斜線文字を使わなければならないのは URI を相対参照の文脈として使う時だけです。例えば、 URI mailto:fred@example.com の path は fred@example.com で、 URI foo://info.example.com?fred の path は空です。

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).

path segment の . や .. は点付き部分ともいいますが、 path 名階層の中での相対参照のために定義されています。点付き部分は階層木中の名前の相対位置を示すために relative-path 参照のはじめで使うことを想定しています。 これはいくつかのオペレーティング・システムのファイル・ディレクトリ構造でそれぞれ現在ディレクトリと親ディレクトリを示すという役割と似ています。 しかし、ファイル・システムの場合とは異なり、これら点付き部分は URI path 階層の中でのみ解釈され、解決処理の中で除去されます。

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.

階層的 path での点付き部分以外は、 path segment は一般構文においては不透明と考えます。 URI 生成応用はしばしば scheme 規定または参照を解く取扱い器規定の部分部品を区切るために segment の中で認められている予約文字を使います。 例えば、予約文字であるセミコロン (:) や等号 (=) はしばしば segment に適用される引数や引数値を区切るために使われます。 予約文字読点 (,) はしばしば似た目的で使われます。 例えば、ある URI 生成器は name の第1.1版への参照を示すために name;v=1.1 のような segment を使うかもしれませんし、 別の URI 生成器は同じことを示すために name,1.1 のような segment を使うかもしれません。 Scheme 規定の意味によって引数の型も定義されるかもしれませんが、ほとんどの場合引数の構文は URI の参照を解く算法の実装に依存したものです。

3.4. Query

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.

query 部品は非階層的なデータを含み、 path 部品のデータと共に URI の scheme と (あれば) 命名権者の適用範囲内で資源を識別する働きをします。 query 部品は最初の疑問符 (?) で始まり、数字符 (#) か URI の末尾によって終わります。

• query = *( pchar / "/" / "?" )

The characters slash ("/") and question mark ("?") may represent data within the query component. Beware that some older, erroneous implementations may not handle such data correctly when it is used as the base URI for relative references (Section 5.1), apparently because they fail to distinguish query data from path data when looking for hierarchical separators. However, as query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI, it is sometimes better for usability to avoid percent-encoding those characters.

斜線文字 (/) と疑問符 (?) は query 部品の中でデータを表現することができます。 古い誤った実装は、斜線文字や疑問符が含まれたデータを相対参照の基底 URI として使うと、どうやら階層の分離子を探す時に path のデータと query のデータを区別できないらしく、 正しく扱うことができないかもしれません。しかし、 query 部品はしばしば 鍵=値 の組の形の識別情報を伝達するのに使われ、よく使われる値の1つが他の URI への参照であったりしますから、これらの文字の百分率符号化は避けた方が可用性的に好ましいことが時たまあります。

3.5. Fragment

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.

URI の素片識別子部品を使うと、一次資源への参照と追加の識別情報によって二次資源を間接的に識別することができます。 識別された二次資源は一次資源の一部分・部分集合かもしれませんし、 一次資源の表現上の形かもしれませんし、その表現によって定義・記述される他の資源かもしれません。 素片識別子部品は数字符 (#) の存在により示され、 URI の終わりで終端となります。

• fragment = *( pchar / "/" / "?" )

The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.

素片識別子の意味は一次資源の取出し動作の結果得られるであろう表現の集合により定義されます。 従って、 fragment の書式と解決は、 たとえ URI の参照が解かれる時だけ取出しが行われるのであったとしても、 取出される可能性のある表現の媒体型に依存します。そのような表現が存在しないのであれば、 fragment の意味は未知と考えられ、 実質無制約となります。素片識別子の意味は URI scheme とは独立であり、 scheme の仕様によって再定義することはできません。

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).

各媒体型は、素片識別子構文の範囲内において、 その媒体型で二次資源として識別できる色々な種類の部分集合, 表示, 外部参照を指定する制限や構造を定義することができます。 一次資源が複数の表現を持つこともあります。 しばしばあるのは資源の表現が取出し要求の属性に基づいて選択されるというもの (内容折衝) です。そのような場合には fragment が何を識別するのであれ、全表現を通じて一貫しているべきです。 各表現は (どう表現されるのであれ) 同じ二次資源を指すように fragment を定義するか、 またはその fragment を未定義 (つまり見つかりません) としておくべきです。

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 の scheme 規定の処理では使いません。代わりに、 素片識別子は参照を解く前に URI の残りの部分から分離され、 素片自体の中の識別情報は URI scheme に関わらず利用者エージェントによって単独で参照を解きます。 この分離処理はしばしば情報の損失であると理解されます (特に資源が時を経て移動する時に正確な参照の再指向の妨げとなります) が、 情報提供者が参照著者の資源内の情報を選択的に参照する権利を拒むのを防ぐことにもなています。 新しい識別の方法を定義・採用するのよりも新しい媒体型の方が簡単ですから、 間接参照は URI を使うシステムをより柔軟、より拡張可能にもしています。

The characters slash ("/") and question mark ("?") are allowed to represent data within the fragment identifier. Beware that some older, erroneous implementations may not handle this data correctly when it is used as the base URI for relative references (Section 5.1).

斜線文字 (/) と疑問符 (?) は素片識別子でデータを表現するために使うことができます。 古い誤った実装は相対参照の基底 URI として使う時にこのデータを正しく扱うことができないかもしれないことに注意してください。