/*********************************************************************** http://member.nifty.ne.jp/moha/rfc/rfc2396j.txt OOHASHI, Masanori mailto:DZT04436@nifty.ne.jp January 1, 2000 　この文書は、 RFC2396 "Uniform Resource Identifiers (URI): Generic Syntax" を、私「大橋正典」が日本語に翻訳したものです。 　RFCの正式な版は英語版です。この文書は私が個人的に翻訳したものであり、 the RFC EditorやIABなどによる保証はありません。また、この文書の訳の正確 性は保証しません。個別の訳語についても、これが正式なものである、ないしこ れが一般的に通用しているものであるとは保証しません。あくまで参考のみと し、正式な利用の際には、必ず原版を利用してください。 　原版にある、改ページ制御文字、ヘッダ、フッタは削除しています。行末を表 す制御文字も適宜削除しています。 　基本構成としては、見出しは訳語の後に括弧内で原文を記述し、本文では原文 の各段落ごとに対訳を記述しています。また一部の用語には、初出の際にその原 語を括弧内に記述しています。BNF式などは訳の後に記述し、各定義に使われて いる英語は翻訳していません。 　特に翻訳に疑問の残る部分については、文には文頭に「??」を、単語には語頭 に「?*」を添えています。 　配布条件など、その他この文書の扱いかたは、原文の条件に準じます。 　翻訳の誤りなど、お気づきの点はぜひEメールでお知らせください。 ***********************************************************************/ Network Working Group T. Berners-Lee Request for Comments: 2396 MIT/LCS Updates: 1808, 1738 R. Fielding Category: Standards Track U.C. Irvine L. Masinter Xerox Corporation August 1998 Uniform Resource Identifiers (URI): Generic Syntax 統一書式資源識別子(URI): 一般的構文 このメモの状況 (Status of this Memo) This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書は、インターネット共同体におけるインターネット標準化過程プロトコ ルを規定し、改良のための議論と提案を求めるものである。このプロトコルの標 準化状態と状況については、最新版の"Internet Official Protocol Standards" (STD 1)を参照してほしい。このメモの配布に制限はない。 著作権表示 (Copyright Notice) Copyright (C) The Internet Society (1998). All Rights Reserved. /*********************************************************************** この翻訳文書における二次的著作権については: Derivative copyright about Japanese translation: Copyright (C) OOHASHI Masanori (1999). All Rights Reserved. ***********************************************************************/ IESGによる注 (IESG Note) This paper describes a "superset" of operations that can be applied to URI. It consists of both a grammar and a description of basic functionality for URI. To understand what is a valid URI, both the grammar and the associated description have to be studied. Some of the functionality described is not applicable to all URI schemes, and some operations are only possible when certain media types are retrieved using the URI, regardless of the scheme used. この文書は、URIに適用できる操作の「超集合」を記述する。この「超集合」は URIの文法と基本的機能解説の両方からなる。何が妥当なURIであるか理解するた めには、文法及び関連した解説の両方を学ぶ必要がある。記述している機能のい くつかは、すべてのURIスキームに適用することはできない。又、いくつかの操 作は、URIを用いて特定のメディア型を取得するときにのみ可能で、使用するス キームには依らない。 抄録 (Abstract) A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. 統一書式資源識別子 (Uniform Resource Identifier, URI)は、抽象的又は物理 的資源を識別するための簡潔な文字列である。この文書は、絶対書式と相対書式 のいずれをも含む、URIの一般的構文を定義し、その使用法のガイドラインを定 める。ここでの定義は、RFC 1738及びRFC 1808における一般的定義を改訂し、置 換するものである。 This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. この文書では、あらゆる妥当なURIの超集合となる文法を定義する。これは、URI 参照の共通部分を、とりうるすべての識別子型についてのスキーム固有な要求事 項を知らずとも、処理系が構文解析できるようにするものである。この文書は URIの生成文法については定義しない。その任は各URIスキーム個々の仕様書が果 たす。 1.概要 (Introduction) Uniform Resource Identifiers (URI) provide 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 such objects dates from 1990 and is described in "Universal Resource Identifiers in WWW" [RFC1630]. The specification of URI 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 Identifiers, URI)は、資源を特定する 単純かつ拡張性のある手段を提供する。URIの構文と意味論を扱うこの仕様書 は、?* the World Wide Web global information initiativeによって導入され た概念から派生した文書である。彼らがこのようなオブジェクトを使用し始めた のは1990年からであり、"Universal Resource Identifiers in WWW" [RFC1630] にそれを記述している。URIの仕様は、"Functional Recommendations for Internet Resource Locators" [RFC1736]及び"Functional Requirements for Uniform Resource Names" [RFC1737]で記述されている推奨事項を満足するよう 設計されている。 This document updates and merges "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order to define a single, generic syntax for all URI. It excludes those portions of RFC 1738 that defined the specific syntax of individual URL schemes; those portions will be updated as separate documents, as will the process for registration of new URI schemes. This document does not discuss the issues and recommendation for dealing with characters outside of the US-ASCII character set [ASCII]; those recommendations are discussed in a separate document. この文書は、すべてのURIに対して単一で一般的な構文を定義するために、 "Uniform Resource Locators" [RFC1738] 及び "Relative Uniform Resource Locators" [RFC1808]を更新し併合するものである。この文書からは、RFC 1738 で各URLスキーム特有の構文について定義した部分を除外している。これらの部 分は、独立した文書として、新たなURIスキームを登録する過程で更新する。こ の文書は、US-ASCII文字集合 [ASCII]に含まれない文字を扱う際の問題点や勧告 については議論しない。これらの勧告は、独立した文書で議論する。 All significant changes from the prior RFCs are noted in Appendix G. 以前のRFCからの重要な変更点はすべて、附属書 Gで記述する。 1.1 URIの概略 (Overview of URI) URI are characterized by the following definitions: 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; and, 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. 統一書式 (Uniform) 統一した書式であること(Uniformity)にはいくつかの利点がある。異なる型の資 源識別子を、たとえそれらの資源にアクセスする際に用いる機構が異なっていて も、同じ文脈の中で用いることができる。さまざまに型の異なる資源識別子に共 通した構文の慣行を、一貫した意味で解釈できる。すでに存在する識別子が用い る手法を妨げることなく新たな型の資源識別子を導入できる。及び、識別子をさ まざま異なった文脈で再利用でき、それゆえ新たなアプリケーションやプロトコ ルは現に存在する、巨大で広く用いられている資源識別子セットを活用できる。 Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. 資源 (Resource) 資源は個が特定できるものであれば何であってもよい。おなじみの例としては、 電子文書、画像、サービス(例えば「ロサンゼルスの今日の天気予報」)、及び何 らかの資源の集合体が挙げられる。資源のすべてがネットワークを通じて"取得 可能"というわけではない。例えば、人間、企業、及び図書館にある装丁された 書籍も、資源とみなすことができる。 The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. Thus, a resource can remain constant even when its content---the entities to which it currently corresponds---changes over time, provided that the conceptual mapping is not changed in the process. 資源とは、実体又は実体の集合への概念的写像のことであり、??必ずしも任意の 時点で写像に対応する実体である必要はない。従って、たとえ資源の内容---そ の時点で対応している実体---が時間経過で変化しても、その過程中で概念的写 像が変更されない限り、資源は不変であり続けられる。 Identifier An identifier is an object that can act as a reference to something that has identity. In the case of URI, the object is a sequence of characters with a restricted syntax. 識別子 (Identifier) 識別子は、個が特定できる何物かへの参照として作用することができるオブジェ クトである。URIの場合、オブジェクトは限定的な構文に従う文字列である。 Having identified a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as `access', `update', `replace', or `find attributes'. 資源が特定されたとき、システムはその資源に、「アクセス」、「更新」、「置 換」、「属性を判別」といった言葉で特徴づけられるような、さまざまな操作を 行える。 1.2.URI、URL、及びURN (URI, URL, and URN) A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The term "Uniform Resource Name" (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. URIはそれが位置指定子か、名前か、又はその両方かという点で、さらに分類で きる。用語"統一書式資源位置指定子" (Uniform Resource Locator, URL)が指す URIの部分集合は、資源を特定する手段として直接的なアクセス機構(例えばネッ トワーク上の"位置(location)")の表現を用い、資源の名前やその他の属性に依 らないものからなる。用語"統一書式資源名" (Uniform Resource Name, URN)が 指すURIの部分集合は、たとえその資源が存在しなくなったり利用できなくなっ ても、全世界的に一意かつ永続的であり続けることが求められる。 The URI scheme (Section 3.1) defines the namespace of the URI, and thus may further restrict the syntax and semantics of identifiers using that scheme. This specification defines those elements of the URI syntax that are either required of all URI schemes or are common to many URI schemes. It thus defines the syntax and semantics that are needed to implement a scheme-independent parsing mechanism for URI references, such that the scheme-dependent handling of a URI can be postponed until the scheme-dependent semantics are needed. We use the term URL below when describing syntax or semantics that only apply to locators. URIスキーム (Section 3.1)はURIの名前空間を定義し、それゆえにそのスキーム を用いる識別子の構文と意味はさらに制限されることがある。この仕様書では、 すべてのURIスキームで必要な、又は多くのURIスキームで共通なURI構文の要素 を定義する。よって、この仕様書で定義する構文と意味論は、URI参照をスキー ム独立に構文解析する機構を実装する上で必要なものとし、スキームに依存する 処理は、スキーム依存の意味解釈が必要になるまで後回しにできるようにする。 これ以降でURLという用語は、位置指定子にのみ適用される構文と意味論を記述 する際に用いる。 Although many URL schemes are named after protocols, this does not imply that the only way to access the URL's resource is via the named protocol. Gateways, proxies, caches, and name resolution services might be used to access some resources, independent of the protocol of their origin, and the resolution of some URL may require the use of more than one protocol (e.g., both DNS and HTTP are typically used to access an "http" URL's resource when it can't be found in a local cache). 多くのURLスキームはプロトコルの名をとって命名されているが、だからといっ てそれは、あるURLの資源にアクセスする上で、その名の由来となっているプロ トコルしか利用できないという意味ではない。ゲートウェイ、プロキシ、キャッ シュ、名前解決サービスなどが、資源本来のプロトコルとは独立に、資源へのア クセスに使われることもある。又、あるURLを?*解決する際に、複数のプロトコ ルを必要とすることもある。(例えば、ローカルのキャッシュで見つからない、 "http" URLの資源にアクセスするには、通常DNSとHTTPの両方が必要である) A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces, each of which has its own set name structure and assignment procedures. The "urn" scheme has been reserved to establish the requirements for a standardized URN namespace, as defined in "URN Syntax" [RFC2141] and its related specifications. 　URNのURLとの違いは、その主たる目的が資源に対して識別子を使って永続的な ラベリングをすることにある点である。その識別子は定義済みの名前空間の集合 から作成され、それぞれの定義済み名前空間は独自の集合名構造及び割り当て手 順を持っている。"urn"というスキームは、"URN Syntax" [RFC2141]及び関係す る仕様書で定義されているように、標準化されたURN名前空間の必要条件を満た すために予約されている。 Most of the examples in this specification demonstrate URL, since they allow the most varied use of the syntax and often have a hierarchical namespace. A parser of the URI syntax is capable of parsing both URL and URN references as a generic URI; once the scheme is determined, the scheme-specific parsing can be performed on the generic URI components. In other words, the URI syntax is a superset of the syntax of all URI schemes. この仕様書では、例の大部分をURLにあてている。それは、URLは構文の使いかた が非常に多様で、多くの場合階層的な名前空間を持っているためである。URI構 文の?*構文解析器は、URLとURNのどちらの参照も、一般的なURIとして構文解析 する能力を持つ。スキームが判明すれば、各一般的URI成分に対してスキーム依 存構文解析が実行可能となる。言いかたを変えれば、URI構文はすべてのURIス キーム構文の超集合である。 1.3. URIの例 (Example URI) The following examples illustrate URI that are in common use. 以下に、よく使われているURIを例示する。 ftp://ftp.is.co.za/rfc/rfc1808.txt -- ftp scheme for File Transfer Protocol services --ファイル転送プロトコルサービス用のftpスキーム gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles -- gopher scheme for Gopher and Gopher+ Protocol services --Gopher及びGopher+プロトコルサービス用のgopherスキーム http://www.math.uio.no/faq/compression-faq/part1.html -- http scheme for Hypertext Transfer Protocol services --ハイパーテキスト転送プロトコル用のhttpスキーム mailto:mduerst@ifi.unizh.ch -- mailto scheme for electronic mail addresses --電子メールアドレス用のmailtoスキーム news:comp.infosystems.www.servers.unix -- news scheme for USENET news groups and articles --USENETニュースグループ及び記事用のnewsスキーム telnet://melvyl.ucop.edu/ -- telnet scheme for interactive services via the TELNET Protocol --TELNETプロトコルを通じた対話型サービス用のtelnetスキーム 1.4. 階層的URIと相対形式 (Hierarchical URI and Relative Forms) An absolute identifier refers to a resource independent of the context in which the identifier is used. In contrast, a relative identifier refers to a resource by describing the difference within a hierarchical namespace between the current context and an absolute identifier of the resource. 絶対識別子は、その識別子が使われている文脈と独立に資源を参照する。対照的 に相対識別子は、階層的名前空間内における現在の文脈と資源の絶対識別子との 差異を記述することで、資源を参照する。 Some URI schemes support a hierarchical naming system, where the hierarchy of the name is denoted by a "/" delimiter separating the components in the scheme. This document defines a scheme-independent `relative' form of URI reference that can be used in conjunction with a `base' URI (of a hierarchical scheme) to produce another URI. The syntax of hierarchical URI is described in Section 3; the relative URI calculation is described in Section 5. いくつかのURIスキームは、階層的命名機構を用意している。そこでは名前の階 層を、スキームにおける成分を"/"区切り子で分割することで表記する。この文 書では、URI参照のためにスキーム独立な「相対」書式を定義するが、これを(階 層的スキームの)「基底」URIとともに用いることで新たなURIを生成できる。階 層的URIの構文はSection 3で記述する。相対URIの算出方法はSection 5で記述す る。 1.5. URIの転記性 (URI Transcribability) The URI syntax was designed with global transcribability as one of its main concerns. A URI is a sequence of characters from a very limited set, i.e. 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 octets in a coded character set. The interpretation of a URI depends only on the characters used and not how those characters are represented in a network protocol. URI構文は、全世界的な転記性を主要課題のひとつとして設計された。URIは非常 に限られた文字集合、すなわち基本ラテンアルファベット、数字、いくつかの特 殊文字からなる文字集合中から選ばれた文字の列である。URIはさまざまな方法 で表現できる。たとえば、紙の上のインク、画面上のピクセル、又は符号化文字 集合中のオクテット列。URI解釈は用いられている文字にのみ依存し、それらの 文字がネットワークプロトコル中でどのように表現されているかには依存しな い。 The goal of transcribability 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人の参加者SamとKimがパブで席について、研究のアイデアを やりとりしている様子を想像してほしい。SamがKimに、より詳しい情報がどこで 得られるかを尋ねる。するとKimが研究のサイトを示すURIをナプキンに書く。家 に帰って、Samはナプキンを取り出し、URIをコンピュータにタイプする。すると Kimが言及した情報が取得できる。 There are several design concerns revealed by the scenario: このシナリオからは、いくつかの設計課題が明らかになっている o A URI is a sequence of characters, which is not always represented as a sequence of octets. ・URIは文字列であり、常にオクテット列として表現されるわけではない。 o A URI may be transcribed from a non-network source, and thus should consist of characters that are most likely to be able to be typed into a computer, within the constraints imposed by keyboards (and related input devices) across languages and locales. ・URIはネットワーク上にないソースから転記されることもある。そのためURI は、ほとんどのコンピュータで入力可能な文字からなっている必要があり、そこ にはさまざまな言語やロケールのキーボード(及び関連した入力デバイス)がある という制限が存在する。 o A URI often needs to be remembered by people, and it is easier for people to remember a URI when it consists of meaningful components. ・URIは、しばしば人間が記憶する必要がある。そしてURIが意味のある成分から なっている場合、人間にとってより覚えやすい。 These design concerns 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 the resource identifier from one medium to another was considered more important than having its URI consist of the most meaningful of components. In local and regional contexts and with improving technology, users might benefit from being able to use a wider range of characters; such use is not defined in this document. これらの設計課題は、すべてが並立しているわけではない。例えば、あるURI成 分にもっとも適切な名前に必要な文字が、あるシステムではタイプできない場合 もよくある。資源識別子をあるメディアから別のメディアへ転記できるというこ とは、URIがもっとも適切な成分からなることより重要であると考慮された。 ローカルな、あるいは地域限定的な状況で使う場合、技術的改良をすれば、利用 者はより広範囲の文字を使うことができ、便利であるかもしれない。そのような 使いかたはこの文書では定義しない。 1.6. 構文の表記法と共通要素 (Syntax Notation and Common Elements) This document uses two conventions to describe and define the syntax for URI. The first, called the layout form, is a general description of the order of components and component separators, as in この文書では、2つの方式を使ってURIの構文を記述し定義する。レイアウト書式 と呼ぶ1番目の方式は、成分と分離子の順序を一般化して記述するもので、以下 のように表す。 /;? The component names are enclosed in angle-brackets and any characters outside angle-brackets are literal separators. Whitespace should be ignored. These descriptions are used informally and do not define the syntax requirements. 成分名は山括弧でくくられ、山括弧の外にある文字はすべてリテラル分離子とな る。空白は無視すること。これらの記述は非公式に用いられるもので、構文の要 件を定義するものではない。 The second convention is a BNF-like grammar, used to define the formal URI syntax. The grammar is that of [RFC822], except that "|" is used to designate alternatives. Briefly, rules are separated from definitions by an equal "=", indentation is used to continue a rule definition over more than one line, literals are quoted with "", parentheses "(" and ")" are used to group elements, optional elements are enclosed in "[" and "]" brackets, and elements may be preceded with * to designate n or more repetitions of the following element; n defaults to 0. 2番目の方式はBNF類似の文法で、正式なURI構文を定義するために使う。この文 法は、"|"を代替を意味するよう定義している点以外は、[RFC822]と同じもので ある。大まかに言って、定義は等号"="によって規則と区分される。インデント は、規則定義を1行を越えて続ける際に使う。リテラルは引用符""で括る。丸括 弧"("と")"は要素をグループ化するために使う。任意選択要素は角括弧"["と"]" でくくる。要素の前に*を付けることができ、それに続く要素のn回以上の繰 り返しを意味する。nの既定値は0である。 Unlike many specifications that use a BNF-like grammar to define the bytes (octets) allowed by a protocol, the URI grammar is defined in terms of characters. Each literal in the grammar corresponds to the character it represents, rather than to the octet encoding of that character in any particular coded character set. How a URI is represented in terms of bits and bytes on the wire is dependent upon the character encoding of the protocol used to transport it, or the charset of the document which contains it. BNF類似文法をプロトコルで使えるバイト(オクテット)を定義するために使って いる多くの仕様書とは異なり、URIの文法は文字に対する定義である。文法中の 各リテラルは、それが表現している文字そのものに対応しており、その文字を何 らかの特定の符号化文字集合で符号化したオクテットに対応するものではない。 通信回線上でURIがビットやバイトとしてどのように表現されるかは、そのURIを 転送するために使われているプロトコル、又はそのURIを含む文書の文字集合、 の文字符号化方式に依存する。 The following definitions are common to many elements: 以下の定義は多くの要素に共通する。 alpha = lowalpha | upalpha lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" alphanum = alpha | digit The complete URI syntax is collected in Appendix A. 完全なURI構文は付属書Aにまとめてある。 2. URI文字とエスケープシーケンス (URI Characters and Escape Sequences) URI consist of a restricted set of characters, primarily chosen to aid transcribability and usability both in computer systems and in non-computer communications. Characters used conventionally as delimiters around URI were excluded. The restricted set of characters consists of digits, letters, and a few graphic symbols were chosen from those common to most of the character encodings and input facilities available to Internet users. URIは、コンピュータシステムとコンピュータによらないコミュニケーションの いずれにおいても転記がしやすく使いやすいことを第一に選ばれた、限られた文 字の集合からなる。URIの前後で区切り子としてよく使われる文字は排除した。 数字、アルファベット、及びいくつかの記号からなるこの限定的文字集合は、イ ンターネット利用者が利用できる文字符号化方法及び入力機能のほとんどに共通 する文字から選択した。 uric = reserved | unreserved | escaped Within a URI, characters are either used as delimiters, or to represent strings of data (octets) within the delimited portions. Octets are either represented directly by a character (using the US- ASCII character for that octet [ASCII]) or by an escape encoding. This representation is elaborated below. URI中では、文字は区切り子として使われるか、又は区切り子で分けられた部分 中でデータ(オクテット)列を表現するために使われる。オクテットは文字で直接 表現する(そのオクテットを表すUS-ASCII文字[ASCII]を使う)か、又はエスケー プ符号化を使う。この表現は後に詳しく述べる。 2.1 URIと非ASCII文字 (URI and non-ASCII characters) The relationship between URI and characters has been a source of confusion for characters that are not part of US-ASCII. To describe the relationship, it is useful to distinguish between a "character" (as a distinguishable semantic entity) and an "octet" (an 8-bit byte). There are two mappings, one from URI characters to octets, and a second from octets to original characters: URIと文字との関連性は、US-ASCIIに含まれない文字にとって混乱の源となって きた。この関連性について説明するために、(意味的に区別可能な1つの実体とし ての)"文字"と"オクテット"(8ビットのバイト)を区別することが有用である。こ こに2個の写像がある。ひとつはURI文字からオクテットへ、2個めはオクテット からもとの文字への写像である。 URI character sequence->octet sequence->original character sequence A URI is represented as a sequence of characters, not as a sequence of octets. That is because URI might be "transported" by means that are not through a computer network, e.g., printed on paper, read over the radio, etc. URIは文字列として表現される。オクテット列としてではない。これは、URIはコ ンピュータネットワークを通さない手段、たとえば紙への印刷、ラジオでの読み 上げなど、によって「伝送」することもあるからである。 A URI scheme may define a mapping from URI characters to octets; whether this is done depends on the scheme. Commonly, within a delimited component of a URI, a sequence of characters may be used to represent a sequence of octets. For example, the character "a" represents the octet 97 (decimal), while the character sequence "%", "0", "a" represents the octet 10 (decimal). URIのスキームはURI文字からオクテットへの写像を定義することもある。定義が 行われるかどうかはスキームによる。一般に、URIの区切り子で分けられた成分 中では、文字列はオクテット列の表現として使われる。たとえば、文字"a"はオ クテット97(10進法)を表現し、文字列"%","0","a"はオクテット10(10進法)を表 現する。 There is a second translation for some resources: the sequence of octets defined by a component of the URI is subsequently used to represent a sequence of characters. A 'charset' defines this mapping. There are many charsets in use in Internet protocols. For example, UTF-8 [UTF-8] defines a mapping from sequences of octets to sequences of characters in the repertoire of ISO 10646. 資源によっては、2番目の変換が行われる。URIの成分で定義されたオクテット列 が、それを受けて文字列の表現として使われる。'文字集合'がこの写像を定義す る。インターネットプロトコルでは多数の文字集合が使われている。たとえば、 UTF-8 [UTF-8]はオクテット列からISO 10646のレパートリに含まれる文字の列へ の写像を定義する。 In the simplest case, the original character sequence contains only characters that are defined in US-ASCII, and the two levels of mapping are simple and easily invertible: each 'original character' is represented as the octet for the US-ASCII code for it, which is, in turn, represented as either the US-ASCII character, or else the "%" escape sequence for that octet. もっとも単純な場合では、元の文字列はUS-ASIIで定義されている文字のみを含 み、2つの段階の写像が単純かつ容易な逆写像である。'元の文字'はそれぞれ、 その文字に対応するUS-ASCII符号を表すオクテットとして表現され、逆にこのオ クテットは、US-ASCIIの文字として、又はそのオクテットを表す"%"エスケープ 文字列として表現される。 For original character sequences that contain non-ASCII characters, however, the situation is more difficult. Internet protocols that transmit octet sequences intended to represent character sequences are expected to provide some way of identifying the charset used, if there might be more than one [RFC2277]. However, there is currently no provision within the generic URI syntax to accomplish this identification. An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used. しかし、元の文字列が非ASCII文字を含んでいる場合、事情はよりやっかいにな る。文字列を表現することを意図してオクテット列を伝送するインターネットプ ロトコルは、とりうる文字集合が複数ある場合、使われている文字集合を識別す る何らかの方法を提供していると期待される[RFC2277]。しかし、一般的URI構文 ではこの識別を達成するための方法を現時点では備えていない。各URIスキーム は、単一の文字集合を要求する場合も、既定の文字集合を定義している場合も、 使われている文字集合を示す手段を備えている場合もある。 It is expected that a systematic treatment of character encoding within URI will be developed as a future modification of this specification. この仕様書を将来において修正するものとして、URIの中で文字符号化を体系的 に処理する方法が開発されるであろう。 2.2. 予約文字 (Reserved Characters) Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI. 多くのURIは、その成分を構成したり、区切り子として使う、何らかの特殊文字 を含む。これらの文字は"reserved(予約されている)"と呼ばれる。なぜなら、こ れらの文字のURI成分中での用法は予約目的によって制限されるからである。も しあるURI成分に対するデータがこの予約目的と衝突するならば、衝突している データはURIを形成する前にエスケープしなければならない。 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," The "reserved" syntax class above refers to those characters that are allowed within a URI, but which may not be allowed within a particular component of the generic URI syntax; they are used as delimiters of the components described in Section 3. 上記の"reserved"構文クラスは、URIの中に含むことは認められているが、一般 的URI構文の特定成分中に含むことは認められない文字を指す。これらの文字 は、Section 3で述べる、成分の区切り子として使われる。 Characters in the "reserved" set are not reserved in all contexts. The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding. "reserved"集合に含まれる文字は、すべての文脈で予約されているわけではな い。あるURI成分中での実際の予約文字集合は、その成分において定義されてい る。一般的に言って、ある文字をその文字のエスケープによるUS-ASCII符号化で 置き換えた場合にURIの意味論が変わる場合、その文字は予約されている。 2.3. 非予約文字 (Unreserved Characters) Data characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include upper and lower case letters, decimal digits, and a limited set of punctuation marks and symbols. URI中に含むことを認められていて、予約目的のないデータ文字は、非予約 (unreserved)と呼ばれる。この中には、大文字と小文字のアルファベット、数 字、及び句読点や記号の一部が含まれる。 unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. 非予約文字はURIの意味を変えずにエスケープできる。しかし、その非予約文字 が現れることが認められていない文脈でURIが使われている場合以外は、エス ケープすべきでない。 2.4. エスケープ文字列 (Escape Sequences) Data must be escaped if it does not have a representation using an unreserved character; this includes data that does not correspond to a printable character of the US-ASCII coded character set, or that corresponds to any US-ASCII character that is disallowed, as explained below. データは、非予約文字を使った表現方法がない場合、エスケープしなければなら ない。このようなデータには、US-ASCII符号化文字集合の印刷可能文字と合致し ないデータ、又は以下で説明する、使用が認められないUS-ASCII文字と合致する データがある。 2.4.1. エスケープ符号化 (Escaped Encoding) An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code. For example, "%20" is the escaped encoding for the US-ASCII space character. エスケープされたオクテットは、三連文字として符号化される。この三連文字 は、パーセント文字"%"の後に、オクテット符号を表す2つの16進数字が続く形で 構成される。たとえば、"%20"はUS-ASCIIの空白文字に対するエスケープ符号化 である。 escaped = "%" hex hex hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" 2.4.2. エスケープとエスケープ解除をいつ行うか (When to Escape and Unescape) A URI is always in an "escaped" form, since escaping or unescaping a completed URI might change its semantics. Normally, the only time escape encodings can safely be made is when the URI is being created from its component parts; each component may have its own set of characters that are reserved, so only the mechanism responsible for generating or interpreting that component can determine whether or not escaping a character will change its semantics. Likewise, a URI must be separated into its components before the escaped characters within those components can be safely decoded. ?? あるURIは、常にある1つの「エスケープされた」書式をとる。?? なぜなら、 完成しているURIをエスケープする、又はエスケープ解除すると、意味が変わる ことがあるからである。一般に、エスケープ符号化を安全に行うことができるの は、URIがその成分から形成される途中だけである。各成分は独自の予約文字集 合を持つことがあるため、当該成分の生成又は解釈に責任を持つ機構にしか、文 字のエスケープがその意味を変えるかどうか判定できないからである。同様に、 URIはその構成部分にあらかじめ分割されなければ、それら成分中のエスケープ された文字を安全に復号化できない。 In some cases, data that could be represented by an unreserved character may appear escaped; for example, some of the unreserved "mark" characters are automatically escaped by some systems. If the given URI scheme defines a canonicalization algorithm, then unreserved characters may be unescaped according to that algorithm. For example, "%7e" is sometimes used instead of "~" in an http URL path, but the two are equivalent for an http URL. 場合によっては、非予約文字で表現できるはずのデータがエスケープされて現れ ることがある。たとえば、あるシステムではある種の非予約"mark"文字が自動的 にエスケープされる。URIのスキームがcanonicalization algorithm*?を規定し ている場合、非予約文字はそのアルゴリズムに従ってエスケープされないことが ある。たとえば、httpのURLパスでは、"%7e"が"~"の代わりに使われることがあ るが、httpのURLではこのふたつは同値である。 Because the percent "%" character always has the reserved purpose of being the escape indicator, it must be escaped as "%25" in order to be used as data within a URI. Implementers should be careful not to escape or unescape the same string more than once, since unescaping an already unescaped string might lead to misinterpreting a percent data character as another escaped character, or vice versa in the case of escaping an already escaped string. パーセント文字"%"は常にエスケープ表示子という予約目的があるので、URI中で データとしてこの文字が使われている場合、"%25"とエスケープされなければな らない。機構を実装する際は、同じ文字列に対してエスケープ又はエスケープ解 除を複数回行わないよう注意すべきである。なぜなら、すでにエスケープ解除さ れている文字列をエスケープ解除すると、パーセントデータ文字を新たにエス ケープされた文字として誤解釈することにつながりかねないからである。又これ と逆のことが、すでにエスケープされている文字列をエスケープする場合に言え る。 2.4.3 除外US-ASCII文字 (Excluded US-ASCII Characters) Although they are disallowed within the URI syntax, we include here a description of those US-ASCII characters that have been excluded and the reasons for their exclusion. ここで挙げられる文字はそもそもURI構文では認められていない文字だが、ここ では除外されたUS-ASCII文字とその除外理由について説明を加える。 The control characters in the US-ASCII coded character set are not used within a URI, both because they are non-printable and because they are likely to be misinterpreted by some control mechanisms. US-ASCII符号化文字集合中の制御文字はURI中では使われない。その理由として は、それらが印刷不可能であることと、一部の制御機構によって誤解釈されかね ないことがある。 control = The space character is excluded because significant spaces may disappear and insignificant spaces may be introduced when URI are transcribed or typeset or subjected to the treatment of word- processing programs. Whitespace is also used to delimit URI in many contexts. 空白文字が除外されるのは、URIを転写する、又は活字に組む、又はワードプロ セッサで処理する際に、意味のある空白が消失したり意味のない空白が挿入され たりすることがあるためである。空白文字は多くの状況でURIを区切るためにも 使われる。 space = The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields. The character "#" is excluded because it is used to delimit a URI from a fragment identifier in URI references (Section 4). The percent character "%" is excluded because it is used for the encoding of escaped characters. 山括弧"<"と">"及び二重引用符(")が除外されるのは、これらがテキスト文書や プロトコルフィールド中で、URIの前後の区切り子として使われることがあるか らである。文字"#"が除外されるのは、これがURI参照の際にURIと?*部分識別子 を区切るために使われるからである(Section 4)。パーセント文字"%"が除外され るのは、これがエスケープされる文字の符号化に使われるからである。 delims = "<" | ">" | "#" | "%" | <"> Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters. 他の文字が除外されるのは、ゲートウェイや他の転送エージェントによっては、 これらの文字を変化させたり、デリミタとして使用していたりすることが知られ ているからである。 unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" Data corresponding to excluded characters must be escaped in order to be properly represented within a URI. URI中で適切に表現されるように、除外文字に対応するデータはエスケープされ なければならない。 3. URI構文の成分 (URI Syntactic Components) The URI syntax is dependent upon the scheme. In general, absolute URI are written as follows: URI構文はスキームに依存する。一般に、絶対URIは次のように記述する。 : An absolute URI contains the name of the scheme being used () followed by a colon (":") and then a string (the ) whose interpretation depends on the scheme. 絶対URIは、使用されているスキーム名()に始まり、次にコロン1文字 (":")、そして解釈がスキーム依存である文字列()が続 く。 The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This "generic URI" syntax consists of a sequence of four main components: URI構文は、すべてのURIに共通であるような一般的構造や意味集合であることを scheme-specific-partに求めない。しかし、URIのある部分集合は、名前空間に おける階層的関係性を表現するための共通構文を共有している。この「一般的 URI」構文は4個の主な成分の列からなる。 ://? each of which, except , may be absent from a particular URI. For example, some URI schemes do not allow an component, and others do not use a component. を除く各成分は、特定のURIでは存在しないこともある。たとえば、 成分を許可しないURIスキームもあれば、成分を使わないURI スキームもある。 absoluteURI = scheme ":" ( hier_part | opaque_part ) URI that are hierarchical in nature use the slash "/" character for separating hierarchical components. For some file systems, a "/" character (used to denote the hierarchical structure of a URI) is the delimiter used to construct a file name hierarchy, and thus the URI path will look similar to a file pathname. This does NOT imply that the resource is a file or that the URI maps to an actual filesystem pathname. 階層的な性質を持つURIでは、スラッシュ文字"/"を階層成分の区分に使う。ある 種のファイルシステムでは、(URIの階層構造を示すために使われる)"/"という文 字が、ファイル名の階層を構成するために使われる区切り子である。そのため、 URIのパスはファイルのパス名と類似しているように見えるだろう。このこと は、当該の資源が1個のファイルである、又は当該のURIが現実のファイルシステ ムのパス名と写像関係にあるということを意味するものでは*ない*(NOT)。 hier_part = ( net_path | abs_path ) [ "?" query ] net_path = "//" authority [ abs_path ] abs_path = "/" path_segments URI that do not make use of the slash "/" character for separating hierarchical components are considered opaque by the generic URI parser. 階層的成分の区分としてスラッシュ文字"/"を使用していないURIは、一般的URI 構文解釈器からは?*オペークであるとみなされる。 opaque_part = uric_no_slash *uric uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," We use the term to refer to both the and constructs, since they are mutually exclusive for any given URI and can be parsed as a single component. この文書ではという用語を、及びの両方が構成 するものを指すものとして使う。なぜなら、任意のURIでこれらは相互に排他的 であり、又これらを単一の成分として構文解析可能だからである。 3.1. スキーム成分(Scheme Component) Just as there are many different methods of access to resources, there are a variety of schemes for identifying such resources. The URI syntax consists of a sequence of components separated by reserved characters, with the first component defining the semantics for the remainder of the URI string. 資源にアクセスするには多数の異なる方法があるように、これらの資源を識別す るためのスキームにはさまざまな種類がある。URI構文は予約文字で区切られた 成分の列からなり、その最初の成分は残りのURI文字列の意味を決定する。 Scheme names consist of a sequence of characters beginning with a lower case letter and followed by any combination of lower case letters, digits, plus ("+"), period ("."), or hyphen ("-"). For resiliency, programs interpreting URI should treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http"). スキーム名は英小文字から始まり、その後に英小文字、数字、プラス("+")、ピ リオド(".")、又はハイフン("-")を組み合わせた文字列が続く。許容性を持たせ るため、URIを解釈するプログラムはスキーム名中の英大文字を小文字と同一視 して扱うべきである(たとえば"HTTP"を"http"と同様に認める)。 scheme = alpha *( alpha | digit | "+" | "-" | "." ) Relative URI references are distinguished from absolute URI in that they do not begin with a scheme name. Instead, the scheme is inherited from the base URI, as described in Section 5.2. 相対URI参照は、それらがスキーム名から始まっていないことをもって、絶対URI と区別される。その際、相対URI参照のスキームは基底URIから継承する。このこ とについてはSection 5.2.で説明する。 3.2. オーソリティ成分 (Authority Component) Many URI schemes include a top hierarchical element for a naming authority, such that the namespace defined by the remainder of the URI is governed by that authority. This authority component is typically defined by an Internet-based server or a scheme-specific registry of naming authorities. 多くのURIスキームには、命名機関(naming authority)としての最上層要素を含 む。URIの残りの部分によって定義される名前空間は、この機関によって管理さ れる。このオーソリティ成分は、インターネットベースのサーバ又はスキーム依 存の命名機関レジストリで定義されるのが典型的である。。 authority = server | reg_name The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved. オーソリティ成分は二重のスラッシュ"//"で始まり、次のスラッシュ"/"、疑問 符"?"、又はURIの末端位置において終了する。オーソリティ成分中では、文字 ";"、":"、"@"、"?"、及び"/"は予約されている。 An authority component is not required for a URI scheme to make use of relative references. A base URI without an authority component implies that any relative reference will also be without an authority component. オーソリティ成分は、URIスキームが相対参照を使用する際には必要ではない。 オーソリティ成分を含まない基底URIは、どの相対参照もオーソリティ成分を含 まないことをも暗に意味している。 3.2.1. レジストリベース命名機関(Registry-based Naming Authority) The structure of a registry-based naming authority is specific to the URI scheme, but constrained to the allowed characters for an authority component. ??レジストリベース命名機関の構造はそのURIスキーム特有である。しかし、 オーソリティ成分に許可されている文字に制限される。 reg_name = 1*( unreserved | escaped | "$" | "," | ";" | ":" | "@" | "&" | "=" | "+" ) 3.2.2. サーバベース命名機関(Server-based Naming Authority) URL schemes that involve the direct use of an IP-based protocol to a specified server on the Internet use a common syntax for the server component of the URI's scheme-specific data: インターネット上の特定サーバに対しIPベースのプロトコルを直接使用するURL スキームは、URIのスキーム依存データにおけるserver成分については共通の文 法を用いる。 @: where may consist of a user name and, optionally, scheme- specific information about how to gain authorization to access the server. The parts "@" and ":" may be omitted. ここでには利用者名及び、選択肢として、サーバへアクセスするため の認証を得ることに関するスキーム依存情報を含むことができる。 "@"及び":"の部分は省略可能である。 server = [ [ userinfo "@" ] hostport ] The user information, if present, is followed by a commercial at-sign "@". 利用者情報が存在する場合、その後ろには単価記号"@"を付ける。 userinfo = *( unreserved | escaped | ";" | ":" | "&" | "=" | "+" | "$" | "," ) Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used. URLスキームの中には、userinfoフィールドで"user:password"書式を使うものが ある。この慣習は推奨しない(NOT RECOMMENDED)。なぜなら、認証情報を(URIの ような)平文で受け渡しするのはセキュリティ上危険があることが、今までの使 用例のほとんどすべての場合に証明されているからである。 The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported. hostは、ネットワークホストのドメイン名、又は4個の10進法数値を"."で区切っ た組で表したIPv4addressである。リテラルIPv6アドレスはサポートされない。 hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit Hostnames take the form described in Section 3 of [RFC1034] and Section 2.1 of [RFC1123]: 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 will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain. To actually be "Uniform" as a resource locator, a URL hostname should be a fully qualified domain name. In practice, however, the host component may be a local domain literal. hostnameは[RFC1034]のSection 3及び[RFC1123]のSection 2.1で記述されている 書式をとる。つまりドメインラベルを"."で区切った連鎖で、各ドメインラベル は最初と最後が英数字であり、途中には文字"-"も含むことがある。完全修飾ド メイン名の右端のdomainlabelは数字で始まることは決してない。これにより、 ドメイン名をIPv4アドレスと構文的に区別できる。また、??完全ドメイン名と何 らかのローカルドメインを区別する必要があるならば、後ろに単独の"."を付け ることができる。資源位置指定子として本当の意味で「統一書式」であるため に、URL hostnameは完全修飾ドメイン名であるべきである。しかし実際には、 host成分はローカルドメインリテラルであってもよい。 Note: A suitable representation for including a literal IPv6 address as the host part of a URL is desired, but has not yet been determined or implemented in practice. 注: リテラルIPv6アドレスをURLのhost部分として含めるための適切な表現方法 が望まれるが、実際には未だ確定も実装もされていない。 The port is the network port number for the server. Most schemes designate protocols that have a default port number. Another port number may optionally be supplied, in decimal, separated from the host by a colon. If the port is omitted, the default port number is assumed. portはサーバのネットワークポート番号である。たいていのスキームが指定する プロトコルは既定ポート番号を持つ。選択肢として別のポート番号を指定するこ とができる。番号は10進法で表し、hostとの間をコロンで区切る。portが省略さ れた場合、既定ポート番号が仮定される。 3.3 パス成分 (Path Component) The path component contains data, specific to the authority (or the scheme if there is no authority component), identifying the resource within the scope of that scheme and authority. パス成分は、機関(オーソリティ成分が存在しない場合はスキーム)特有であり、 そのスキーム及び機関の有効範囲内で資源を特定するデータからなる。 path = [ abs_path | opaque_part ] path_segments = segment *( "/" segment ) segment = *pchar *( ";" param ) param = *pchar pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," The path may consist of a sequence of path segments separated by a single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references. pathはパスセグメントを並べたもので、各セグメントは単一のスラッシュ"/"で 区切る。パスセグメントの中では、文字"/"、";"、"="は予約されている。各パ スセグメントはそれぞれパラメタ列を含むことができ、パラメタはセミコロン文 字";"を印とする。パラメタは相対参照の構文解析時には意味を持たない。 3.4. クエリー成分 (Query Component) The query component is a string of information to be interpreted by the resource. クエリー成分は資源によって解釈される情報文字列である。 query = *uric Within a query component, the characters ";", "/", "?", ":", "@", "&", "=", "+", ",", and "$" are reserved. クエリー成分中では、文字";"、"/"、"?"、":"、"@"、"&"、"="、"+"、","、及 び"$"は予約されている。 4. URI参照 (URI References) The term "URI-reference" is used here to denote the common usage of a resource identifier. A URI reference may be absolute or relative, and may have additional information attached in the form of a fragment identifier. However, "the URI" that results from such a reference includes only the absolute URI after the fragment identifier (if any) is removed and after any relative URI is resolved to its absolute form. Although it is possible to limit the discussion of URI syntax and semantics to that of the absolute result, most usage of URI is within general URI references, and it is impossible to obtain the URI from such a reference without also parsing the fragment and resolving the relative form. ここでは、用語"URI-reference"は資源識別子の慣用法を示す意味で用いる。URI 参照は絶対参照の場合も相対参照の場合もあり、追加情報が部分識別子の書式で 付加されている場合もある。しかし、そのような参照から生じる「URIそのも の」は、(もしあれば)部分識別子を除去し、相対URIはその絶対書式に解決した 後の、絶対URIのみからなる。URIの構文と意味についての議論を絶対URIに限る ことも可能ではあるが、URIは一般URI参照の中で使われることが多く、そのよう な参照からURIを得るには部分識別子の構文解析及び相対書式の解決なしでは不 可能である。 URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] The syntax for relative URI is a shortened form of that for absolute URI, where some prefix of the URI is missing and certain path components ("." and "..") have a special meaning when, and only when, interpreting a relative path. The relative URI syntax is defined in Section 5. 相対URIの構文は絶対URIを短縮した書式で、URIの前方部分が失われ、特定の path成分("."及び"..")が相対パスの解釈時に、そしてその時にのみ、特別の意 味を持つ。相対URI構文はSection 5で定義する。 4.1. 部分識別子 (Fragment Identifier) When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. URI参照がそれによって特定される資源に対し取得動作を実行するため用いられ る場合、選択肢として部分識別子を、シャープ記号"#"で区切って付けることが できる。これは付加的な参照情報であり、取得動作が成功した後でユーザエージ ェントが解釈する。そういうものであるから、これはURIの一部分ではないが、 しばしばURIとともに用いられる。 fragment = *uric The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. The character restrictions described in Section 2 for URI also apply to the fragment in a URI-reference. Individual media types may define additional restrictions or structure within the fragment for specifying different types of "partial views" that can be identified within that media type. 部分識別子の意味は、その参照で用いたURIの型が何であれ、取得動作の結果と して得られたデータが持つ特性である。それゆえ、部分識別子の書式及び解釈は 取得結果のメディア型[RFC2046]に依存する。Section 2に記述されたURIに対す る文字制限はURI-reference中の部分識別子にも適用される。個々のメディア型 は部分識別子に対して付加的に制限又は構造を定義することができ、それにより メディア型の中で定義できる様々な型の?*"partial views"を指定できる。 A fragment identifier is only meaningful when a URI reference is intended for retrieval and the result of that retrieval is a document for which the identified fragment is consistently defined. 部分識別子は、URI参照が取得を意図したものであって、取得の結果得られたも のが文書であり、指定された部分がその文書の中で矛盾なく定義されている場合 にのみ意味を持つ。 4.2 同一文書参照　(Same-document References) A URI reference that does not contain a URI is a reference to the current document. In other words, an empty URI reference within a document is interpreted as a reference to the start of that document, and a reference containing only a fragment identifier is a reference to the identified fragment of that document. Traversal of such a reference should not result in an additional retrieval action. However, if the URI reference occurs in a context that is always intended to result in a new request, as in the case of HTML's FORM element, then an empty URI reference represents the base URI of the current document and should be replaced by that URI when transformed into a request. URIを含んでいないURI参照は当該文書への参照である。言い換えれば、文書中の 空URI参照はその文書の先頭への参照として解釈され、部分識別子のみを含む参 照はその文書の指定された部分への参照である。そのような参照での移動が、再 び取得動作を行う結果となるべきではない。しかし、HTMLのFORM要素のように、 そのURI参照が常に新たなリクエストを発生するよう意図する文脈で出現してい る場合、空URI参照は当該文書の基底URIを表し、リクエストへと変換される際に そのURIへと置換されるべきである。 4.3. URI参照の構文解析 (Parsing a URI Reference) A URI reference is typically parsed according to the four main components and fragment identifier in order to determine what components are present and whether the reference is relative or absolute. The individual components are then parsed for their subparts and, if not opaque, to verify their validity. URI参照は通常は、4個の主成分と部分識別子に照らして構文解析し、どの成分が 存在するか、相対参照か絶対参照か、を確定する。その後で個々の成分をそれぞ れの副成分へと構文解析し、さらに、オペークでなければ、妥当性を確認する。 Although the BNF defines what is allowed in each component, it is ambiguous in terms of differentiating between an authority component and a path component that begins with two slash characters. The greedy algorithm is used for disambiguation: the left-most matching rule soaks up as much of the URI reference string as it is capable of matching. In other words, the authority component wins. BNFはそれぞれの成分中でいかなる形が許されるかを定義しているが、オーソリ ティ成分と2つのスラッシュ文字から始まるパス成分とを区別する点については 不明確である。不明確でなくするために、どん欲なアルゴリズムが用いられる。 最左端マッチ規則は、URI参照文字列の多くをマッチ可能として取り込む。言い 換えれば、オーソリティ成分が優先される。 Readers familiar with regular expressions should see Appendix B for a concrete parsing example and test oracle. 正規表現に慣れた読者は、構文解析の具体例と?*test oracleを記述した附属書B を参照するのが望ましい。 5. 相対URI参照 (Relative URI References) It is often the case that a group or "tree" of documents has been constructed to serve a common purpose; the vast majority of URI in these documents point to resources within the tree rather than outside of 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. 1つの共通目的を果たすために、文書が集団又は「ツリー」を構成している場合 がよくある。これらの文書中のURIは、大部分がツリー内の資源を指定し、ツ リー外への指定はそれに比べ少ない。同様に、ある特定のサイトにある文書は、 そのほとんどが当該サイトにある他の資源を参照し、それに比べると外部サイト の資源への参照は少ない。 Relative addressing of URI 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 using relative URI. Furthermore, such document trees can be moved, as a whole, without changing any of the relative references. Experience within the WWW has demonstrated that the ability to perform relative referencing is necessary for the long-term usability of embedded URI. URIを相対指定することにより、文書ツリーをその配置場所及びアクセススキー ムからある程度独立にできる。例えば、一組のハイパーテキスト文書について、 互いの文書への参照に相対URIを使っていれば、スキーム"file"、"http"、"ftp" のいずれを使う場合でも、アクセス及び互いへの移動ができる。さらに、そのよ うな文書ツリーを、どの相対参照も変更せずに、丸ごと移転することができる。 WWWでの実例により、埋め込まれたURIが長期にわたり有効であるためには、相対 参照が可能であることが必要不可欠だと実証されている。 The syntax for relative URI takes advantage of the syntax of (Section 3) in order to express a reference that is relative to the namespace of another hierarchical URI. 相対URIの構文では、すでにある (Section 3) での構 文を利用する形で、別階層のURIの名前空間に対する参照を表現する。 relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ] A relative reference beginning with two slash characters is termed a network-path reference, as defined by in Section 3. Such references are rarely used. 2つのスラッシュ文字から始まる相対参照は、ネットワークパス参照と呼び、 Section 3でと定義している。そのような参照はほとんど用いられな い。 A relative reference beginning with a single slash character is termed an absolute-path reference, as defined by in Section 3. 1つのスラッシュ文字から始まる相対参照は、絶対パス参照と呼び、Section 3で と定義している。 A relative reference that does not begin with a scheme name or a slash character is termed a relative-path reference. スキーム名でもスラッシュ文字でも始まらない相対参照は、相対パス参照と呼 ぶ。 rel_path = rel_segment [ abs_path ] rel_segment = 1*( unreserved | escaped | ";" | "@" | "&" | "=" | "+" | "$" | "," ) Within a relative-path reference, the complete path segments "." and ".." have special meanings: "the current hierarchy level" and "the level above this hierarchy level", respectively. Although this is very similar to their use within Unix-based filesystems to indicate directory levels, these path components are only considered special when resolving a relative-path reference to its absolute form (Section 5.2). 相対パス参照中では、完全パスセグメント"."及び".."は特別な意味を持つ。そ れぞれ「現在の階層」及び「現在の階層の上の階層」である。これはUNIXベース のファイルシステムでディレクトリ階層を表す際の使用法と非常によく似ている が、これらのパス成分は相対パス参照をその絶対書式に解決する(Section 5.2) 時にのみ特別視される。 Authors should be aware that a path segment which contains a colon character cannot be used as the first segment of a relative URI path (e.g., "this:that"), because it would be mistaken for a scheme name. コロン文字が含まれるパスセグメントを相対URIパスの最初のセグメントに使う (例えば"this:that")ことはできないことを承知しておくのが望ましい。なぜな ら、スキーム名と誤解釈される恐れがあるからである。 It is therefore necessary to precede such segments with other segments (e.g., "./this:that") in order for them to be referenced as a relative path. 従って、それらのパスセグメントを相対パスとして参照するためには、別のセグ メントを前に置く(例えば"./this:that")必要がある。 It is not necessary for all URI within a given scheme to be restricted to the syntax, since the hierarchical properties of that syntax are only necessary when relative URI are used within a particular document. Documents can only make use of relative URI when their base URI fits within the syntax. It is assumed that any document which contains a relative reference will also have a base URI that obeys the syntax. In other words, relative URI cannot be used within a document that has an unsuitable base URI. 必ずしも、あるスキームに属するすべてのURIが構文に制限されるわ けではない。なぜなら、構文が階層に関する特性を必要とするのは、個々の文書 において相対URIが使われる場合のみだからである。文書で相対URIを使用できる のは、文書の基底URIが構文に適合する場合のみである。相対参照を 含む文書は、この構文に従う基底URIも持っているものと仮定される。言い換え れば、相対URIは適切な基底URIを持たない文書中では使用できない。 Some URI schemes do not allow a hierarchical syntax matching the syntax, and thus cannot use relative references. URIスキームによっては、構文にマッチする階層的構文を許容しない ものがあり、その場合は相対参照を使用できない。 5.1. 基底URIの設定 (Establishing a Base URI) The term "relative URI" implies that there exists some absolute "base URI" against which the relative reference is applied. Indeed, the base URI is necessary to define the semantics of any relative URI reference; without it, a relative reference is meaningless. In order for relative URI to be usable within a document, the base URI of that document must be known to the parser. 「相対URI」という用語は、その相対参照を適用する対象となる何らかの絶対的 な「基底URI」が存在するということを含意している。実際に、いかなる相対URI 参照もその意味を決定するために基底URIを必要とする。基底URIがなければ、相 対参照は意味をなさない。相対URIが文書中で使用できるためには、その文書の 基底URIを構文解析器に知らせなければならない。 The base URI of a document can be established in one of four ways, listed 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: 文書の基底URIは、以下の順で優先される4つの手段のうちの1つによって設定す る。優先度は層の観点で考えることができ、最も内側で定義された基底URIが最 も優先度が高い。 このことは次のように図示することができる。 .----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | .----------------------------------. | | | | | | | | | | | | | | | | | | `----------------------------------' | | | | | | | | (5.1.1) Base URI embedded in the | | | | | | | | document's content | | | | | | | `----------------------------------------' | | | | | | (5.1.2) Base URI of the encapsulating entity | | | | | | (message, document, or none). | | | | | `----------------------------------------------' | | | | (5.1.3) URI used to retrieve the entity | | | `----------------------------------------------------' | | (5.1.4) Default Base URI is application-dependent | `----------------------------------------------------------' .----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | .----------------------------------. | | | | | | | | | | | | | | | | | | `----------------------------------' | | | | | | | | (5.1.1) 文書内容に埋め込まれた | | | | | | | | 基底URI | | | | | | | `----------------------------------------' | | | | | | (5.1.2) カプセル化された実体の基底URI | | | | | | (メッセージ、文書、又は?*none) | | | | | `----------------------------------------------' | | | | (5.1.3) その実体を取得する際に使用したURI | | | `----------------------------------------------------' | | (5.1.4) アプリケーションに依存する既定の基底URI | `----------------------------------------------------------' 5.1.1. 文書内容に含まれた基底URI (Base URI within Document Content) Within certain document media types, the base URI of the document can be embedded within the content itself such that it can be readily obtained by a parser. This can be useful for descriptive documents, such as tables of content, which may be transmitted to others through protocols other than their usual retrieval context (e.g., E-Mail or USENET news). ある種の文書メディア型の中では、構文解析器がすぐ利用できるように、文書の 基底URIをその文書の内容中に埋め込むことができる。このことは、目次のよう な説明用文書を、通常の取得手段とは異なるプロトコル(電子メールやUSENETニ ュースなど)を通じて送る際に役立つ。 It is beyond the scope of this document to specify how, for each media type, the base URI can be embedded. It is assumed that user agents manipulating such media types will be able to obtain the appropriate syntax from that media type's specification. An example of how the base URI can be embedded in the Hypertext Markup Language (HTML) [RFC1866] is provided in Appendix D. どうすれば基底URIを埋め込むことができるかを各メディア型について規定する のはこの文書の範囲を外れる。そのようなメディア型を扱うユーザエージェント については、それぞれのメディア型の仕様書から適切な構文を得られるものと仮 定する。基底URIのハイパーテキストマーク付け言語(HTML) [RFC1866]への埋め 込み例は、附属書Dにある。 A mechanism for embedding the base URI within MIME container types (e.g., the message and multipart types) is defined by MHTML [RFC2110]. Protocols that do not use the MIME message header syntax, but which do allow some form of tagged metainformation to be included within messages, may define their own syntax for defining the base URI as part of a message. 基底URIをMIMEコンテナ型(メッセージ及びマルチパート型など)の中に埋め込む 機構については、MHTML [RFC2110]で定義している。MIMEメッセージヘッダ構文 を使用しないが、何らかの書式でタグ付けしたメタ情報をメッセージ内に含むこ とを許容するプロトコルは、基底URIをメッセージの一部という形で定義するた めの独自構文を定義することができる。 5.1.2. カプセル化された実体による基底URI (Base URI from the Encapsulating Entity) If no base URI is embedded, the base URI of a document is defined by the document's retrieval context. For a document that is enclosed within another entity (such as a message or another document), the retrieval context is that entity; thus, the default base URI of the document is the base URI of the entity in which the document is encapsulated. 基底URIが埋め込まれていない場合、文書の基底URIはその文書の取得状況によっ て決まる。ある文書が他の実体(メッセージ又は別の文書など)の中に内包されて いる場合、取得状況とはその実体のことである。従って、その文書の基底URI は、その文書を中にカプセル化している実体の基底URIである。 5.1.3. 取得URIによる基底URI (Base URI from the Retrieval URI) If no base URI is embedded and the document is not encapsulated within some other entity (e.g., the top level of a composite entity), then, if a URI was used to retrieve the base document, 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., that which resulted in the actual retrieval of the document) is the base URI. 基底URIが埋め込まれておらず、その文書が他の何らかの実体にカプセル化され ていない場合(複合構造実体の最上層など)、その基底文書の取得にURIが使用さ れていれば、そのURIを基底URIと見なすのが当然であろう。注意すべき点として は、取得時にリクエストがリダイレクトされていた場合は、使用された最後の URI(つまり、実際に文書の取得をしたURI)が基底URIとなる。 5.1.4. 既定値の基底URI (Default Base URI) If none of the conditions described in Sections 5.1.1--5.1.3 apply, then the base URI is defined by the context of the application. Since this definition is necessarily application-dependent, failing to define the base URI using one of the other methods may result in the same content being interpreted differently by different types of application. Section 5.1.1.から5.1.3.で記述した条件のいずれも当てはまらない場合、基底 URIはアプリケーションの状況により定める。この決定方法は必然的にアプリ ケーション依存であるから、他の手段を使って基底URIを定めることに失敗した 場合、型の異なるアプリケーションでは同一内容が異なって解釈されることもあ り得る。 It is the responsibility of the distributor(s) of a document containing relative URI to ensure that the base URI for that document can be established. It must be emphasized that relative URI cannot be used reliably in situations where the document's base URI is not well-defined. 相対URIを含む文書の基底URIを確実に画定できるようにすることは、文書配布者 の責務である。文書の基底URIが明確でない状況では、相対URIを信頼して使用で きないことは強調する必要がある。 5.2. 相対参照の絶対書式への解決 (Resolving Relative References to Absolute Form) This section describes an example algorithm for resolving URI references that might be relative to a given base URI. この節では、所定の基底URIに対する相対参照と思われるURI参照を解決するため のアルゴリズム例を記述する。 The base URI is established according to the rules of Section 5.1 and parsed into the four main components as described in Section 3. Note that only the scheme component is required to be present in the base URI; the other components may be empty or undefined. A component is undefined if its preceding separator does not appear in the URI reference; the path component is never undefined, though it may be empty. The base URI's query component is not used by the resolution algorithm and may be discarded. 基底URIはSection 5.1の規則に従って画定され、Section 3で記述したように4個 の主成分へと構文解釈される。注意すべき点は、基底URI中に必要とされる成分 は、スキーム成分のみであることである。他の成分は空であったり未定義であっ てもよい。成分が未定義であるとは、URI参照中にその成分の先導分離子が出現 していないことである。パス成分は、たとえ空であっても、決して未定義ではな い。基底URIのクエリー成分は解決アルゴリズムでは使用しないので、破棄して よい。 For each URI reference, the following steps are performed in order: URI参照に対しては、下記の段階が順に実行される。 1) The URI reference is parsed into the potential four components and fragment identifier, as described in Section 4.3. 1) Section 4.3.の記述に従い、URI参照をそれが持ち得る4個の成分と部分識別 子に構文解析する。 2) If the path component is empty and the scheme, authority, and query components are undefined, then it is a reference to the current document and we are done. Otherwise, the reference URI's query and fragment components are defined as found (or not found) within the URI reference and not inherited from the base URI. 2) もしパス成分が空であり、スキーム、オーソリティ、及びクエリー成分が定 義されていなければ、それは当該文書への参照であり、解析は終了する。そうで なければ、参照URIのクエリー成分および部分識別子はそのURI参照内に存在する (または存在しない)形で定義され、基底URIからは継承しない。 3) If the scheme component is defined, indicating that the reference starts with a scheme name, then the reference is interpreted as an absolute URI and we are done. Otherwise, the reference URI's scheme is inherited from the base URI's scheme component. 3) もしスキーム成分が定義されている、つまり参照がスキーム名から始まる形 で表されているならば、その参照は絶対URIであり、解析は終了する。そうでな ければ、参照URIのスキームは基底URIのスキーム成分から継承される。 Due to a loophole in prior specifications [RFC1630], some parsers allow the scheme name to be present in a relative URI if it is the same as the base URI scheme. Unfortunately, this can conflict with the correct parsing of non-hierarchical URI. For backwards compatibility, an implementation may work around such references by removing the scheme if it matches that of the base URI and the scheme is known to always use the syntax. The parser can then continue with the steps below for the remainder of the reference components. Validating parsers should mark such a misformed relative reference as an error. 以前の仕様 [RFC1630]の?*抜け穴のために、構文解析器の中には、基底URIのス キームと同じであれば、相対URI中であってもスキーム名の存在を許容するもの がある。残念ながら、このことは非階層的URIを正しく構文解析する際に衝突を 起こし得る。下位互換性のために、処理系はこのような参照に対処するために、 スキーム名が基底URIとマッチし、そのスキームが常に構文を用いる ことが知られている場合、スキーム名を除去してもよい。そうすれば、構文解析 器は参照のうち残っている成分に対し、以下の段階を継続できる。妥当性判定を 行う構文解析器は、このような書式に誤りがある相対参照をエラーと判定するべ きである。 4) If the authority component is defined, then the reference is a network-path and we skip to step 7. Otherwise, the reference URI's authority is inherited from the base URI's authority component, which will also be undefined if the URI scheme does not use an authority component. 4) もしオーソリティ成分が定義されているならば、その参照はネットワークパ スであり、7)へ移動する。そうでなければ、参照URIのオーソリティ成分は基底 URIのオーソリティ成分から継承される。もしそのURIのスキームがオーソリティ 成分を使用しないのであれば、参照URIのオーソリティ成分もまた定義されな い。 5) If the path component begins with a slash character ("/"), then the reference is an absolute-path and we skip to step 7. 5) もしパス成分が1個のスラッシュ文字("/")から始まっているならば、その参 照は絶対パスであり、7)へ移動する。 6) If this step is reached, then we are resolving a relative-path reference. The relative path needs to be merged with the base URI's path. Although there are many ways to do this, we will describe a simple method using a separate string buffer. 6) もしこの段階に達したら、相対パス参照を解釈していることになる。相対パ スは基底URIのパスと結合する必要がある。これを実行するには多数の方法があ るが、ここでは単純な、別個の文字列バッファを使用する方法を説明する。 a) All but the last segment of the base URI's path component is copied to the buffer. In other words, any characters after the last (right-most) slash character, if any, are excluded. a) 基底URIのパス成分のうち最後のセグメント以外をバッファに複写する。言い かたを変えれば、最後の(最も右の)スラッシュ文字以降にもし文字があれば、そ れらの文字は除外される。 b) The reference's path component is appended to the buffer string. b) 参照のパス成分をバッファの文字列の後に添加する。 c) All occurrences of "./", where "." is a complete path segment, are removed from the buffer string. c) "."がそれ自身で1個の完全パスセグメントである"./"が出現していれば、そ れらをすべてバッファ文字列から除去する。 d) If the buffer string ends with "." as a complete path segment, that "." is removed. d) もしバッファの文字列が、完全パスセグメントである"."で終わっているなら ば、"."を除去する。 e) All occurrences of "/../", where is a complete path segment not equal to "..", are removed from the buffer string. Removal of these path segments is performed iteratively, removing the leftmost matching pattern on each iteration, until no matching pattern remains. e) "/../"という文字列が出現し、が1個の完全パスセグメン トであってかつ".."とは等しくない場合、それらの文字列をバッファ文字列から 除去する。これらのパスセグメント除去は反復して行う。各反復ごとに最も左側 でマッチするパターンから除去し、マッチするパターンが存在しなくなるまで繰 り返す。 f) If the buffer string ends with "/..", where is a complete path segment not equal to "..", that "/.." is removed. f) もしバッファ文字列が"/.."という文字列で、は1個の完 全パスセグメントであってかつ".."とは等しくない場合、この"/.."を 除去する。 g) If the resulting buffer string still begins with one or more complete path segments of "..", then the reference is considered to be in error. Implementations may handle this error by retaining these components in the resolved path (i.e., treating them as part of the final URI), by removing them from the resolved path (i.e., discarding relative levels above the root), or by avoiding traversal of the reference. g) もし残りのバッファ文字列がなお1個以上の".."という完全パスセグメントで 始まっているならば、その参照はエラーであると見なされる。処理系はこのエ ラーを、解決したパス中の成分としてそのまま残す(つまり、それらを最終的な URIの一部分として扱う)、解決したパスから除去する(つまりルートより上の相 対レベルを取り除く)、又はその参照への移動を無効とする、のいずれの方法で 扱ってもよい。 h) The remaining buffer string is the reference URI's new path component. h) 残ったバッファ文字列が、参照URIの新たなパス成分である。 7) The resulting URI components, including any inherited from the base URI, are recombined to give the absolute form of the URI reference. Using pseudocode, this would be result = "" if scheme is defined then append scheme to result append ":" to result if authority is defined then append "//" to result append authority to result append path to result if query is defined then append "?" to result append query to result if fragment is defined then append "#" to result append fragment to result return result 7)基底URIからの継承も含む残ったURI成分は、URI参照の絶対書式を得るために 再結合される。疑似コードを用いれば、以下の結果が返値となる。 (スキームが定義されていれば、スキームと":"を添加する。 authorityが定義されていれば、"//"とauthorityを添加する。 pathを添加する。 queryが定義されていれば、?とqueryを添加する。 部分識別子が定義されていれば、"#"と部分識別子を添加する。) Note that we must be 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. 注意すべき点として、定義されていない、つまりその分離子が参照中に出現しな かった成分と、空である、つまり分離子が出現し、かつそのすぐ後続が次の成分 の分離子又は参照の終了である成分との区別をしっかり維持する必要がある。 The above algorithm is intended to provide an example by which the output of implementations can be tested -- implementation of the algorithm itself is not required. For example, some systems may find it more efficient to implement step 6 as a pair of segment stacks being merged, rather than as a series of string pattern replacements. 上記のアルゴリズムは、処理系の出力を試験するための例を提供することを意図 しており、このアルゴリズムそのものの実装を要求するものではない。例えばシ ステムによってはstep 6を実装する際に、文字列パターン置換の繰り返しではな く、2個のセグメントスタックを併合する方法を採った方がより効果的であろ う。 Note: Some WWW client applications will fail to separate the reference's query component from its path component before merging the base and reference paths in step 6 above. This may result in a loss of information if the query component contains the strings "/../" or "/./". 注:WWWクライアントアプリケーションの中には、上記step 6に規定された基底 URIのパスと参照のパスの併合を行う前に参照のクエリー成分を分離することが できないものもある。このような場合、クエリー成分に文字列"/../"又は"/./" が含まれていると、情報を失う結果となる。 Resolution examples are provided in Appendix C. 解決の例を附属書Cで挙げている。 6. URIの正規化と同値 (URI Normalization and Equivalence) In many cases, different URI strings may actually identify the identical resource. For example, the host names used in URL are actually case insensitive, and the URL is equivalent to . In general, the rules for equivalence and definition of a normal form, if any, are scheme dependent. When a scheme uses elements of the common syntax, it will also use the common syntax equivalence rules, namely that the scheme and hostname are case insensitive and a URL with an explicit ":port", where the port is the default for the scheme, is equivalent to one where the port is elided. 異なるURI文字列が実際にはまったく同じ資源を指定することがしばしばある。 例えば、URL中ではホスト名は大文字小文字を区別しないので、 というURLはと同値である。一 般に、同値判断規則及び標準書式の定義は、それが存在する場合、スキームに依 存する。あるスキームが一般構文の要素を使用しているならば、一般構文同値判 断規則も使用する。すなわち、スキームとホスト名は大文字小文字を区別せず、 スキーム既定のポートを":port"として明示したURLはポートを記述していない URLと同値である。 7. 安全性の考察 (Security Considerations) A URI does not in itself pose a security threat. Users should beware that there is no general guarantee that a URL, which at one time located a given resource, will continue to do so. Nor is there any guarantee that a URL will not locate a different resource at some later point in time, due to the lack of any constraint on how a given authority apportions its namespace. Such a guarantee can only be obtained from the person(s) controlling that namespace and the resource in question. A specific URI scheme may include additional semantics, such as name persistence, if those semantics are required of all naming authorities for that scheme. URIそれ自身は安全性に関して問題を引き起こすことはない。利用者は、ある時 点である特定の資源の位置を指定していたURLが、将来もその状態であるという 保証は一般に存在しないことに注意すべきである。??また、わずかしか時間が経 過していなければ、あるURLが以前と異なる資源を位置指定しているということ はない、という保証もない。これはオーソリティがその名前空間を割り当てる方 法に制限がないからである。これらの保証は、名前空間と当該資源の管理者以外 からは得られない。あるURIスキームの命名機関すべてで特定の意味が必要であ る場合、そのURIスキームは名前永続性などの付加的意味を含むことがある。 It is sometimes possible to construct a URL such that an attempt to perform a seemingly harmless, idempotent operation, such as the retrieval of an entity associated with the resource, will in fact cause a possibly damaging remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is in fact running a different protocol. The content of the URL contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URL to cause an unintended or impersonating message to be sent via a SMTP server. ある資源についてそれに対応する実体を取得するような、一見したところ無害 な、同等の操作のように思えながら、実際には障害の発生する遠隔操作を引き起 こしかねないURLを構成できてしまうことがある。そうした安全でないURLを構成 するのは、概して当該のネットワークプロトコルで予約されていないポート番号 を指定した場合である。クライアントは、それとは知らず、実際には異なったプ ロトコルで作動しているサイトへと接触する。当該URLの内容には、この別のプ ロトコルに従って解釈されたとき、予期せぬ操作を引き起こすような指示が含ま れている。例えば、gopher URLを使用した時に、意図しない、あるいは他の人に なったかのようなメッセージをSMTPサーバを通じて発信してしまうことがある。 Caution should be used when using any URL that specifies a port number other than the default for the protocol, especially when it is a number within the reserved space. 当該プロトコルの既定値と異なるポート番号を指定するURLを使う場合、それが 予約空間内の番号である場合は特に、警告を発するのが望ましい。 Care should be taken when a URL contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be performed. あるURLが、当該プロトコルの区切り子(例えば、telnetプロトコルにおけるCR及 びLF文字)をエスケープしたものを含む場合、それらを送信前にエスケープ解除 しないように注意するべきである。この処置は当該プロトコルに違反しているこ とがあるが、それらの文字は当該プロトコルにおいて特殊な操作又はパラメタの 役割を果たし、予期せぬ、たいていは有害な遠隔操作を引き起こしかねないた め、この処置によりそのような機能を無効とできるだろう。 It is clearly unwise to use a URL that contains a password which is intended to be secret. In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public. 秘密としたいパスワードを内容として含むURLを使用するのは明らかに思慮が足 りない行為である。特に、URLの'userinfo'成分内でパスワードを使用するの は、'password'パラメタの公開を意図するようなまれな場合を除き、強く非推奨 とする。 8. 謝辞 (Acknowledgements) This document was derived from RFC 1738 [RFC1738] and RFC 1808 [RFC1808]; the acknowledgements in those specifications still apply. In addition, contributions by Gisle Aas, Martin Beet, Martin Duerst, Jim Gettys, Martijn Koster, Dave Kristol, Daniel LaLiberte, Foteos Macrides, James Marshall, Ryan Moats, Keith Moore, and Lauren Wood are gratefully acknowledged. この文書はRFC 1738 [RFC1738]及びRFC 1808 [RFC1808]から派生したものであ る。これらの仕様書における謝辞はこの文書でも適用される。さらに、 Gisle Aas, Martin Beet, Martin Duerst, Jim Gettys, Martijn Koster, Dave Kristol, Daniel LaLiberte, Foteos Macrides, James Marshall, Ryan Moats, Keith Moore, 及びLauren Woodによる寄与に対し、感謝の意を表す る。 9. 参照 (References) [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [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. [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC1866] Berners-Lee T., and D. Connolly, "HyperText Markup Language Specification -- 2.0", RFC 1866, November 1995. [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995. [RFC2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC2110] Palme, J., and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997. [RFC1737] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [ASCII] US-ASCII. "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 10. 著者連絡先 (Authors' Addresses) Tim Berners-Lee World Wide Web Consortium MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge, MA 02139 Fax: +1(617)258-8682 EMail: timbl@w3.org Roy T. Fielding Department of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 Fax: +1(949)824-1715 EMail: fielding@ics.uci.edu Larry Masinter Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94034 Fax: +1(415)812-4333 EMail: masinter@parc.xerox.com A. URIに関するBNFの一覧 (Collected BNF for URI) URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] absoluteURI = scheme ":" ( hier_part | opaque_part ) relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ] hier_part = ( net_path | abs_path ) [ "?" query ] opaque_part = uric_no_slash *uric uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," net_path = "//" authority [ abs_path ] abs_path = "/" path_segments rel_path = rel_segment [ abs_path ] rel_segment = 1*( unreserved | escaped | ";" | "@" | "&" | "=" | "+" | "$" | "," ) scheme = alpha *( alpha | digit | "+" | "-" | "." ) authority = server | reg_name reg_name = 1*( unreserved | escaped | "$" | "," | ";" | ":" | "@" | "&" | "=" | "+" ) server = [ [ userinfo "@" ] hostport ] userinfo = *( unreserved | escaped | ";" | ":" | "&" | "=" | "+" | "$" | "," ) hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit path = [ abs_path | opaque_part ] path_segments = segment *( "/" segment ) segment = *pchar *( ";" param ) param = *pchar pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," query = *uric fragment = *uric uric = reserved | unreserved | escaped reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" escaped = "%" hex hex hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" alphanum = alpha | digit alpha = lowalpha | upalpha lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" B. 正規表現によるURI参照の構文解釈 (Parsing a URI Reference with a Regular Expression) As described in Section 4.3, the generic URI syntax is not sufficient to disambiguate the components of some forms of URI. Since the "greedy algorithm" described in that section is identical to the disambiguation method used by POSIX regular expressions, it is natural and commonplace to use a regular expression for parsing the potential four components and fragment identifier of a URI reference. Section 4.3で記述したように、共通URI構文は、URI書式によってはその成分を 明確にする上で十分ではない。Section 4.3で記述した「どん欲なアルゴリズ ム」はPOSIX正規表現で用いられる明確化手法とまったく同じものであるため、 あるURI参照に含まれている可能性のある4種の成分と部分識別子を構文解析する 際に正規表現を用いるのは自然かつ当然のことである。 The following line is the regular expression for breaking-down a URI reference into its components. 下記の行は、あるURI参照をその成分へと分解するための正規表現である。 ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9 The numbers in the second line above are only to assist readability; they indicate the reference points for each subexpression (i.e., each paired parenthesis). We refer to the value matched for subexpression as $. For example, matching the above expression to 上記2行目の番号は、ただ読みやすさのためのものである。これらは各部分表現 (つまり、それぞれの括弧の組)の参照個所を示している。部分表現にマッチ する値を$で表す。例えば、上記の表現を 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 = $7 = $8 = #Related $9 = Related where 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 four components and fragment as ここで、はこの成分が存在しないことを示しており、上記の例では クエリー成分がそれにあたる。従って、4種の成分と部分識別子は、 scheme = $2 authority = $4 path = $5 query = $7 fragment = $9 and, going in the opposite direction, we can recreate a URI reference from its components using the algorithm in step 7 of Section 5.2. であると確定でき、そこから逆方向にたどることにより、Section 5.2のstep 7 のアルゴリズムを用いて、成分からURI参照を再生成できる。 C. 相対URI参照解決の例 (Examples of Resolving Relative URI References) Within an object with a well-defined base URI of 形式の整った基底URI http://a/b/c/d;p?q the relative URI would be resolved as follows: を持つオブジェクト内では、相対URIは以下のように解決されるであろう。 C.1. 正常な例 (Normal Examples) 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/?y g?y = http://a/b/c/g?y #s = (current document)#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/ ./ = http://a/b/c/ .. = http://a/b/ ../ = http://a/b/ ../g = http://a/b/g ../.. = http://a/ ../../ = http://a/ ../../g = http://a/g C.2. 異常な例 (Abnormal Examples) 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 above. 以下の異常な例は通常の状況ではまず起こらないが、すべてのURI構文解析器は これらをも同様に解決できることが望まれる。どの例も上記の基底URIを用い る。 An empty reference refers to the start of the current document. 空の参照は、当該文書の先頭を参照する。 <> = (current document) Parsers must be careful in handling the case where there are more relative path ".." segments than there are hierarchical levels in the base URI's path. Note that the ".." syntax cannot be used to change the authority component of a URI. 構文解析器、基底URIのパスに含まれる階層レベルより相対パスの".."セグメン トの数が多い場合、扱いに注意する必要がある。".."構文はURIのオーソリティ 成分を変更するためには使用できないことに注意すること。 ../../../g = http://a/../g ../../../../g = http://a/../../g In practice, some implementations strip leading relative symbolic elements (".", "..") after applying a relative URI calculation, based on the theory that compensating for obvious author errors is better than allowing the request to fail. Thus, the above two references will be interpreted as "http://a/g" by some implementations. 実際には、その要求を失敗に終わらせるより著者の明らかなエラーを補正した方 がよいという理屈に基づき、相対URIの算出後に先頭部の相対記号要素("."又は "..")を取り除く処理系もある。従って、上記の2個の参照はそのような処理系で は"http://a/g"と解釈されるであろう。 Similarly, parsers must avoid treating "." and ".." as special when they are not complete components of a relative path. 同様に、構文解析器は"."及び".."について、それらが相対パスの完全成分では ない場合、特殊な扱いを避けなければならない。 /./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 URI uses unnecessary or nonsensical forms of the "." and ".." complete path segments. さらにめったにないことだが、相対URIが"."及び".."の完全パスセグメントを不 必要な又は無意味な書式で用いている場合がある。 ./../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 All client applications remove the query component from the base URI before resolving relative URI. However, some applications fail to separate the reference's query and/or fragment components from a relative path before merging it with the base path. This error is rarely noticed, since typical usage of a fragment never includes the hierarchy ("/") character, and the query component is not normally used within relative references. あらゆるクライアントアプリケーションは、相対URIを解決する前に、基底URIか らクエリー成分を除去する。しかし、アプリケーションによっては、基底のパス と併合する以前に、相対パスからクエリー成分及び/又は部分識別子を分離でき ないものがある。このエラーはめったに気が付かない。なぜなら、部分識別子は 通常の使用法では決して階層文字("/")を含まず、又クエリー成分は通常は相対 参照内では使われないからである。 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 URI 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. 構文解析器によっては、基底URIのスキームと同じであれば、相対URI中にスキー ム名が表れることを許すものがある。これは、先行する一部URI仕様書 [RFC1630]における抜け穴と考えられる。この手法は避けるべきである。 http:g = http:g ; for validating parsers | http://a/b/c/g ; for backwards compatibility 妥当性を検証する構文解析器の場合 下位互換性を採る場合 D. HTML文書内への基底URIの埋め込み (Embedding the Base URI in HTML documents) It is useful to consider an example of how the base URI of a document can be embedded within the document's content. In this appendix, we describe how documents written in the Hypertext Markup Language (HTML) [RFC1866] can include an embedded base URI. This appendix does not form a part of the URI specification and should not be considered as anything more than a descriptive example. どのようにすれば文書の基底URIをその文書内容中に埋め込むことができるか、 その例を考察することは有用である。この附属書では、ハイパーテキストマーク 付け言語(HTML) [RFC1866]で記述された文書が、どのような方法で埋め込み基底 URIを含むことができるかを記述する。この附属書は、URI仕様書の一部を構成す るものではなく、例示以上のものと取るべきではない。 HTML defines a special element "BASE" which, when present in the "HEAD" portion of a document, signals that the parser should use the BASE element's "HREF" attribute as the base URI for resolving any relative URI. The "HREF" attribute must be an absolute URI. Note that, in HTML, element and attribute names are case-insensitive. For example: HTMLでは、特別な要素"BASE"を、文書の"HEAD"部分の中に存在するとき、その "BASE"要素の"HREF"属性を相対URI解決の際に基底URIとして使用するよう示すも のとして定義している。この"HREF"属性は絶対URIでなければならない。HTMLに おいては、要素名及び属性名は大文字と小文字を区別しないことに注意するこ と。例えば、 An example HTML document ... a hypertext anchor ... A parser reading the example document should interpret the given relative URI "../x" as representing the absolute URI この例の文書を読むパーザは、この文書をどのような状況で取得したかに関わら ず、与えられた相対URI "../x"を、絶対URI regardless of the context in which the example document was obtained. を表現するものとして扱うことが望まれる。 E. 文脈中でのURIの区切りかたについての推奨 (Recommendations for Delimiting URI in Context) URI are often transmitted through formats that do not provide a clear context for their interpretation. For example, there are many occasions when URI are included in plain text; examples include text sent in electronic mail, USENET news messages, and, most importantly, printed on 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の一部と誤解されかねない句 読点(punctation marks)と区分できることが重要となる。 In practice, URI are delimited in a variety of ways, but usually within double-quotes "http://test.com/", angle brackets , or just using whitespace 現実には、URIは様々な方法で区分される。しかし一般には二重引用符 "http://test.com"、山括弧 、あるいは単に空白文字を使 う。 http://test.com/ These wrappers do not form part of the URI. これらの括り文字はURIの一部を構成しない。 In the case where a fragment identifier is associated with a URI reference, the fragment would be placed within the brackets as well (separated from the URI with a "#" character). 部分識別子がURI参照と結合している場合、その部分識別子もまた、括弧内に記 述される(URIとは"#"文字で区切られる)。 In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI. 複数行にまたがる長い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 a line, the interpreter of a URI containing a line break immediately after a hyphen should ignore all unescaped 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 URI that contain whitespace. 空白文字を含むURIを区分けするスタイルとしては、<>山括弧で各URIを括る方法 を特に推奨する。 The prefix "URL:" (with or without a trailing space) was recommended as a way to used to help distinguish a URL from other bracketed designators, although this is not common in practice. 他の、山括弧で括った指示文字列とURLを区別する助けとなる方法として、接頭 辞"URL:" (その後ろにスペースがある場合とない場合がある)が推奨されていた が、実際にはこの方法は一般的になっていない。 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 . Note the warning in . contains the URI references は、URI参照 http://www.w3.org/Addressing/ ftp://ds.internic.net/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING を含む。 F. 省略されたURL (Abbreviated URLs) The URL syntax was designed for unambiguous reference to network resources and extensibility via the URL scheme. However, as URL identification and usage have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URL references. That is, a reference consisting of only the authority and path portions of the identified resource, such as URL構文は、ネットワーク資源に対するあいまいさのない参照と、URLスキームを 通じた拡張性を狙いとして設計された。しかし、URLの同一視及び慣用法が一般 的になるにつれて、従来のメディア(テレビ、ラジオ、新聞、看板広告など)によ る省略URL参照の使用が増えてきている。省略URL参照とはすなわち、指定する資 源のオーソリティとパスの部分だけからなる参照であり、 www.w3.org/Addressing/ or simply the DNS hostname on its own. Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URL (e.g., most hostnames beginning with "www" are likely to have a URL prefix of "http://"). Although there is no standard set of heuristics for disambiguating abbreviated URL references, many client implementations allow them to be entered by the user and heuristically resolved. It should be noted that such heuristics may change over time, particularly when new URL schemes are introduced. 又は単にそのDNSホスト名のみといった形である。このような参照は本来は機械 ではなく人間が解釈することを意図したものであり、文脈ごとの経験則により URLを完全なものとできるという仮定がある(例えば、"www"で始まるホスト名な ら、大部分はURLの接頭辞に"http://"が来る)。URL参照の省略部分を明らかにす るための標準的な経験則の組は存在しないが、多くのクライアント処理系が、利 用者によるそれら省略URL参照の入力を受け付け、経験則的に解決している。こ のような経験則は時が経つにつれて、特に新しいURLスキームが導入されること により、変化しうることに注意すべきである。 Since an abbreviated URL has the same syntax as a relative URL path, abbreviated URL references cannot be used in contexts where relative URLs are expected. This limits the use of abbreviated URLs to places where there is no defined base URL, such as dialog boxes and off-line advertisements. 省略URLは相対URLパスと同様の構文になっているから、省略URL参照を相対URLが 想定される文脈で使うことはできない。このことにより、省略URLは基底URLが定 義されていない場、つまりダイアログボックスやオフラインの広告などに使用の 場を制限される。 G. 編集上の問題ではない変更の概要 (Summary of Non-editorial Changes) G.1. 追加 (Additions) Section 4 (URI References) was added to stem the confusion regarding "what is a URI" and how to describe fragment identifiers given that they are not part of the URI, but are part of the URI syntax and parsing concerns. In addition, it provides a reference definition for use by other IETF specifications (HTML, HTTP, etc.) that have previously attempted to redefine the URI syntax in order to account for the presence of fragment identifiers in URI references. Section 4 (URI参照)は、"URIとは何か"という問題、及びURIの一部ではないが URI構文の一部であり構文解析に関係する存在である部分識別子をどのように記 述するかという問題について、混乱を防ぐために追加した。他のIETF仕様書 (HTML、HTTPなど)ではすでに、URI参照内の部分識別子の存在を根拠づけるため に、URI構文の再定義が試みられてきた。このSection 4ではさらに、これらの仕 様書で使用できる参照定義も行っている。 Section 2.4 was rewritten to clarify a number of misinterpretations and to leave room for fully internationalized URI. Section 2.4は、多数の誤解釈を明らかにし、又、完全に国際化されたURIのため に余地を残しておくために、書き直した。 Appendix F on abbreviated URLs was added to describe the shortened references often seen on television and magazine advertisements and explain why they are not used in other contexts. 省略URLについての附属書Fは、短縮記述された参照がテレビや雑誌広告ではしば しば見られることを述べ、それらがなぜ他の文脈では用いられないかを説明する ために追加した。 G.2. RFC 1738及びRFC 1808からの修正点 (Modifications from both RFC 1738 and RFC 1808) Changed to URI syntax instead of just URL. URLから、URI構文への変更。 Confusion regarding the terms "character encoding", the URI "character set", and the escaping of characters with % equivalents has (hopefully) been reduced. Many of the BNF rule names regarding the character sets have been changed to more accurately describe their purpose and to encompass all "characters" rather than just US-ASCII octets. Unless otherwise noted here, these modifications do not affect the URI syntax. 「文字符号化」、URI「文字集合」、及び文字を等価である%へとエス ケープすること、という用語に関する混同を減らす(ことができたと期待する)。 文字集合に関するBNF式の名前の多くを、より的確にその目的を述べ、US-ASCII オクテットのみにとどまらずすべての「文字」を包含するように変更した。別注 がない限り、これらの修正はURI構文に影響しない。 Both RFC 1738 and RFC 1808 refer to the "reserved" set of characters as if URI-interpreting software were limited to a single set of characters with a reserved purpose (i.e., as meaning something other than the data to which the characters correspond), and that this set was fixed by the URI scheme. However, this has not been true in practice; any character that is interpreted differently when it is escaped is, in effect, reserved. Furthermore, the interpreting engine on a HTTP server is often dependent on the resource, not just the URI scheme. The description of reserved characters has been changed accordingly. RFC 1738及びRFC 1808のいずれも、「予約」文字の集合について、URI解釈ソフ トウェアはある予約目的に対して単一の文字集合(つまり、文字に対応するデー タ以外の何物か)を扱い、その集合はURIスキームごとに固定されているかのよう に記述している。しかし、実際にはこれは正しくはない。エスケープの際に異な った文字に変換された文字は、事実上、予約されている。さらに、HTTPサーバ上 の解釈エンジンはしばしば資源に依存し、URIスキームそのものには依存しな い。それゆえ、予約文字の記述を変更した。 The plus "+", dollar "$", and comma "," characters have been added to those in the "reserved" set, since they are treated as reserved within the query component. プラス"+"、ダラー"$"、及びコンマ","文字を"reserved"集合に追加した。これ らはクエリー成分内で予約されているとして取り扱われるためである。 The tilde "~" character was added to those in the "unreserved" set, since it is extensively used on the Internet in spite of the difficulty to transcribe it with some keyboards. チルダ文字"~"を"unreserved"集合に追加した。ある種のキーボードではこの文 字の入力に困難を伴うが、インターネットにおいて広く用いられているためであ る。 The syntax for URI scheme has been changed to require that all schemes begin with an alpha character. URIスキームの構文を、すべてのスキームがalpha文字から始まることを要求する ように変更した。 The "user:password" form in the previous BNF was changed to a "userinfo" token, and the possibility that it might be "user:password" made scheme specific. In particular, the use of passwords in the clear is not even suggested by the syntax. 以前のBNFにおける"user:password"書式を、"userinfo"トークンへと変更し、そ れが"user:password"という形式であるかどうかはスキーム固有とした。特に、 パスワードを明示的な形で用いることは、構文では示唆していない。 The question-mark "?" character was removed from the set of allowed characters for the userinfo in the authority component, since testing showed that many applications treat it as reserved for separating the query component from the rest of the URI. 疑問符文字"?"を、オーソリティ成分内のuserinfoで許される文字の集合から除 外した。試験の結果、多くのアプリケーションがこの文字をURIの残りの部分か らクエリー成分を分離するための予約文字として扱うことが示されたからであ る。 The semicolon ";" character was added to those stated as being reserved within the authority component, since several new schemes are using it as a separator within userinfo to indicate the type of user authentication. セミコロン文字";"をオーソリティ成分内での予約文字として追加した。いくつ かの新たなスキームがこの文字を、userinfo内で利用者認証の型を示す分離子と して使っているからである。 RFC 1738 specified that the path was separated from the authority portion of a URI by a slash. RFC 1808 followed suit, but with a fudge of carrying around the separator as a "prefix" in order to describe the parsing algorithm. RFC 1630 never had this problem, since it considered the slash to be part of the path. In writing this specification, it was found to be impossible to accurately describe and retain the difference between the two URI and without either considering the slash to be part of the path (as corresponds to actual practice) or creating a separate component just to hold that slash. We chose the former. RFC 1738では、パスをURIのオーソリティ部分から分離する際に1個のスラッシュ を用いると定義していた。RFC 1808も追随したが、構文解析アルゴリズムを記述 するために、この分離子を「接頭辞」として扱うごまかしを伴っていた。 RFC 1630ではこの問題はなかった。なぜなら、スラッシュをパスの一部と見なし たからである。この仕様書を書く上で、スラッシュを(現実の慣行に合わせて)パ スの一部と見なすか、スラッシュのみを含むseparate成分を作成するかのいずれ かを行わなければ、2種のURI 及び を違ったものとして正確に記述し取り扱うことは不可能であることがわかった。 われわれは前者の方法を選択した。 G.3. RFC 1738からの修正点 (Modifications from RFC 1738) The definition of specific URL schemes and their scheme-specific syntax and semantics has been moved to separate documents. 特定のURLスキーム及び、それらのスキーム固有の構文と意味論は別個の文書へ と移行した。 The URL host was defined as a fully-qualified domain name. However, many URLs are used without fully-qualified domain names (in contexts for which the full qualification is not necessary), without any host (as in some file URLs), or with a host of "localhost". URLホストは完全修飾ドメイン名として定義していた。しかし、(完全修飾が必要 とされない文脈において)完全修飾ドメイン名なしで、(ある種のfile URLで)何 らのホストなしで、又は"localhost"をホストとして、多数のURLが用いられてい る。 The URL port is now *digit instead of 1*digit, since systems are expected to handle the case where the ":" separator between host and port is supplied without a port. URLポートは今や1*digitではなく*digitである。これは、ホストとポートの間の ":"分離子が、ポートがないのに挿入されている場合を扱えるよう、システムが 求められているからである。 The recommendations for delimiting URI in context (Appendix E) have been adjusted to reflect current practice. URIを文脈上で区分けすることについての推奨(附属書E)を、現状の慣行を反映し て調整した。 G.4. RFC 1808からの修正点 (Modifications from RFC 1808) RFC 1808 (Section 4) defined an empty URL reference (a reference containing nothing aside from the fragment identifier) as being a reference to the base URL. Unfortunately, that definition could be interpreted, upon selection of such a reference, as a new retrieval action on that resource. Since the normal intent of such references is for the user agent to change its view of the current document to the beginning of the specified fragment within that document, not to make an additional request of the resource, a description of how to correctly interpret an empty reference has been added in Section 4. RFC 1808 (Section 4)では、空のURL参照(部分識別子以外には何も含まない参 照)を基底URLへの参照と定義した。残念ながらこの定義は、そのような参照を抽 出する際に、当該資源へ新たな取得操作を発生させるように解釈可能であった。 このような参照が通常意図しているのは、現在の文書表示を、その文書中の指定 された部分の先頭へと切り替えるようユーザエージェントに指示するものであ り、当該資源を再び要求することではないから、空の参照を正しく解釈する方法 の記述をSection 4に追加した。 The description of the mythical Base header field has been replaced with a reference to the Content-Location header field defined by MHTML [RFC2110]. 架空の存在であるBaseヘッダフィールドについての記述を、MHTML [RFC2110]で 定義されたContent-Locationヘッダフィールドへの参照と差し替えた。 RFC 1808 described various schemes as either having or not having the properties of the generic URI syntax. However, the only requirement is that the particular document containing the relative references have a base URI that abides by the generic URI syntax, regardless of the URI scheme, so the associated description has been updated to reflect that. RFC 1808では、様々なスキームについて、それが一般的URI構文を特徴として持 つかどうか述べた。しかし必要なのは、相対参照を含むある特定の文書にはURI スキームに依らず一般的URI構文を守る基底URIがあるという点のみであるため、 その点を反映して関連する記述を更新した。 The BNF term has been replaced with , since the latter more accurately describes its use and purpose. Likewise, the authority is no longer restricted to the IP server syntax. BNFの項はで置き換えた。なぜなら、後者はその用法と目 的をより正確に描写するものであるためである。さらに、オーソリティはもはや IPサーバ構文に限定されない。 Extensive testing of current client applications demonstrated that the majority of deployed systems do not use the ";" character to indicate trailing parameter information, and that the presence of a semicolon in a path segment does not affect the relative parsing of that segment. Therefore, parameters have been removed as a separate component and may now appear in any path segment. Their influence has been removed from the algorithm for resolving a relative URI reference. The resolution examples in Appendix C have been modified to reflect this change. 現時点のクライアントアプリケーションによる広範囲な試験により、運用されて いるシステムの大部分は、";"文字をパラメタ情報が後に続く印として使用して いないこと、パス部分中にセミコロンが存在することは相対参照の構文解析に影 響を与えないことが示された。そこで、パラメタは独立した成分へと移され、今 ではどのようなパス部分にも現れることができる。これらの影響は相対URI参照 の構文解析算法からは除去されている。附属書Cでの解析例を、この変更を反映 させて修正した。 Implementations are now allowed to work around misformed relative references that are prefixed by the same scheme as the base URI, but only for schemes known to use the syntax. この文書からは、基底URIと同じスキームが頭部に記述されている誤った形式の 相対参照は、形式を使うことが知られているスキームである場合に は、処理系で処理することを認めている。 H. 完全な著作権表示 (Full Copyright Statement) Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.