URI共通構文(G)

広告

広告

原文

最終更新
2006-04-14T01:01:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2396/rfc2396_g.html#source

URI共通構文(和訳)

最終更新
2006-09-28T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2396/rfc2396_g.html#translation

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.

4. URI参照」は、"URIとは何か"について、及びURIの一部ではないがURI構文の一部で且つ解析に影響を及ぼすフラグメント識別子をどのように記すかについて混乱を防ぐため追加された。加えて、URI参照内でフラグメント識別子の存在を説明するために、URI構文の再定義している他のIETF仕様書(HTMLやHTTPなど)で用いられる参照定義を提供するものである。

   Section 2.4 was rewritten to clarify a number of misinterpretations
   and to leave room for fully internationalized URI.

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.

E. 文脈の中でURIを区切ることを推奨」は、省略された参照がテレビや雑誌広告で再々見られることについて、更にはその参照がなぜ他の文脈では用いられないのかを説明するために追加された。

G.2. 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 %<hex><hex>
   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の"文字集合"、文字を同義である%<hex><hex>にエスケープする、といった用語に関する混乱が縮小された(と期待する)。文字集合に関する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.

クエリコンポーネント内で予約済みと扱われるため、プラス記号"+"、ドル記号"$"、カンマ","を予約文字集合に追加した。

   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.

チルダ"~"を予約文字集合から除外した。チルダは、キーボードによっては入力が難しいがインターネット上で広く用いられているためである。

   The syntax for URI scheme has been changed to require that all
   schemes begin with an alpha character.

URIスキームの構文は、全てのスキームがアルファベットで始まることを要求するよう変更された。

   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.

疑問符"?"は、オーソリティコンポーネント内のユーザ情報で許される文字集合から除外した。これは、テストの結果多くのアプリケーションが、疑問符を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.

セミコロン";"をオーソリティコンポーネント内の予約文字のような位置付けとした。これは、いくつかの新たなスキームが、ユーザ情報内で利用者認証の型を示す区切り文字として使っているためである。

   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
      <foo:/bar>   and   <foo:bar>
   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では、スラッシュをパスの一部とみなしたためこの問題は起こらなかった。当仕様書を作成するにあたり、スラッシュを(現実の習慣通り)パスの一部とみなすかスラッシュのみを含むセパレートコンポーネントを作成するかを決定しない限り、<foo:/bar>と<foo:bar>のURIの違いを正確に記述し、扱うことが不可能であると判断し、前者を選択した。

G.3. 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ホストは完全修飾ドメイン名として定義された。しかし多くのURLは、完全修飾ドメイン名なし(完全修飾が必要とされない文脈にて)で、またホストなし(ファイルURLとして)で、またホストを"localhost"として用いられている。

   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.

E. 文脈の中でURIを区切ることを推奨」は、現状の習慣を反映した形で調整された。

G.4. 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では、空のURL参照(フラグメント識別子以外に何も含まない参照)を基底URLへの参照と定義した。残念ながら、この定義はそのような参照の抽出の際にリソースを新たに取得し直すものと解釈する誤解を招いた。このような参照では、その文書中の指定された部分の先頭へと表示を切り替えるようユーザエージェントに指示することを意図し、その文書を再度取得し直すことを要求するものではない。そのため、どのように空の参照を正しく解釈するかとの記述が4. URI参照に追加された。

   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 <net_loc> has been replaced with <authority>, since the
   latter more accurately describes its use and purpose.  Likewise, the
   authority is no longer restricted to the IP server syntax.

BNFの用語である<net_loc>は、用法と目的をより正確に記すため<authority>によって置き換えられた。更に、オーソリティは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. 相対URI参照を解決する為の例での解決例は、これにより修正された。

   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 <hier_part> syntax.

基底URIと同じスキームが前方に付けられる誤った形式の相対参照は、<hier_part>構文を用いることが周知のスキームである場合に限り、処理系で処理することが現在認められている。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年04月14日 最終更新:2006年09月28日