release/man7/uri.7

   1 .\"
   2 .\" (C) Copyright 1999-2000 David A. Wheeler (dwheeler@dwheeler.com)
   3 .\"
   4 .\" Permission is granted to make and distribute verbatim copies of this
   5 .\" manual provided the copyright notice and this permission notice are
   6 .\" preserved on all copies.
   7 .\"
   8 .\" Permission is granted to copy and distribute modified versions of this
   9 .\" manual under the conditions for verbatim copying, provided that the
  10 .\" entire resulting derived work is distributed under the terms of a
  11 .\" permission notice identical to this one.
  12 .\"
  13 .\" Since the Linux kernel and libraries are constantly changing, this
  14 .\" manual page may be incorrect or out-of-date.  The author(s) assume no
  15 .\" responsibility for errors or omissions, or for damages resulting from
  16 .\" the use of the information contained herein.  The author(s) may not
  17 .\" have taken the same level of care in the production of this manual,
  18 .\" which is licensed free of charge, as they might when working
  19 .\" professionally.
  20 .\"
  21 .\" Formatted or processed versions of this manual, if unaccompanied by
  22 .\" the source, must acknowledge the copyright and authors of this work.
  23 .\"
  24 .\" Fragments of this document are directly derived from IETF standards.
  25 .\" For those fragments which are directly derived from such standards,
  26 .\" the following notice applies, which is the standard copyright and
  27 .\" rights announcement of The Internet Society:
  28 .\"
  29 .\" Copyright (C) The Internet Society (1998).  All Rights Reserved.
  30 .\" This document and translations of it may be copied and furnished to
  31 .\" others, and derivative works that comment on or otherwise explain it
  32 .\" or assist in its implementation may be prepared, copied, published
  33 .\" and distributed, in whole or in part, without restriction of any
  34 .\" kind, provided that the above copyright notice and this paragraph are
  35 .\" included on all such copies and derivative works.  However, this
  36 .\" document itself may not be modified in any way, such as by removing
  37 .\" the copyright notice or references to the Internet Society or other
  38 .\" Internet organizations, except as needed for the purpose of
  39 .\" developing Internet standards in which case the procedures for
  40 .\" copyrights defined in the Internet Standards process must be
  41 .\" followed, or as required to translate it into languages other than English.
  42 .\"
  43 .\" Modified Fri Jul 25 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
  44 .\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
  45 .\" Modified Tue Mar 14 2000 by David A. Wheeler (dwheeler@dwheeler.com)
  46 .\"
  47 .\"*******************************************************************
  48 .\"
  49 .\" This file was generated with po4a. Translate the source file.
  50 .\"
  51 .\"*******************************************************************
  52 .TH URI 7 2000\-03\-14 Linux "Linux Programmer's Manual"
  53 .SH 名前
  54 uri, url, urn \- uniform resource identifier (URI), URL と URN も含む.
  55 .SH 書式
  56 .nf
  57 .HP 0.2i
  58 URI = [ absoluteURI | relativeURI ] [ "#" fragment ]
  59 .HP
  60 absoluteURI = scheme ":" ( hierarchical_part | opaque_part )
  61 .HP
  62 relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]
  63 .HP
  64 scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
  65          "file" | "man" | "info" | "whatis" | "ldap" | "wais" | \&...
  66 .HP
  67 hierarchical_part = ( net_path | absolute_path ) [ "?" query ]
  68 .HP
  69 net_path = "//" authority [ absolute_path ]
  70 .HP
  71 absolute_path = "/"  path_segments
  72 .HP
  73 relative_path = relative_segment [ absolute_path ]
  74 .fi
  75 .SH 説明
  76 .PP
  77 Uniform Resource Identifier (URI)  は抽象的・物理的なリソース (web ページなど)
  78 を識別するための短い文字列である。 Uniform Resource Locator (URL) は URI の一種で、
  79 リソースの名前などの属性でではなく、 そのリソースに対応するアクセスメカニズムを通してリソースを指定する (つまりネットワーク上の「場所
  80 (location)」を指定する)。 Uniform Resource Name (URN) は URI の一種で、
  81 これは対象のリソースが廃棄されたり利用できなくなった場合にも、 グローバルに他と重なることなく永続しなければならない。
  82 .PP
  83 URI は、 web ブラウザなどのツールで ハイパーテキストリンクのリンク先を指定する時の標準的な方法である。 文字列
  84 "http://www.kernelnotes.org" は URL である (従って URI でもある)。多くの人々は、 URL という言葉をほぼ
  85 URI の 同義語として使っている (しかし技術的には URL は URI のサブセットである)。
  86 .PP
  87 URI は絶対的にも相対的にも指定できる。 絶対的な指定は、リソースをコンテクストに依存しないかたちで参照する。
  88 相対的な指定は、リソースを現在のコンテクストからの差異によって記述する。 相対パス参照では、 "." および ".." だけのパス部分 (path
  89 segment)  は特別な意味を持ち、 それぞれ「現在の階層レベル」および「現在の階層の一つ上のレベル」 として扱われる (UNIX
  90 風のシステムと同様)。 コロン文字を含むパス部分は相対 URI パスの先頭に用いることはできない (つまり "this:that"
  91 はダメ)。スキーム名と区別できないからである。 このような場合には ./ を前置すること (つまり "./this:that" とする)。 MS\-DOS
  92 の子孫 (Microsoft Windows など) は、 デバイス名のコロンを URI では垂直バー ("|") に置き換える。 したがって "C:"
  93 は "C|" となる。
  94 .PP
  95 フラグメント指定子 (fragment identifier) は、(もし含まれていれば)  リソース中の名前付けされた特定の部分 (フラグメント)
  96 を参照する。 \(aq#\(aq 指定子以降の文字列がフラグメントを指定する。 \(aq#\(aq で始まる URI
  97 は現在のリソース中のフラグメントを参照する。
  98 .SS 使い方
  99 URI のスキームには色々な種類があり、 それぞれ固有のルールや意味が追加されている。 しかしできるだけ統一したものにしようという努力もなされている。
 100 例えば、多くの URL スキームは「機関 (authority)」に対して以下の書式 (ここでは \fIip_server\fP と呼ぶことにする)
 101 を許している (角括弧内部は省略可能)。
 102 .HP
 103 \fIip_server = \fP[\fIuser\fP [ : \fIpassword\fP ] @ ] \fIhost\fP [ : \fIport\fP]
 104 .PP
 105 このフォーマットには、ユーザ名、ユーザ名+パスワードを指定できる。 ポート番号を追加することも可能である。 \fIhost\fP
 106 はホストコンピュータの名前で、 DNS で定義される名前か IP アドレス (ピリオドで区切られた数字) で指定する。したがって URI
 107 <http://fred:fredpassword@xyz.com:8080/> は、ホスト xyz.com に fred として
 108 (パスワードを使って)  ポート 8080 を使ってログインする。 パスワードは可能なら URI には含めないほうが良いだろう。
 109 パスワードを直書きすると様々なセキュリティ上のリスクが生じるからである。 URL にユーザ名だけを与え、パスワードを与えない場合は、
 110 リモートサーバはパスワードを要求してくる。 URL を解釈したプログラムが、ユーザにこの入力を促すことになろう。
 111 .PP
 112 以下に、 UNIX 風のシステムで非常に良く用いられており、 多くのツールが理解するスキームを示す。 URI
 113 を使うツールの多くでは、内部スキームや特殊なスキームも 使えることが多い。そのようなスキームに関してはツールのドキュメントを見ること。
 114 .PP
 115 \fBhttp \- Web (HTTP) サーバ\fP
 116 .PP
 117 http://\fIip_server\fP/\fIpath\fP
 118 .br
 119 http://\fIip_server\fP/\fIpath\fP?\fIquery\fP
 120 .PP
 121 これは web (HTTP) サーバにアクセスするための URL である。 デフォルトのポートは 80。パスがディレクトリを参照しているときは、
 122 返される情報は web サーバが選択する。通常は、 "index.html" や "index.htm" のようなファイルがあれば、その内容が返される。
 123 なければ、カレントディレクトリのリストが (適切なリンクとともに) 生成されて 返される。例としては <http://lwn.net>
 124 など。
 125 .PP
 126 問い合わせ (query) を、古い "isindex" フォーマットによって送ることもできる。 このフォーマットは単語またはフレーズからなり、等号
 127 (=) は含まない。 より長い "GET" フォーマットでも問い合わせは行える。 このフォーマットには、一つ以上の問い合わせエントリが
 128 \fIkey\fP=\fIvalue\fP という形式で含まれる。それぞれのエントリはアンパサンド (&) で区切られる。 \fIkey\fP
 129 は複数個指定することもできる。しかしそれに意味があるかどうかは web サーバとアプリケーションプログラムが決める。 HTML/XML/SGML と
 130 GET 問い合わせ形式の間には、不幸な関係がある。 一つ以上のキーの含まれる URI が SGML/XML 文書 (HTML もそう)
 131 に埋めこまれる際には、アンパサンド (&) は &amp; と書かなければならない。 全ての問い合わせがこの形式を使うわけではない。
 132 フォームが長くなると URI に入れるには長すぎるから、 別の通信メカニズム (POST と呼ばれる) が用いられる。 POST では URI
 133 にはデータは含まれない。 より詳しい情報は、 <http://www.w3.org/CGI> にある Common Gateway
 134 Interface の仕様書を見よ。
 135 .PP
 136 \fBftp \- ファイル転送プロトコル (FTP)\fP
 137 .PP
 138 ftp://\fIip_server\fP/\fIpath\fP
 139 .PP
 140 これはファイル転送プロトコル (FTP) を通してファイルにアクセスするための URL である。デフォルトの (制御用) ポートは 21 である。
 141 ユーザ名がない場合には、ユーザ名 anonymous が与えられる。 そしてその場合には、クライアントの多くは要求した人の
 142 インターネットメールアドレスをパスワードとして与える。 例としては
 143 <ftp://ftp.is.co.za/rfc/rfc1808.txt> など。
 144 .PP
 145 \fBgofer \- Gofer サーバ\fP
 146 .PP
 147 gopher://\fIip_server\fP/\fIgophertype selector\fP
 148 .br
 149 gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP
 150 .br
 151 gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP%09\fIgopher+_string\fP
 152 .br
 153 .PP
 154 デフォルトの gopher ポートは 70 である。 \fIgophertype\fP は 1 文字からなるフィールドで、 URL が参照している
 155 Gopher のリソースタイプを示す。 パス全体が空であってもよく、その場合は区切りの "/" も省略できる。 このとき gophertype
 156 のデフォルトは "1" になる。
 157 .PP
 158 \fIselector\fP は Gopher セレクタ文字列である。Gopher プロトコルでは、 Gopher セレクタ文字列はオクテット文字からなり、
 159 16進数の 09 (US\-ASCII の HT または tab)、 0A (US\-ASCII の LF 文字)、 0D (US\-ASCII の CR
 160 文字) 以外ならどんなオクテットも指定できる。
 161 .PP
 162 \fBmailto \- 電子メールアドレス\fP
 163 .PP
 164 mailto:\fIemail\-address\fP
 165 .PP
 166 これは電子メールアドレスで、通常 \fIname\fP@\fIhostname\fP という形式をとる。電子メールアドレスの正しいフォーマットに関する
 167 より詳しい情報は \fBmailaddr\fP(7)  を見よ。 % 文字はすべて %25 と書き直さなければならないことに注意。 例としては
 168 <mailto:dwheeler@dwheeler.com> など。
 169 .PP
 170 \fBnews \- ニュースグループ・ニュースメッセージ\fP
 171 .PP
 172 news:\fInewsgroup\-name\fP
 173 .br
 174 news:\fImessage\-id\fP
 175 .PP
 176 \fInewsgroup\-name\fP はピリオドで区切られた階層的な名前である。例えば "comp.infosystems.www.misc" など。
 177 <newsgroup\-name> が "*" (つまり <news:*>) の場合には、
 178 「参照できる全てのニュースグループ」の意味になる。 例としては <news:comp.lang.ada> など。
 179 .PP
 180 \fImessage\-id\fP は
 181 .UR http://www.ietf.org/rfc/rfc1036.txt
 182 IETF RFC\ 1036
 183 .UE
 184 の Message\-ID から、囲みの "<" と ">" を取ったものに対応する。 Message\-ID は
 185 \fIunique\fP@\fIfull_domain_name\fP という形式をとる。メッセージの指定には "@" 文字が含まれるので、
 186 ニュースグループの名前と区別できるだろう。
 187 .PP
 188 \fBtelnet \- telnet ログイン\fP
 189 .PP
 190 telnet://\fIip_server\fP/
 191 .PP
 192 Telnet URL スキームは対話的なテキストサービスに Telnet プロトコルを 通してアクセスするために用いられる。最後の "/"
 193 文字は省略してよい。 例としては <telnet://melvyl.ucop.edu/> など。
 194 .PP
 195 \fBfile \- 通常のファイル\fP
 196 .PP
 197 file://\fIip_server\fP/\fIpath_segments\fP
 198 .br
 199 file:\fIpath_segments\fP
 200 .PP
 201 これはローカルに直接アクセスできるファイルを示す。 特殊なケースとして、 \fIhost\fP には "localhost"
 202 という文字列を用いたり、空文字にしてもよい。 これは「URI が解釈されたマシン」とみなされる。 path
 203 がディレクトリの場合は、ビューアはディレクトリの内容を リンクを張ったかたちで表示するとよいだろう。
 204 しかし現在は、まだ全てのビューアがこの動作をするわけではない。 KDE は生成ファイル (generated file) を URL
 205 <file:/cgi\-bin> の形式でサポートしている。 与えられたファイルが見付からなかった場合は、
 206 ファイル名をグロブによって展開すると良いかもしれない (\fBglob\fP(7)  および \fBglob\fP(3)  を見よ)。
 207 .PP
 208 二つめの書式 (例えば <file:/etc/passwd>) もローカルファイルを参照する
 209 正しいフォーマットである。しかし古い標準ではこの書式を許していなかったので、 これを URI として認識しないプログラムも存在する。
 210 より汎用的な文法は、サーバ名に空文字を用いるもの、 つまり <file:///etc/passwd> のようなものである。
 211 この形式も指す内容は同じであり、パターンマッチやより古いプログラムでも URI として認識されやすい。
 212 もし意図するところが「現在の場所からスタート」なら、 スキームは一切用いるべきではない。 <../test.txt>
 213 のような、スキームに依存しない相対リンクを用いること。 このスキームの例としては <file:///etc/passwd> など。
 214 .PP
 215 \fBman \- man ページ文書\fP
 216 .PP
 217 man:\fIcommand\-name\fP
 218 .br
 219 man:\fIcommand\-name\fP(\fIsection\fP)
 220 .PP
 221 これはローカルのオンラインマニュアル (man) リファレスページを参照する。 command\-name には括弧とセクション番号を追加してもよい。
 222 セクション番号の意味について詳しく知りたい場合は \fBman\fP(7)  をみよ。この URI スキームは UNIX 風のシステム (Linux など)
 223 に特有のものであり、現在はまだ IETF による登録はされていない。 例としては <man:ls(1)> など。
 224 .PP
 225 \fBinfo \- info ページ文書\fP
 226 .PP
 227 info:\fIvirtual\-filename\fP
 228 .br
 229 info:\fIvirtual\-filename\fP#\fInodename\fP
 230 .br
 231 info:(\fIvirtual\-filename\fP)
 232 .br
 233 info:(\fIvirtual\-filename\fP)\fInodename\fP
 234 .PP
 235 このスキームは、オンラインの info リファレンスページ (texinfo ファイルから生成される) を参照する。 info ページは GNU
 236 ツールなどのプログラムで用いられている文書フォーマットである。 この URI スキームは UNIX 風のシステム (Linux など)
 237 に特有のものであり、現在はまだ IETF による登録はされていない。 この文書の執筆時において、 GNOME と KDE はそれぞれ異なる文法の URI
 238 を用いており、お互い相手の文法を受け入れない。 最初の 2 つの書式は GNOME の書式である。ノード名 (nodename)
 239 のスペースはすべてアンダースコアに変換される。 3 つめと 4 つめは KDE の書式である。ノード名のスペースは そのままスペースで書かれる (URI
 240 の標準では禁止されているのだが)。 将来は多くのツールがこれらの書式すべてを理解するようになり、
 241 ノード名のアンダースコア、スペースを両方とも理解できるように なることを期待したい。 GNOME でも KDE でも、
 242 ノード名が省略された場合は、ノード名として "Top" が用いられる。 GNOME 書式の例としては <info:gcc> や
 243 <info:gcc#G++_and_GCC> など、 KDE 書式の例としては <info:(gcc)> や
 244 <info:(gcc)G++ and GCC> など。
 245 .PP
 246 \fBwhatis \- 文書検索\fP
 247 .PP
 248 whatis:\fIstring\fP
 249 .PP
 250 このスキームは、コマンドに関する短い (1 行の) 説明を集めた データベースを検索し、 string を含む文字列をリストして返す。
 251 単語が完全にマッチした結果だけが返される。 \fBwhatis\fP(1)  を見よ。 この URI スキームは UNIX 風のシステム (Linux など)
 252 に特有のものであり、現在はまだ IETF による登録はされていない。
 253 .PP
 254 \fBghelp \- GNOME ヘルプ文書\fP
 255 .PP
 256 ghelp:\fIname\-of\-application\fP
 257 .PP
 258 与えられた application に対応する GNOME help をロードする。 この書式を用いた文書はまだあまり多くない。
 259 .PP
 260 \fBldap \- 軽量ディレクトリアクセスプロトコル\fP
 261 .PP
 262 ldap://\fIhostport\fP
 263 .br
 264 ldap://\fIhostport\fP/
 265 .br
 266 ldap://\fIhostport\fP/\fIdn\fP
 267 .br
 268 ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP
 269 .br
 270 ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP
 271 .br
 272 ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP
 273 .br
 274 ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP?\fIextensions\fP
 275 .PP
 276 このスキームは Lightweight Directory Access Protocol (LDAP)  へのクエリーをサポートする。 LDAP
 277 は複数のサーバに分散した、 階層化された情報 (人々や計算資源など) に問い合わせるための プロトコルである。 LDAP の URL
 278 スキームに関するより詳しい情報は
 279 .UR http://www.ietf.org/rfc/rfc2255.txt
 280 RFC\ 2255
 281 .UE
 282 で見ることができる。 この URL の各部は以下の通り:
 283 .IP hostport 12
 284 クエリーを行う LDAP サーバ。ホスト名を書く。続けてコロンとポート番号を 追加することもできる。 LDAP のデフォルトのポートは TCP ポート
 285 389 である。 省略されると、どの LDAP サーバを用いるかはクライアントが決定する。
 286 .IP dn
 287 LDAP の Distintuished Name (識別名)。 LDAP 検索の base オブジェクトを指定するものである (
 288 .UR http://www.ietf.org/rfc/rfc2253.txt
 289 RFC\ 2253
 290 .UE
 291 の section 3 を見よ)。
 292 .IP attributes
 293 コンマ区切りの、返される属性 (attribute) のリスト。 RFC\ 2251 の section 4.1.5
 294 を見よ。省略されると全ての属性が返される。
 295 .IP scope
 296 検索のスコープを指定する。 "base" (base オブジェクト検索), "one" (1 レベル検索), "sub" (サブツリー検索)
 297 のいずれかを指定する。 省略すると "base" が仮定される。
 298 .IP filter
 299 検索フィルタ (返されるエントリのサブセット) を指定する。 省略されると、全てのエントリが返される。
 300 .UR http://www.ietf.org/rfc/rfc2254.txt
 301 RFC\ 2254
 302 .UE
 303 の section 4 を見よ。
 304 .IP extensions
 305 コンマで区切られた type=value ペアのリスト。 ここで =value の部分は、それを要求しないオプションに対しては 省略できる。
 306 \(aq!\(aq が前置された extension は critical (サポートしていなければならない) であり、 そうでなければ
 307 critical ではない (省略できる)。
 308 .PP
 309 LDAP のクエリーは、例とともに説明するのが最も簡単である。 次の例は、 ldap.itd.umich.edu に、 U.S. にある
 310 University of Michigan の情報を尋ねる例である。
 311 .PP
 312 .nf
 313 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
 314 .fi
 315 .PP
 316 郵便用の住所属性だけを取得する場合は、 次のようにリクエストする:
 317 .PP
 318 .nf
 319 ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
 320 .fi
 321 .PP
 322 host.com のポート 6666 に、 University of Michigan にいる common name (cn) が "Babs
 323 Jenson" の人の情報を尋ねる場合は、 次のようにリクエストする:
 324 .PP
 325 .nf
 326 ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
 327 .fi
 328 .PP
 329 \fBwais \- 広域情報サービス\fP
 330 .PP
 331 wais://\fIhostport\fP/\fIdatabase\fP
 332 .br
 333 wais://\fIhostport\fP/\fIdatabase\fP?\fIsearch\fP
 334 .br
 335 wais://\fIhostport\fP/\fIdatabase\fP/\fIwtype\fP/\fIwpath\fP
 336 .PP
 337 このスキームは WAIS のデータベース、検索、文書を指定する (WAIS に関する詳しい情報は
 338 .UR http://www.ietf.org/rfc/rfc1625.txt
 339 IETF RFC\ 1625
 340 .UE
 341 を見よ)。 hostport は、ホスト名にコロンとポート番号を付加したものである (コロン + ポート番号は省略可。デフォルトのポート番号は 210
 342 である)。
 343 .PP
 344 最初の書式は WAIS のデータベースに対する検索の指定である。 二つめの書式は特定の WAIS データベース \fIdatabase\fP
 345 に対する検索の指定である。 三つめの書式は WAIS データベースにある特定の文書を取出す指定である。 \fIwtype\fP は WAIS
 346 のオブジェクト形式指定であり、 \fIwpath\fP は WAIS document\-id である。
 347 .PP
 348 \fBその他のスキーム\fP
 349 .PP
 350 他にも多くの URI スキームが存在する。 URI を受付けるほとんどのツールは、内部 URI のセットをサポートする (例えば Mozilla
 351 は内部情報用の about: というスキームを受付けるし、 GNOME ヘルプブラウザはいろいろな出発点用に toc: というスキームを持っている)。
 352 定義されたスキームはたくさんあるが、現時点で広く用いられてはいない (例えば prospero とか)。 nntp: スキームは news:
 353 スキームが好んで用いられるようになったので 使わないほうが良い。 URN は urn: スキームによって、階層的な名前空間 (例えば
 354 urn:ietf:... は IETF 文書を示す)  としてサポートされるべきであるが、現時点では URN はあまり用いられていない。
 355 全てのツールが全てのスキームをサポートしているわけではない。
 356 .SS 文字エンコード
 357 .PP
 358 URI では、色々な状況下で入力できるように、文字の種類を制限している。
 359 .PP
 360 以下の文字は予約されている。すなわち、これらの文字は URI に登場することがあるが、それらの利用法 (解釈のされ方) は
 361 予約された目的に制限されている (衝突するデータは URI にする前にエスケープしなければならない)。
 362 .IP
 363    ; / ? : @ & = + $ ,
 364 .PP
 365 未予約文字 (unreserved character) は URI に使ってよい。 これには英字の大文字と小文字、10 進の数字、および
 366 以下の句読文字・記号が含まれる
 367 .IP
 368  \- _ . ! ~ * ' ( )
 369 .PP
 370 他の文字はすべてエスケープしなければならない。 エスケープされたオクテットは 3 文字からなる: 先頭にパーセント文字
 371 "%"、それに続けてオクテットコードを表す 2 文字の 16 進数字である (16 進数の英字は大文字小文字どちらでも良い)。 例えば空白文字は
 372 "%20" のようにエスケープしなければならず、 タブ文字は "%09"、 "&" は "%26" となる。 パーセント文字 "%"
 373 は常にエスケープを示す予約された目的に用いられるので、 "%" 自身を表すには "%25" とエスケープしなければならない。
 374 クエリーのテキストでは、スペース文字をプラス記号 (+) でエスケープすることも 一般に良く行われる。この慣例は関連 RFC
 375 で実際に定義されているわけではない (代わりに %20 を推奨している) が、クエリーテキストを受付ける
 376 ツールは、この書式への対応を用意しておくべきであろう。 URI は、常に「エスケープされた」かたちで表示される。
 377 .PP
 378 未予約文字もエスケープすることができ、これによって URI の意味するところが変わるわけではない。 しかしURI
 379 にその非エスケープ文字が現れることが許されないような 特殊な場合を除いて、これは避けるべきである。 例えば、 HTTP URL の path において
 380 "%7e" が "~" の代わりに用いられることがあるが、 この二つは HTTP URL としては等価である。
 381 .PP
 382 US ASCII キャラクタセット以外の文字を URI として扱う場合、 HTML 4.1 規格 (section B.2) 及び IETF RFC\ 2718 (section 2.2.5) は 以下の手法を用いるよう推奨している。
 383 .IP 1. 4
 384 キャラクタ列を UTF\-8 (IETF RFC\ 2279, \fButf\-8\fP(7)  参照) に変換し、
 385 .IP 2.
 386 URI エスケープ機構を用いる。 つまり、安全でないオクテットを %HH でエンコードする。
 387 .SS "URI を書くには"
 388 URI を書く時には、ダブルクォートの内部に書く (例: "http://www.kernelnotes.org") か、 angle ブラケットで囲む
 389 (例: <http://lwn.net>) か、 一行に URI だけを書くかする。 ダブルクォートを使う人に警告: \fB絶対に\fP句読点
 390 (文末のピリオドやリスト区切りのコンマ) を URI の内部に移動してはならない。 代わりに angle ブラケットを使うか、
 391 外にある文字をクォーテーションマークの内部に 決して含めないような引用方式に切替えること。 後者の方式は "Hart's Rules" や
 392 "Oxford Dictionary for Writers and Editors" によれば 「新しい (new) 引用方式」あるいは「論理的
 393 (logical) な引用方式」 と呼ばれており、 イギリス人や世界中のハッカー達はこちらの慣習を好んでいる (より詳しい情報は Hacker
 394 Writing Style の Jargon File のセクション
 395 \fIhttp://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html\fP を見よ)。 古い文書では、
 396 "URL:" という文字列を URI の直前に挿入することを 勧めているものもあるが、しかしこの形式はまったく流行しなかった。
 397 .PP
 398 URI の書式は曖昧さを排除するように設計されている。 しかし URI が広まるにつれ、昔ながらのメディア (TV、ラジオ、新聞、 看板などなど) は
 399 URI 参照を省略したかたち、すなわち 機関部とパス部だけでリソースを指定することが多くなっている (例:
 400 <www.w3.org/Addressing>)。 このような参照はマシンというよりは人間向けのもので、
 401 コンテキストベースの推測によって URI の補完が可能であることを あてにしているのである (例えば "www" ではじまるホスト名なら
 402 "http://" がつくだろうし、 "ftp" ではじまるホスト名なら "ftp://" がつくだろう)。
 403 多くのクライアントの実装では、この種の参照を推測によって解決する。 このような推測は時代とともに変わりうる。
 404 特に新しいスキームが導入されるとそうである。 URI の省略形では相対 URL パスの区別が付けられないので、 省略形 URI 参照は相対 URI
 405 の利用できるところでは使えない。 つまり定義済みのベース (ダイアログボックスなど)  がない場合に限って利用できる。
 406 文書内部でのハイパーテキストリンクには省略形 URI を使ってはならない。 上述の標準フォーマットを使うこと。
 407 .SH 準拠
 408 .PP
 409 \fIhttp://www.ietf.org/rfc/rfc2396.txt\fP (IETF RFC\ 2396),
 410 \fIhttp://www.w3.org/TR/REC\-html40\fP (HTML 4.0).
 411 .SH 注意
 412 Linux システムで URI を受付けるツール (例えば web ブラウザなど) は、 上にあげた全てのスキームを (直接または間接に)
 413 扱えるべきである。 man: や info: も含めて、である。 スキームの処理に他のプログラムを実行するのは良いことだし、
 414 実はすすんでそうすべきである。
 415 .PP
 416 技術的には、フラグメントは URI の一部ではない。
 417 .PP
 418 URI (URL も含む) をデータフォーマットに埋めこむ方法に関する情報は、 そのフォーマットのドキュメントを見よ。 HTML は <A
 419 HREF="\fIuri\fP">\fItext\fP</A> を用いる。 texinfo は @uref{\fIuri\fP}
 420 という書式を用いる。 man と mdoc は、最近追加された UR マクロを使う。 あるいは URI をそのままテキストに埋めこむ (ビューアが
 421 :// を URI の一部と解釈できなければならない)。
 422 .PP
 423 デスクトップ環境である GNOME と KDE は、 それぞれ受付ける URI が (特にそれぞれのヘルプブラウザにおいて)  異なっている。 man
 424 ページをリストするには、 GNOME では <toc:man> を用い、 KDE では <man:(index)>
 425 を用いる。 また info ページをリストするには、 GNOME では <toc:info> を用い、 KDE では
 426 <info:(dir)> を用いる (本 man ページの著者は KDE のアプローチのほうが好みである。
 427 しかしより標準的な書式の方が更に良いが)。 一般に KDE は生成ファイル (generated file) のプレフィックスとして
 428 <file:/cgi\-bin/> を用いる。 KDE は HTML の文書を
 429 <file:/cgi\-bin/helpindex> 経由でアクセスするのが好みなようである。 GNOME は文書の保管・検索に
 430 ghelp スキームを用いる方法を取っているようだ。 どちらのブラウザも、現時点では file: によるディレクトリ参照を扱えない。
 431 したがってディレクトリ全体をブラウズ可能な URI で参照することが難しい。 先に述べたように、これら二つの環境では info: スキームの
 432 扱いが異なっている (おそらく最も重要な差異であろう)。 GNOME と KDE が共通 URI フォーマットに収斂することが望ましい。 この man
 433 ページが、将来はその収斂した結果を記述できることを望む。 この作業への助力を喚起したい。
 434 .SS セキュリティ
 435 .PP
 436 URI そのものはセキュリティの脅威を引き起こすものではない。 ある時点ではリソースの場所を与えていた URL が、
 437 ずっとそうでありつづけるという保証は一般にはない。 またある URL が、将来には別のリソースを示さないとも限らない。
 438 このような保証は、その名前空間とリソースとを管理している個人に 帰するものに過ぎない。
 439 .PP
 440 無害に見える操作 (リソースに関連づけられたエンティティの取得など)  によって、実際にはリモートにダメージを与える動作を引き起こすような URL
 441 を記述することも場合によっては可能である。 危険な URL の典型的なものは、そのネットワークプロトコルに
 442 予約されているポート番号とは異なるポートを指定しているものである。 URL の内容には命令が含まれていて、 そのプロトコルにしたがって解釈されたとき、
 443 予期されない動作を引起こすのである。 例をあげると、 gopher の URL によって、意図しないメッセージや なりすましメッセージなどが SMTP
 444 サーバ経由で送信されるようなことがあった。
 445 .PP
 446 そのプロトコルのデフォルト以外のポート番号を指定している URL を用いるときには注意すべきである。 特にその番号が予約空間の内部にある場合には。
 447 .PP
 448 URI に、そのプロトコルに対するデリミタがエスケープされたかたちで入っている 場合も注意が必要である (例えば telnet プロトコルに対する CR
 449 文字や LF 文字など)。 なぜならこれらは転送前にエスケープが外されないからである。
 450 これはプロトコルに反しており、予期しない、おそらくは害になるような リモート動作を引起こす結果となりかねない。
 451 .PP
 452 秘密にしておくべきパスワードを含んだ URI を使うのが 賢くないのは明らかである。特に、パスワードを URI の "userinfo"
 453 の部分に使うのは絶対に避けるべきである。 ただしその "password" のパラメータを意図的に公開したい場合は別であるが。
 454 .SH バグ
 455 .PP
 456 文書は様々な場所に置かれうる。したがって現時点では、 任意のフォーマットで書かれた一般のオンライン文書に対する良い URI スキームが 存在しない。
 457 <file:///usr/doc/ZZZ> 形式の参照は使えない。なぜなら
 458 ディストリビューションやローカルへのインストールの際の条件によって、 ファイルは異なるディレクトリに置かれることがあるからである (/usr/doc か
 459 /usr/local/doc か /usr/share かその他の場所か、などなど)。 また、ディレクトリ ZZZ
 460 は通常バージョンが変わると異なったものになる (ファイル名のグロブによってある程度克服できるだろうが)。 最後にもう一つ、文書をインターネットから
 461 (ローカルのファイルシステムに ファイルをロードするのではなく) 動的にロードする人々は、 なかなか file: スキームを使ってくれない。
 462 将来には新たな URI スキーム (例えば "userdoc:" のような) が追加され、 より詳しい文書へのクロスリファレンスが、
 463 その文書の正確な場所をプログラムが知らなくても可能になるかもしれない。 あるいは、ファイルシステム規格の将来の版で
 464 ファイルの場所の指定をより厳密にして、 file: スキームによる文書の位置指定が可能になるかもしれない。
 465 .PP
 466 プログラムやファイルフォーマットの多くでは、 URI を使ったリンクを取り込んだり実装したりする方法がない。
 467 .PP
 468 .\" .SH AUTHOR
 469 .\" David A. Wheeler (dwheeler@dwheeler.com) wrote this man page.
 470 プログラムの多くは、これらの URI フォーマットをすべては扱えない。 ユーザの環境 (テキストかグラフィックか、
 471 デスクトップ環境、ローカルユーザの好み、 現在実行されているツール) などを自動的に検知して、 任意の URI をロードし、その URI
 472 に適したツールを起動するような 標準的な仕組みがあるといいのだろうが。
 473 .SH 関連項目
 474 \fBlynx\fP(1), \fBman2html\fP(1), \fBmailaddr\fP(7), \fButf\-8\fP(7),
 475 .UR http://www.ietf.org/rfc/rfc2255.txt
 476 IETF RFC\ 2255
 477 .UE