-'\"
+.\"
.\" (C) Copyright 1999-2000 David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Tue Mar 14 2000 by David A. Wheeler (dwheeler@dwheeler.com)
.\"
-.\" Japanese Version Copyright (c) 2000 NAKANO Takeo all rights reserved.
-.\" Translated San 12 Mar 2000 by NAKANO Takeo <nakano@apm.seikei.ac.jp>
+.\"*******************************************************************
.\"
-.\"WORD: generated file (KDE の) 生成ファイル
+.\" This file was generated with po4a. Translate the source file.
.\"
-.TH URI 7 2000-03-14 "Linux" "Linux Programmer's Manual"
+.\"*******************************************************************
+.TH URI 7 2000\-03\-14 Linux "Linux Programmer's Manual"
.SH 名前
uri, url, urn \- uniform resource identifier (URI), URL と URN も含む.
.SH 書式
.fi
.SH 説明
.PP
-Uniform Resource Identifier (URI)
-は抽象的・物理的なリソース (web ページなど)
-を識別するための短い文字列である。
-Uniform Resource Locator (URL) は URI の一種で、
-リソースの名前などの属性でではなく、
-そのリソースに対応するアクセスメカニズムを通してリソースを指定する
-(つまりネットワーク上の「場所 (location)」を指定する)。
-Uniform Resource Name (URN) は URI の一種で、
-これは対象のリソースが廃棄されたり利用できなくなった場合にも、
-グローバルに他と重なることなく永続しなければならない。
-.PP
-URI は、 web ブラウザなどのツールで
-ハイパーテキストリンクのリンク先を指定する時の標準的な方法である。
-文字列 "http://www.kernelnotes.org" は URL である (従って
-URI でもある)。多くの人々は、 URL という言葉をほぼ URI の
-同義語として使っている (しかし技術的には URL は URI のサブセットである)。
-.PP
-URI は絶対的にも相対的にも指定できる。
-絶対的な指定は、リソースをコンテクストに依存しないかたちで参照する。
-相対的な指定は、リソースを現在のコンテクストからの差異によって記述する。
-相対パス参照では、 "." および ".." だけのパス部分 (path segment)
-は特別な意味を持ち、
-それぞれ「現在の階層レベル」および「現在の階層の一つ上のレベル」
-として扱われる (UNIX 風のシステムと同様)。
-コロン文字を含むパス部分は相対 URI パスの先頭に用いることはできない
-(つまり "this:that" はダメ)。スキーム名と区別できないからである。
-このような場合には ./ を前置すること (つまり "./this:that" とする)。
-MS-DOS の子孫 (Microsoft Windows など) は、
-デバイス名のコロンを URI では垂直バー ("|") に置き換える。
-したがって "C:" は "C|" となる。
-.PP
-フラグメント指定子 (fragment identifier) は、(もし含まれていれば)
-リソース中の名前付けされた特定の部分 (フラグメント) を参照する。
-\(aq#\(aq 指定子以降の文字列がフラグメントを指定する。
-\(aq#\(aq で始まる URI は現在のリソース中のフラグメントを参照する。
-.S 利用法
-URI のスキームには色々な種類があり、
-それぞれ固有のルールや意味が追加されている。
-しかしできるだけ統一したものにしようという努力もなされている。
-例えば、多くの URL スキームは「機関 (authority)」に対して以下の書式
-(ここでは
-.I ip_server
-と呼ぶことにする)
+Uniform Resource Identifier (URI) は抽象的・物理的なリソース (web ページなど)
+を識別するための短い文字列である。 Uniform Resource Locator (URL) は URI の一種で、
+リソースの名前などの属性でではなく、 そのリソースに対応するアクセスメカニズムを通してリソースを指定する (つまりネットワーク上の「場所
+(location)」を指定する)。 Uniform Resource Name (URN) は URI の一種で、
+これは対象のリソースが廃棄されたり利用できなくなった場合にも、 グローバルに他と重なることなく永続しなければならない。
+.PP
+URI は、 web ブラウザなどのツールで ハイパーテキストリンクのリンク先を指定する時の標準的な方法である。 文字列
+"http://www.kernelnotes.org" は URL である (従って URI でもある)。多くの人々は、 URL という言葉をほぼ
+URI の 同義語として使っている (しかし技術的には URL は URI のサブセットである)。
+.PP
+URI は絶対的にも相対的にも指定できる。 絶対的な指定は、リソースをコンテクストに依存しないかたちで参照する。
+相対的な指定は、リソースを現在のコンテクストからの差異によって記述する。 相対パス参照では、 "." および ".." だけのパス部分 (path
+segment) は特別な意味を持ち、 それぞれ「現在の階層レベル」および「現在の階層の一つ上のレベル」 として扱われる (UNIX
+風のシステムと同様)。 コロン文字を含むパス部分は相対 URI パスの先頭に用いることはできない (つまり "this:that"
+はダメ)。スキーム名と区別できないからである。 このような場合には ./ を前置すること (つまり "./this:that" とする)。 MS\-DOS
+の子孫 (Microsoft Windows など) は、 デバイス名のコロンを URI では垂直バー ("|") に置き換える。 したがって "C:"
+は "C|" となる。
+.PP
+フラグメント指定子 (fragment identifier) は、(もし含まれていれば) リソース中の名前付けされた特定の部分 (フラグメント)
+を参照する。 \(aq#\(aq 指定子以降の文字列がフラグメントを指定する。 \(aq#\(aq で始まる URI
+は現在のリソース中のフラグメントを参照する。
+.SS 使い方
+URI のスキームには色々な種類があり、 それぞれ固有のルールや意味が追加されている。 しかしできるだけ統一したものにしようという努力もなされている。
+例えば、多くの URL スキームは「機関 (authority)」に対して以下の書式 (ここでは \fIip_server\fP と呼ぶことにする)
を許している (角括弧内部は省略可能)。
.HP
-.IR "ip_server = " [ user " [ : " password " ] @ ] " host " [ : " port ]
-.PP
-このフォーマットには、ユーザ名、ユーザ名+パスワードを指定できる。
-ポート番号を追加することも可能である。
-.I host
-はホストコンピュータの名前で、 DNS で定義される名前か IP アドレス
-(ピリオドで区切られた数字) で指定する。したがって URI
-<http://fred:fredpassword@xyz.com:8080/>
-は、ホスト xyz.com に fred として (パスワードを使って)
-ポート 8080 を使ってログインする。
-パスワードは可能なら URI には含めないほうが良いだろう。
-パスワードを直書きすると様々なセキュリティ上のリスクが生じるからである。
-URL にユーザ名だけを与え、パスワードを与えない場合は、
-リモートサーバはパスワードを要求してくる。
-URL を解釈したプログラムが、ユーザにこの入力を促すことになろう。
-.PP
-以下に、 UNIX 風のシステムで非常に良く用いられており、
-多くのツールが理解するスキームを示す。
-URI を使うツールの多くでは、内部スキームや特殊なスキームも
-使えることが多い。そのようなスキームに関してはツールのドキュメントを見ること。
-.PP
-.B "http \- Web (HTTP) サーバ"
-.PP
-.RI http:// ip_server / path
+\fIip_server = \fP[\fIuser\fP [ : \fIpassword\fP ] @ ] \fIhost\fP [ : \fIport\fP]
+.PP
+このフォーマットには、ユーザ名、ユーザ名+パスワードを指定できる。 ポート番号を追加することも可能である。 \fIhost\fP
+はホストコンピュータの名前で、 DNS で定義される名前か IP アドレス (ピリオドで区切られた数字) で指定する。したがって URI
+<http://fred:fredpassword@xyz.com:8080/> は、ホスト xyz.com に fred として
+(パスワードを使って) ポート 8080 を使ってログインする。 パスワードは可能なら URI には含めないほうが良いだろう。
+パスワードを直書きすると様々なセキュリティ上のリスクが生じるからである。 URL にユーザ名だけを与え、パスワードを与えない場合は、
+リモートサーバはパスワードを要求してくる。 URL を解釈したプログラムが、ユーザにこの入力を促すことになろう。
+.PP
+以下に、 UNIX 風のシステムで非常に良く用いられており、 多くのツールが理解するスキームを示す。 URI
+を使うツールの多くでは、内部スキームや特殊なスキームも 使えることが多い。そのようなスキームに関してはツールのドキュメントを見ること。
+.PP
+\fBhttp \- Web (HTTP) サーバ\fP
+.PP
+http://\fIip_server\fP/\fIpath\fP
.br
-.RI http:// ip_server / path ? query
-.PP
-これは web (HTTP) サーバにアクセスするための URL である。
-デフォルトのポートは 80。パスがディレクトリを参照しているときは、
-返される情報は web サーバが選択する。通常は、
-"index.html" や "index.htm" のようなファイルがあれば、その内容が返される。
-なければ、カレントディレクトリのリストが (適切なリンクとともに) 生成されて
-返される。例としては <http://lwn.net> など。
-.PP
-問い合わせ (query) を、古い "isindex" フォーマットによって送ることもできる。
-このフォーマットは単語またはフレーズからなり、等号 (=) は含まない。
-より長い "GET" フォーマットでも問い合わせは行える。
-このフォーマットには、一つ以上の問い合わせエントリが
-.IR key = value
-という形式で含まれる。それぞれのエントリはアンパサンド (&) で区切られる。
-.I key
-は複数個指定することもできる。しかしそれに意味があるかどうかは
-web サーバとアプリケーションプログラムが決める。
-HTML/XML/SGML と GET 問い合わせ形式の間には、不幸な関係がある。
-一つ以上のキーの含まれる URI が SGML/XML 文書 (HTML もそう)
-に埋めこまれる際には、アンパサンド (&) は & と書かなければならない。
-全ての問い合わせがこの形式を使うわけではない。
-フォームが長くなると URI に入れるには長すぎるから、
-別の通信メカニズム (POST と呼ばれる) が用いられる。
-POST では URI にはデータは含まれない。
-より詳しい情報は、
-<http://www.w3.org/CGI> にある
-Common Gateway Interface の仕様書を見よ。
-.PP
-.B "ftp \- ファイル転送プロトコル (FTP)"
-.PP
-.RI ftp:// ip_server / path
-.PP
-これはファイル転送プロトコル (FTP) を通してファイルにアクセスするための
-URL である。デフォルトの (制御用) ポートは 21 である。
-ユーザ名がない場合には、ユーザ名 anonymous が与えられる。
-そしてその場合には、クライアントの多くは要求した人の
-インターネットメールアドレスをパスワードとして与える。
-例としては <ftp://ftp.is.co.za/rfc/rfc1808.txt> など。
-.PP
-.B "gofer \- Gofer サーバ"
-.PP
-.RI gopher:// ip_server / "gophertype selector"
+http://\fIip_server\fP/\fIpath\fP?\fIquery\fP
+.PP
+これは web (HTTP) サーバにアクセスするための URL である。 デフォルトのポートは 80。パスがディレクトリを参照しているときは、
+返される情報は web サーバが選択する。通常は、 "index.html" や "index.htm" のようなファイルがあれば、その内容が返される。
+なければ、カレントディレクトリのリストが (適切なリンクとともに) 生成されて 返される。例としては <http://lwn.net>
+など。
+.PP
+問い合わせ (query) を、古い "isindex" フォーマットによって送ることもできる。 このフォーマットは単語またはフレーズからなり、等号
+(=) は含まない。 より長い "GET" フォーマットでも問い合わせは行える。 このフォーマットには、一つ以上の問い合わせエントリが
+\fIkey\fP=\fIvalue\fP という形式で含まれる。それぞれのエントリはアンパサンド (&) で区切られる。 \fIkey\fP
+は複数個指定することもできる。しかしそれに意味があるかどうかは web サーバとアプリケーションプログラムが決める。 HTML/XML/SGML と
+GET 問い合わせ形式の間には、不幸な関係がある。 一つ以上のキーの含まれる URI が SGML/XML 文書 (HTML もそう)
+に埋めこまれる際には、アンパサンド (&) は & と書かなければならない。 全ての問い合わせがこの形式を使うわけではない。
+フォームが長くなると URI に入れるには長すぎるから、 別の通信メカニズム (POST と呼ばれる) が用いられる。 POST では URI
+にはデータは含まれない。 より詳しい情報は、 <http://www.w3.org/CGI> にある Common Gateway
+Interface の仕様書を見よ。
+.PP
+\fBftp \- ファイル転送プロトコル (FTP)\fP
+.PP
+ftp://\fIip_server\fP/\fIpath\fP
+.PP
+これはファイル転送プロトコル (FTP) を通してファイルにアクセスするための URL である。デフォルトの (制御用) ポートは 21 である。
+ユーザ名がない場合には、ユーザ名 anonymous が与えられる。 そしてその場合には、クライアントの多くは要求した人の
+インターネットメールアドレスをパスワードとして与える。 例としては
+<ftp://ftp.is.co.za/rfc/rfc1808.txt> など。
+.PP
+\fBgofer \- Gofer サーバ\fP
+.PP
+gopher://\fIip_server\fP/\fIgophertype selector\fP
.br
-.RI gopher:// ip_server / "gophertype selector" %09 search
+gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP
.br
-.RI gopher:// ip_server / "gophertype selector" %09 search %09 gopher+_string
+gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP%09\fIgopher+_string\fP
.br
.PP
-デフォルトの gopher ポートは 70 である。
-.I gophertype
-は 1 文字からなるフィールドで、
-URL が参照している Gopher のリソースタイプを示す。
-パス全体が空であってもよく、その場合は区切りの "/" も省略できる。
-このとき gophertype のデフォルトは "1" になる。
+デフォルトの gopher ポートは 70 である。 \fIgophertype\fP は 1 文字からなるフィールドで、 URL が参照している
+Gopher のリソースタイプを示す。 パス全体が空であってもよく、その場合は区切りの "/" も省略できる。 このとき gophertype
+のデフォルトは "1" になる。
.PP
-.I selector
-は Gopher セレクタ文字列である。Gopher プロトコルでは、
-Gopher セレクタ文字列はオクテット文字からなり、
-16進数の 09 (US-ASCII の HT または tab)、 0A (US-ASCII の LF 文字)、
-0D (US-ASCII の CR 文字) 以外ならどんなオクテットも指定できる。
+\fIselector\fP は Gopher セレクタ文字列である。Gopher プロトコルでは、 Gopher セレクタ文字列はオクテット文字からなり、
+16進数の 09 (US\-ASCII の HT または tab)、 0A (US\-ASCII の LF 文字)、 0D (US\-ASCII の CR
+文字) 以外ならどんなオクテットも指定できる。
.PP
-.B "mailto \- 電子メールアドレス"
+\fBmailto \- 電子メールアドレス\fP
.PP
-.RI mailto: email-address
+mailto:\fIemail\-address\fP
.PP
-これは電子メールアドレスで、通常
-.IR name @ hostname
-という形式をとる。電子メールアドレスの正しいフォーマットに関する
-より詳しい情報は
-.BR mailaddr (7)
-を見よ。 % 文字はすべて %25 と書き直さなければならないことに注意。
-例としては <mailto:dwheeler@dwheeler.com> など。
+これは電子メールアドレスで、通常 \fIname\fP@\fIhostname\fP という形式をとる。電子メールアドレスの正しいフォーマットに関する
+より詳しい情報は \fBmailaddr\fP(7) を見よ。 % 文字はすべて %25 と書き直さなければならないことに注意。 例としては
+<mailto:dwheeler@dwheeler.com> など。
.PP
-.B "news \- ニュースグループ・ニュースメッセージ"
+\fBnews \- ニュースグループ・ニュースメッセージ\fP
.PP
-.RI news: newsgroup-name
+news:\fInewsgroup\-name\fP
.br
-.RI news: message-id
+news:\fImessage\-id\fP
.PP
-.I newsgroup-name
-はピリオドで区切られた階層的な名前である。例えば
-"comp.infosystems.www.misc" など。
-<newsgroup-name> が "*" (つまり <news:*>) の場合には、
-「参照できる全てのニュースグループ」の意味になる。
-例としては <news:comp.lang.ada> など。
+\fInewsgroup\-name\fP はピリオドで区切られた階層的な名前である。例えば "comp.infosystems.www.misc" など。
+<newsgroup\-name> が "*" (つまり <news:*>) の場合には、
+「参照できる全てのニュースグループ」の意味になる。 例としては <news:comp.lang.ada> など。
.PP
-.I message-id
-は
+\fImessage\-id\fP は
.UR http://www.ietf.org/rfc/rfc1036.txt
IETF RFC\ 1036
.UE
-の Message-ID から、囲みの "<" と ">" を取ったものに対応する。
-Message-ID は
-.IR unique @ full_domain_name
-という形式をとる。メッセージの指定には "@" 文字が含まれるので、
+の Message\-ID から、囲みの "<" と ">" を取ったものに対応する。 Message\-ID は
+\fIunique\fP@\fIfull_domain_name\fP という形式をとる。メッセージの指定には "@" 文字が含まれるので、
ニュースグループの名前と区別できるだろう。
.PP
-.B "telnet \- telnet ログイン"
+\fBtelnet \- telnet ログイン\fP
.PP
-.RI telnet:// ip_server /
+telnet://\fIip_server\fP/
.PP
-Telnet URL スキームは対話的なテキストサービスに Telnet プロトコルを
-通してアクセスするために用いられる。最後の "/" 文字は省略してよい。
-例としては <telnet://melvyl.ucop.edu/> など。
+Telnet URL スキームは対話的なテキストサービスに Telnet プロトコルを 通してアクセスするために用いられる。最後の "/"
+文字は省略してよい。 例としては <telnet://melvyl.ucop.edu/> など。
.PP
-.B "file \- 通常のファイル"
+\fBfile \- 通常のファイル\fP
.PP
-.RI file:// ip_server / path_segments
+file://\fIip_server\fP/\fIpath_segments\fP
.br
-.RI file: path_segments
-.PP
-これはローカルに直接アクセスできるファイルを示す。
-特殊なケースとして、
-.I host
-には "localhost" という文字列を用いたり、空文字にしてもよい。
-これは「URI が解釈されたマシン」とみなされる。
-path がディレクトリの場合は、ビューアはディレクトリの内容を
-リンクを張ったかたちで表示するとよいだろう。
-しかし現在は、まだ全てのビューアがこの動作をするわけではない。
-KDE は生成ファイル (generated file) を URL <file:/cgi-bin>
-の形式でサポートしている。
-与えられたファイルが見付からなかった場合は、
-ファイル名をグロブによって展開すると良いかもしれない
-.RB ( glob (7)
-および
-.BR glob (3)
-を見よ)。
+file:\fIpath_segments\fP
+.PP
+これはローカルに直接アクセスできるファイルを示す。 特殊なケースとして、 \fIhost\fP には "localhost"
+という文字列を用いたり、空文字にしてもよい。 これは「URI が解釈されたマシン」とみなされる。 path
+がディレクトリの場合は、ビューアはディレクトリの内容を リンクを張ったかたちで表示するとよいだろう。
+しかし現在は、まだ全てのビューアがこの動作をするわけではない。 KDE は生成ファイル (generated file) を URL
+<file:/cgi\-bin> の形式でサポートしている。 与えられたファイルが見付からなかった場合は、
+ファイル名をグロブによって展開すると良いかもしれない (\fBglob\fP(7) および \fBglob\fP(3) を見よ)。
.PP
二つめの書式 (例えば <file:/etc/passwd>) もローカルファイルを参照する
-正しいフォーマットである。しかし古い標準ではこの書式を許していなかったので、
-これを URI として認識しないプログラムも存在する。
-より汎用的な文法は、サーバ名に空文字を用いるもの、
-つまり <file:///etc/passwd> のようなものである。
-この形式も指す内容は同じであり、パターンマッチやより古いプログラムでも
-URI として認識されやすい。
-もし意図するところが「現在の場所からスタート」なら、
-スキームは一切用いるべきではない。
-<../test.txt> のような、スキームに依存しない相対リンクを用いること。
-このスキームの例としては <file:///etc/passwd> など。
-.PP
-.B "man \- man ページ文書"
-.PP
-.RI man: command-name
+正しいフォーマットである。しかし古い標準ではこの書式を許していなかったので、 これを URI として認識しないプログラムも存在する。
+より汎用的な文法は、サーバ名に空文字を用いるもの、 つまり <file:///etc/passwd> のようなものである。
+この形式も指す内容は同じであり、パターンマッチやより古いプログラムでも URI として認識されやすい。
+もし意図するところが「現在の場所からスタート」なら、 スキームは一切用いるべきではない。 <../test.txt>
+のような、スキームに依存しない相対リンクを用いること。 このスキームの例としては <file:///etc/passwd> など。
+.PP
+\fBman \- man ページ文書\fP
+.PP
+man:\fIcommand\-name\fP
.br
-.RI man: command-name ( section )
+man:\fIcommand\-name\fP(\fIsection\fP)
.PP
-これはローカルのオンラインマニュアル (man) リファレスページを参照する。
-command-name には括弧とセクション番号を追加してもよい。
-セクション番号の意味について詳しく知りたい場合は
-.BR man (7)
-をみよ。この URI スキームは UNIX 風のシステム (Linux など)
-に特有のものであり、現在はまだ IETF による登録はされていない。
-例としては <man:ls(1)> など。
+これはローカルのオンラインマニュアル (man) リファレスページを参照する。 command\-name には括弧とセクション番号を追加してもよい。
+セクション番号の意味について詳しく知りたい場合は \fBman\fP(7) をみよ。この URI スキームは UNIX 風のシステム (Linux など)
+に特有のものであり、現在はまだ IETF による登録はされていない。 例としては <man:ls(1)> など。
.PP
-.B "info \- info ページ文書"
+\fBinfo \- info ページ文書\fP
.PP
-.RI info: virtual-filename
+info:\fIvirtual\-filename\fP
.br
-.RI info: virtual-filename # nodename
+info:\fIvirtual\-filename\fP#\fInodename\fP
.br
-.RI info:( virtual-filename )
+info:(\fIvirtual\-filename\fP)
.br
-.RI info:( virtual-filename ) nodename
+info:(\fIvirtual\-filename\fP)\fInodename\fP
.PP
-このスキームは、オンラインの info リファレンスページ
-(texinfo ファイルから生成される) を参照する。 info ページは
-GNU ツールなどのプログラムで用いられている文書フォーマットである。
-この URI スキームは UNIX 風のシステム (Linux など)
-に特有のものであり、現在はまだ IETF による登録はされていない。
-この文書の執筆時において、 GNOME と KDE はそれぞれ異なる文法の URI
-を用いており、お互い相手の文法を受け入れない。
-最初の 2 つの書式は GNOME の書式である。ノード名 (nodename)
-のスペースはすべてアンダースコアに変換される。
-3 つめと 4 つめは KDE の書式である。ノード名のスペースは
-そのままスペースで書かれる
-(URI の標準では禁止されているのだが)。
-将来は多くのツールがこれらの書式すべてを理解するようになり、
-ノード名のアンダースコア、スペースを両方とも理解できるように
-なることを期待したい。 GNOME でも KDE でも、
-ノード名が省略された場合は、ノード名として "Top" が用いられる。
-GNOME 書式の例としては <info:gcc> や <info:gcc#G++_and_GCC> など、
-KDE 書式の例としては <info:(gcc)> や <info:(gcc)G++ and GCC> など。
-.PP
-.B "whatis \- 文書検索"
-.PP
-.RI whatis: string
-.PP
-このスキームは、コマンドに関する短い (1 行の) 説明を集めた
-データベースを検索し、 string を含む文字列をリストして返す。
-単語が完全にマッチした結果だけが返される。
-.BR whatis (1)
-を見よ。
-この URI スキームは UNIX 風のシステム (Linux など)
+このスキームは、オンラインの info リファレンスページ (texinfo ファイルから生成される) を参照する。 info ページは GNU
+ツールなどのプログラムで用いられている文書フォーマットである。 この URI スキームは UNIX 風のシステム (Linux など)
+に特有のものであり、現在はまだ IETF による登録はされていない。 この文書の執筆時において、 GNOME と KDE はそれぞれ異なる文法の URI
+を用いており、お互い相手の文法を受け入れない。 最初の 2 つの書式は GNOME の書式である。ノード名 (nodename)
+のスペースはすべてアンダースコアに変換される。 3 つめと 4 つめは KDE の書式である。ノード名のスペースは そのままスペースで書かれる (URI
+の標準では禁止されているのだが)。 将来は多くのツールがこれらの書式すべてを理解するようになり、
+ノード名のアンダースコア、スペースを両方とも理解できるように なることを期待したい。 GNOME でも KDE でも、
+ノード名が省略された場合は、ノード名として "Top" が用いられる。 GNOME 書式の例としては <info:gcc> や
+<info:gcc#G++_and_GCC> など、 KDE 書式の例としては <info:(gcc)> や
+<info:(gcc)G++ and GCC> など。
+.PP
+\fBwhatis \- 文書検索\fP
+.PP
+whatis:\fIstring\fP
+.PP
+このスキームは、コマンドに関する短い (1 行の) 説明を集めた データベースを検索し、 string を含む文字列をリストして返す。
+単語が完全にマッチした結果だけが返される。 \fBwhatis\fP(1) を見よ。 この URI スキームは UNIX 風のシステム (Linux など)
に特有のものであり、現在はまだ IETF による登録はされていない。
.PP
-.B "ghelp \- GNOME ヘルプ文書"
+\fBghelp \- GNOME ヘルプ文書\fP
.PP
-.RI ghelp: name-of-application
+ghelp:\fIname\-of\-application\fP
.PP
-与えられた application に対応する GNOME help をロードする。
-この書式を用いた文書はまだあまり多くない。
+与えられた application に対応する GNOME help をロードする。 この書式を用いた文書はまだあまり多くない。
.PP
-.B "ldap \- 軽量ディレクトリアクセスプロトコル"
+\fBldap \- 軽量ディレクトリアクセスプロトコル\fP
.PP
-.RI ldap:// hostport
+ldap://\fIhostport\fP
.br
-.RI ldap:// hostport /
+ldap://\fIhostport\fP/
.br
-.RI ldap:// hostport / dn
+ldap://\fIhostport\fP/\fIdn\fP
.br
-.RI ldap:// hostport / dn ? attributes
+ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP
.br
-.RI ldap:// hostport / dn ? attributes ? scope
+ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP
.br
-.RI ldap:// hostport / dn ? attributes ? scope ? filter
+ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP
.br
-.RI ldap:// hostport / dn ? attributes ? scope ? filter ? extensions
+ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP?\fIextensions\fP
.PP
-このスキームは Lightweight Directory Access Protocol (LDAP)
-へのクエリーをサポートする。 LDAP は複数のサーバに分散した、
-階層化された情報 (人々や計算資源など) に問い合わせるための
-プロトコルである。 LDAP の URL スキームに関するより詳しい情報は
+このスキームは Lightweight Directory Access Protocol (LDAP) へのクエリーをサポートする。 LDAP
+は複数のサーバに分散した、 階層化された情報 (人々や計算資源など) に問い合わせるための プロトコルである。 LDAP の URL
+スキームに関するより詳しい情報は
.UR http://www.ietf.org/rfc/rfc2255.txt
RFC\ 2255
.UE
-で見ることができる。
-この URL の各部は以下の通り:
+で見ることができる。 この URL の各部は以下の通り:
.IP hostport 12
-クエリーを行う LDAP サーバ。ホスト名を書く。続けてコロンとポート番号を
-追加することもできる。 LDAP のデフォルトのポートは TCP ポート 389 である。
-省略されると、どの LDAP サーバを用いるかはクライアントが決定する。
+クエリーを行う LDAP サーバ。ホスト名を書く。続けてコロンとポート番号を 追加することもできる。 LDAP のデフォルトのポートは TCP ポート
+389 である。 省略されると、どの LDAP サーバを用いるかはクライアントが決定する。
.IP dn
-LDAP の Distintuished Name (識別名)。
-LDAP 検索の base オブジェクトを指定するものである (
+LDAP の Distintuished Name (識別名)。 LDAP 検索の base オブジェクトを指定するものである (
.UR http://www.ietf.org/rfc/rfc2253.txt
RFC\ 2253
.UE
の section 3 を見よ)。
.IP attributes
-コンマ区切りの、返される属性 (attribute) のリスト。
-RFC\ 2251 の section 4.1.5 を見よ。省略されると全ての属性が返される。
+コンマ区切りの、返される属性 (attribute) のリスト。 RFC\ 2251 の section 4.1.5
+を見よ。省略されると全ての属性が返される。
.IP scope
-検索のスコープを指定する。
-"base" (base オブジェクト検索), "one" (1 レベル検索),
-"sub" (サブツリー検索) のいずれかを指定する。
-省略すると "base" が仮定される。
+検索のスコープを指定する。 "base" (base オブジェクト検索), "one" (1 レベル検索), "sub" (サブツリー検索)
+のいずれかを指定する。 省略すると "base" が仮定される。
.IP filter
-検索フィルタ (返されるエントリのサブセット) を指定する。
-省略されると、全てのエントリが返される。
+検索フィルタ (返されるエントリのサブセット) を指定する。 省略されると、全てのエントリが返される。
.UR http://www.ietf.org/rfc/rfc2254.txt
RFC\ 2254
.UE
の section 4 を見よ。
.IP extensions
-コンマで区切られた type=value ペアのリスト。
-ここで =value の部分は、それを要求しないオプションに対しては
-省略できる。 \(aq!\(aq が前置された extension は critical
-(サポートしていなければならない) であり、
-そうでなければ critical ではない (省略できる)。
+コンマで区切られた type=value ペアのリスト。 ここで =value の部分は、それを要求しないオプションに対しては 省略できる。
+\(aq!\(aq が前置された extension は critical (サポートしていなければならない) であり、 そうでなければ
+critical ではない (省略できる)。
.PP
-LDAP のクエリーは、例とともに説明するのが最も簡単である。
-次の例は、 ldap.itd.umich.edu に、
-U.S. にある University of Michigan の情報を尋ねる例である。
+LDAP のクエリーは、例とともに説明するのが最も簡単である。 次の例は、 ldap.itd.umich.edu に、 U.S. にある
+University of Michigan の情報を尋ねる例である。
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
.fi
.PP
-郵便用の住所属性だけを取得する場合は、
-次のようにリクエストする:
+郵便用の住所属性だけを取得する場合は、 次のようにリクエストする:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
.fi
.PP
-host.com のポート 6666 に、 University of Michigan にいる
-common name (cn) が "Babs Jenson" の人の情報を尋ねる場合は、
-次のようにリクエストする:
+host.com のポート 6666 に、 University of Michigan にいる common name (cn) が "Babs
+Jenson" の人の情報を尋ねる場合は、 次のようにリクエストする:
.PP
.nf
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
.fi
.PP
-.B "wais \- 広域情報サービス"
+\fBwais \- 広域情報サービス\fP
.PP
-.RI wais:// hostport / database
+wais://\fIhostport\fP/\fIdatabase\fP
.br
-.RI wais:// hostport / database ? search
+wais://\fIhostport\fP/\fIdatabase\fP?\fIsearch\fP
.br
-.RI wais:// hostport / database / wtype / wpath
+wais://\fIhostport\fP/\fIdatabase\fP/\fIwtype\fP/\fIwpath\fP
.PP
-このスキームは WAIS のデータベース、検索、文書を指定する
-(WAIS に関する詳しい情報は
+このスキームは WAIS のデータベース、検索、文書を指定する (WAIS に関する詳しい情報は
.UR http://www.ietf.org/rfc/rfc1625.txt
IETF RFC\ 1625
.UE
-を見よ)。
-hostport は、ホスト名にコロンとポート番号を付加したものである
-(コロン + ポート番号は省略可。デフォルトのポート番号は 210 である)。
-.PP
-最初の書式は WAIS のデータベースに対する検索の指定である。
-二つめの書式は特定の WAIS データベース
-.I database
-に対する検索の指定である。
-三つめの書式は WAIS データベースにある特定の文書を取出す指定である。
-.I wtype
-は WAIS のオブジェクト形式指定であり、
-.I wpath
-は WAIS document-id である。
-.PP
-.B その他のスキーム
-.PP
-他にも多くの URI スキームが存在する。
-URI を受付けるほとんどのツールは、内部 URI のセットをサポートする
-(例えば Mozilla は内部情報用の about: というスキームを受付けるし、
-GNOME ヘルプブラウザはいろいろな出発点用に toc: というスキームを持っている)。
-定義されたスキームはたくさんあるが、現時点で広く用いられてはいない
-(例えば prospero とか)。
-nntp: スキームは news: スキームが好んで用いられるようになったので
-使わないほうが良い。 URN は urn: スキームによって、階層的な名前空間
-(例えば urn:ietf:... は IETF 文書を示す)
-としてサポートされるべきであるが、現時点では URN はあまり用いられていない。
+を見よ)。 hostport は、ホスト名にコロンとポート番号を付加したものである (コロン + ポート番号は省略可。デフォルトのポート番号は 210
+である)。
+.PP
+最初の書式は WAIS のデータベースに対する検索の指定である。 二つめの書式は特定の WAIS データベース \fIdatabase\fP
+に対する検索の指定である。 三つめの書式は WAIS データベースにある特定の文書を取出す指定である。 \fIwtype\fP は WAIS
+のオブジェクト形式指定であり、 \fIwpath\fP は WAIS document\-id である。
+.PP
+\fBその他のスキーム\fP
+.PP
+他にも多くの URI スキームが存在する。 URI を受付けるほとんどのツールは、内部 URI のセットをサポートする (例えば Mozilla
+は内部情報用の about: というスキームを受付けるし、 GNOME ヘルプブラウザはいろいろな出発点用に toc: というスキームを持っている)。
+定義されたスキームはたくさんあるが、現時点で広く用いられてはいない (例えば prospero とか)。 nntp: スキームは news:
+スキームが好んで用いられるようになったので 使わないほうが良い。 URN は urn: スキームによって、階層的な名前空間 (例えば
+urn:ietf:... は IETF 文書を示す) としてサポートされるべきであるが、現時点では URN はあまり用いられていない。
全てのツールが全てのスキームをサポートしているわけではない。
.SS 文字エンコード
.PP
URI では、色々な状況下で入力できるように、文字の種類を制限している。
.PP
-以下の文字は予約されている。すなわち、これらの文字は
-URI に登場することがあるが、それらの利用法 (解釈のされ方) は
-予約された目的に制限されている (衝突するデータは
-URI にする前にエスケープしなければならない)。
+以下の文字は予約されている。すなわち、これらの文字は URI に登場することがあるが、それらの利用法 (解釈のされ方) は
+予約された目的に制限されている (衝突するデータは URI にする前にエスケープしなければならない)。
.IP
; / ? : @ & = + $ ,
.PP
-未予約文字 (unreserved character) は URI に使ってよい。
-これには英字の大文字と小文字、10 進の数字、および
+未予約文字 (unreserved character) は URI に使ってよい。 これには英字の大文字と小文字、10 進の数字、および
以下の句読文字・記号が含まれる
.IP
\- _ . ! ~ * ' ( )
.PP
-他の文字はすべてエスケープしなければならない。
-エスケープされたオクテットは 3 文字からなる:
-先頭にパーセント文字 "%"、それに続けてオクテットコードを表す
-2 文字の 16 進数字である (16 進数の英字は大文字小文字どちらでも良い)。
-例えば空白文字は "%20" のようにエスケープしなければならず、
-タブ文字は "%09"、 "&" は "%26" となる。
-パーセント文字 "%" は常にエスケープを示す予約された目的に用いられるので、
-"%" 自身を表すには "%25" とエスケープしなければならない。
-クエリーのテキストでは、スペース文字をプラス記号 (+) でエスケープすることも
-一般に良く行われる。この慣例は関連 RFC で実際に定義されているわけではない
-(代わりに %20 を推奨している) が、クエリーテキストを受付ける
-ツールは、この書式への対応を用意しておくべきであろう。
-URI は、常に「エスケープされた」かたちで表示される。
-.PP
-未予約文字もエスケープすることができ、これによって
-URI の意味するところが変わるわけではない。
-しかしURI にその非エスケープ文字が現れることが許されないような
-特殊な場合を除いて、これは避けるべきである。
-例えば、 HTTP URL の path において
-"%7e" が "~" の代わりに用いられることがあるが、
-この二つは HTTP URL としては等価である。
-.PP
-US ASCII キャラクタセット以外の文字を URI として扱う場合、
-HTML 4.1 規格 (section B.2) 及び IETF RFC\ 2718 (section 2.2.5) は
-以下の手法を用いるよう推奨している。
+他の文字はすべてエスケープしなければならない。 エスケープされたオクテットは 3 文字からなる: 先頭にパーセント文字
+"%"、それに続けてオクテットコードを表す 2 文字の 16 進数字である (16 進数の英字は大文字小文字どちらでも良い)。 例えば空白文字は
+"%20" のようにエスケープしなければならず、 タブ文字は "%09"、 "&" は "%26" となる。 パーセント文字 "%"
+は常にエスケープを示す予約された目的に用いられるので、 "%" 自身を表すには "%25" とエスケープしなければならない。
+クエリーのテキストでは、スペース文字をプラス記号 (+) でエスケープすることも 一般に良く行われる。この慣例は関連 RFC
+で実際に定義されているわけではない (代わりに %20 を推奨している) が、クエリーテキストを受付ける
+ツールは、この書式への対応を用意しておくべきであろう。 URI は、常に「エスケープされた」かたちで表示される。
+.PP
+未予約文字もエスケープすることができ、これによって URI の意味するところが変わるわけではない。 しかしURI
+にその非エスケープ文字が現れることが許されないような 特殊な場合を除いて、これは避けるべきである。 例えば、 HTTP URL の path において
+"%7e" が "~" の代わりに用いられることがあるが、 この二つは HTTP URL としては等価である。
+.PP
+US ASCII キャラクタセット以外の文字を URI として扱う場合、 HTML 4.1 規格 (section B.2) 及び IETF RFC\ 2718 (section 2.2.5) は 以下の手法を用いるよう推奨している。
.IP 1. 4
-キャラクタ列を UTF-8 (IETF RFC\ 2279,
-.BR utf-8 (7)
-参照) に変換し、
+キャラクタ列を UTF\-8 (IETF RFC\ 2279, \fButf\-8\fP(7) 参照) に変換し、
.IP 2.
-URI エスケープ機構を用いる。
-つまり、安全でないオクテットを %HH でエンコードする。
+URI エスケープ機構を用いる。 つまり、安全でないオクテットを %HH でエンコードする。
.SS "URI を書くには"
-URI を書く時には、ダブルクォートの内部に書く
-(例: "http://www.kernelnotes.org") か、
-angle ブラケットで囲む (例: <http://lwn.net>) か、
-一行に URI だけを書くかする。
-ダブルクォートを使う人に警告:
-\fB絶対に\fP句読点 (文末のピリオドやリスト区切りのコンマ) を
-URI の内部に移動してはならない。
-代わりに angle ブラケットを使うか、
-外にある文字をクォーテーションマークの内部に
-決して含めないような引用方式に切替えること。
-後者の方式は "Hart's Rules" や
-"Oxford Dictionary for Writers and Editors" によれば
-「新しい (new) 引用方式」あるいは「論理的 (logical) な引用方式」
-と呼ばれており、 イギリス人や世界中のハッカー達はこちらの慣習を好んでいる
-(より詳しい情報は
-Hacker Writing Style の Jargon File のセクション
-.I http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html
-を見よ)。
-古い文書では、 "URL:" という文字列を URI の直前に挿入することを
-勧めているものもあるが、しかしこの形式はまったく流行しなかった。
-.PP
-URI の書式は曖昧さを排除するように設計されている。
-しかし URI が広まるにつれ、昔ながらのメディア (TV、ラジオ、新聞、
-看板などなど) は URI 参照を省略したかたち、すなわち
-機関部とパス部だけでリソースを指定することが多くなっている
-(例: <www.w3.org/Addressing>)。
-このような参照はマシンというよりは人間向けのもので、
-コンテキストベースの推測によって URI の補完が可能であることを
-あてにしているのである (例えば "www" ではじまるホスト名なら
-"http://" がつくだろうし、 "ftp" ではじまるホスト名なら
-"ftp://" がつくだろう)。
-多くのクライアントの実装では、この種の参照を推測によって解決する。
-このような推測は時代とともに変わりうる。
-特に新しいスキームが導入されるとそうである。
-URI の省略形では相対 URL パスの区別が付けられないので、
-省略形 URI 参照は相対 URI の利用できるところでは使えない。
-つまり定義済みのベース (ダイアログボックスなど)
-がない場合に限って利用できる。
-.\"nakano: この文脈での dialog box とは？
-文書内部でのハイパーテキストリンクには省略形 URI を使ってはならない。
-上述の標準フォーマットを使うこと。
+URI を書く時には、ダブルクォートの内部に書く (例: "http://www.kernelnotes.org") か、 angle ブラケットで囲む
+(例: <http://lwn.net>) か、 一行に URI だけを書くかする。 ダブルクォートを使う人に警告: \fB絶対に\fP句読点
+(文末のピリオドやリスト区切りのコンマ) を URI の内部に移動してはならない。 代わりに angle ブラケットを使うか、
+外にある文字をクォーテーションマークの内部に 決して含めないような引用方式に切替えること。 後者の方式は "Hart's Rules" や
+"Oxford Dictionary for Writers and Editors" によれば 「新しい (new) 引用方式」あるいは「論理的
+(logical) な引用方式」 と呼ばれており、 イギリス人や世界中のハッカー達はこちらの慣習を好んでいる (より詳しい情報は Hacker
+Writing Style の Jargon File のセクション
+\fIhttp://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html\fP を見よ)。 古い文書では、
+"URL:" という文字列を URI の直前に挿入することを 勧めているものもあるが、しかしこの形式はまったく流行しなかった。
+.PP
+URI の書式は曖昧さを排除するように設計されている。 しかし URI が広まるにつれ、昔ながらのメディア (TV、ラジオ、新聞、 看板などなど) は
+URI 参照を省略したかたち、すなわち 機関部とパス部だけでリソースを指定することが多くなっている (例:
+<www.w3.org/Addressing>)。 このような参照はマシンというよりは人間向けのもので、
+コンテキストベースの推測によって URI の補完が可能であることを あてにしているのである (例えば "www" ではじまるホスト名なら
+"http://" がつくだろうし、 "ftp" ではじまるホスト名なら "ftp://" がつくだろう)。
+多くのクライアントの実装では、この種の参照を推測によって解決する。 このような推測は時代とともに変わりうる。
+特に新しいスキームが導入されるとそうである。 URI の省略形では相対 URL パスの区別が付けられないので、 省略形 URI 参照は相対 URI
+の利用できるところでは使えない。 つまり定義済みのベース (ダイアログボックスなど) がない場合に限って利用できる。
+文書内部でのハイパーテキストリンクには省略形 URI を使ってはならない。 上述の標準フォーマットを使うこと。
.SH 準拠
.PP
-.I http://www.ietf.org/rfc/rfc2396.txt
-(IETF RFC\ 2396),
-.UE
-.I http://www.w3.org/TR/REC-html40
-(HTML 4.0).
+\fIhttp://www.ietf.org/rfc/rfc2396.txt\fP (IETF RFC\ 2396),
+\fIhttp://www.w3.org/TR/REC\-html40\fP (HTML 4.0).
.SH 注意
-Linux システムで URI を受付けるツール (例えば web ブラウザなど) は、
-上にあげた全てのスキームを (直接または間接に) 扱えるべきである。
-man: や info: も含めて、である。
-スキームの処理に他のプログラムを実行するのは良いことだし、
+Linux システムで URI を受付けるツール (例えば web ブラウザなど) は、 上にあげた全てのスキームを (直接または間接に)
+扱えるべきである。 man: や info: も含めて、である。 スキームの処理に他のプログラムを実行するのは良いことだし、
実はすすんでそうすべきである。
.PP
技術的には、フラグメントは URI の一部ではない。
.PP
-URI (URL も含む) をデータフォーマットに埋めこむ方法に関する情報は、
-そのフォーマットのドキュメントを見よ。 HTML は
-<A HREF="\fIuri\fP">\fItext\fP</A>
-を用いる。 texinfo は @uref{\fIuri\fP} という書式を用いる。
-man と mdoc は、最近追加された UR マクロを使う。
-あるいは URI をそのままテキストに埋めこむ
-(ビューアが :// を URI の一部と解釈できなければならない)。
-.PP
-デスクトップ環境である GNOME と KDE は、
-それぞれ受付ける URI が (特にそれぞれのヘルプブラウザにおいて)
-異なっている。
-man ページをリストするには、
-GNOME では <toc:man> を用い、 KDE では <man:(index)> を用いる。
-また info ページをリストするには、
-GNOME では <toc:info> を用い、 KDE では <info:(dir)> を用いる
-(本 man ページの著者は KDE のアプローチのほうが好みである。
-しかしより標準的な書式の方が更に良いが)。
-一般に KDE は生成ファイル (generated file) のプレフィックスとして
-<file:/cgi-bin/> を用いる。
-.\"nakano: 意味ワカラン... KDE に詳しい人〜
-KDE は HTML の文書を
-<file:/cgi-bin/helpindex> 経由でアクセスするのが好みなようである。
-GNOME は文書の保管・検索に ghelp スキームを用いる方法を取っているようだ。
-どちらのブラウザも、現時点では file: によるディレクトリ参照を扱えない。
-したがってディレクトリ全体をブラウズ可能な URI で参照することが難しい。
-先に述べたように、これら二つの環境では info: スキームの
-扱いが異なっている (おそらく最も重要な差異であろう)。
-GNOME と KDE が共通 URI フォーマットに収斂することが望ましい。
-この man ページが、将来はその収斂した結果を記述できることを望む。
-この作業への助力を喚起したい。
+URI (URL も含む) をデータフォーマットに埋めこむ方法に関する情報は、 そのフォーマットのドキュメントを見よ。 HTML は <A
+HREF="\fIuri\fP">\fItext\fP</A> を用いる。 texinfo は @uref{\fIuri\fP}
+という書式を用いる。 man と mdoc は、最近追加された UR マクロを使う。 あるいは URI をそのままテキストに埋めこむ (ビューアが
+:// を URI の一部と解釈できなければならない)。
+.PP
+デスクトップ環境である GNOME と KDE は、 それぞれ受付ける URI が (特にそれぞれのヘルプブラウザにおいて) 異なっている。 man
+ページをリストするには、 GNOME では <toc:man> を用い、 KDE では <man:(index)>
+を用いる。 また info ページをリストするには、 GNOME では <toc:info> を用い、 KDE では
+<info:(dir)> を用いる (本 man ページの著者は KDE のアプローチのほうが好みである。
+しかしより標準的な書式の方が更に良いが)。 一般に KDE は生成ファイル (generated file) のプレフィックスとして
+<file:/cgi\-bin/> を用いる。 KDE は HTML の文書を
+<file:/cgi\-bin/helpindex> 経由でアクセスするのが好みなようである。 GNOME は文書の保管・検索に
+ghelp スキームを用いる方法を取っているようだ。 どちらのブラウザも、現時点では file: によるディレクトリ参照を扱えない。
+したがってディレクトリ全体をブラウズ可能な URI で参照することが難しい。 先に述べたように、これら二つの環境では info: スキームの
+扱いが異なっている (おそらく最も重要な差異であろう)。 GNOME と KDE が共通 URI フォーマットに収斂することが望ましい。 この man
+ページが、将来はその収斂した結果を記述できることを望む。 この作業への助力を喚起したい。
.SS セキュリティ
.PP
-URI そのものはセキュリティの脅威を引き起こすものではない。
-ある時点ではリソースの場所を与えていた URL が、
-ずっとそうでありつづけるという保証は一般にはない。
-またある URL が、将来には別のリソースを示さないとも限らない。
-このような保証は、その名前空間とリソースとを管理している個人に
-帰するものに過ぎない。
-.PP
-無害に見える操作 (リソースに関連づけられたエンティティの取得など)
-によって、実際にはリモートにダメージを与える動作を引き起こすような
-URL を記述することも場合によっては可能である。
-危険な URL の典型的なものは、そのネットワークプロトコルに
-予約されているポート番号とは異なるポートを指定しているものである。
-URL の内容には命令が含まれていて、
-そのプロトコルにしたがって解釈されたとき、
-予期されない動作を引起こすのである。
-例をあげると、 gopher の URL によって、意図しないメッセージや
-なりすましメッセージなどが SMTP サーバ経由で送信されるようなことがあった。
-.PP
-そのプロトコルのデフォルト以外のポート番号を指定している
-URL を用いるときには注意すべきである。
-特にその番号が予約空間の内部にある場合には。
-.PP
-URI に、そのプロトコルに対するデリミタがエスケープされたかたちで入っている
-場合も注意が必要である
-(例えば telnet プロトコルに対する CR 文字や LF 文字など)。
-なぜならこれらは転送前にエスケープが外されないからである。
-これはプロトコルに反しており、予期しない、おそらくは害になるような
-リモート動作を引起こす結果となりかねない。
-.PP
-秘密にしておくべきパスワードを含んだ URI を使うのが
-賢くないのは明らかである。特に、パスワードを URI の
-"userinfo" の部分に使うのは絶対に避けるべきである。
-ただしその "password" のパラメータを意図的に公開したい場合は別であるが。
+URI そのものはセキュリティの脅威を引き起こすものではない。 ある時点ではリソースの場所を与えていた URL が、
+ずっとそうでありつづけるという保証は一般にはない。 またある URL が、将来には別のリソースを示さないとも限らない。
+このような保証は、その名前空間とリソースとを管理している個人に 帰するものに過ぎない。
+.PP
+無害に見える操作 (リソースに関連づけられたエンティティの取得など) によって、実際にはリモートにダメージを与える動作を引き起こすような URL
+を記述することも場合によっては可能である。 危険な URL の典型的なものは、そのネットワークプロトコルに
+予約されているポート番号とは異なるポートを指定しているものである。 URL の内容には命令が含まれていて、 そのプロトコルにしたがって解釈されたとき、
+予期されない動作を引起こすのである。 例をあげると、 gopher の URL によって、意図しないメッセージや なりすましメッセージなどが SMTP
+サーバ経由で送信されるようなことがあった。
+.PP
+そのプロトコルのデフォルト以外のポート番号を指定している URL を用いるときには注意すべきである。 特にその番号が予約空間の内部にある場合には。
+.PP
+URI に、そのプロトコルに対するデリミタがエスケープされたかたちで入っている 場合も注意が必要である (例えば telnet プロトコルに対する CR
+文字や LF 文字など)。 なぜならこれらは転送前にエスケープが外されないからである。
+これはプロトコルに反しており、予期しない、おそらくは害になるような リモート動作を引起こす結果となりかねない。
+.PP
+秘密にしておくべきパスワードを含んだ URI を使うのが 賢くないのは明らかである。特に、パスワードを URI の "userinfo"
+の部分に使うのは絶対に避けるべきである。 ただしその "password" のパラメータを意図的に公開したい場合は別であるが。
.SH バグ
.PP
-文書は様々な場所に置かれうる。したがって現時点では、
-任意のフォーマットで書かれた一般のオンライン文書に対する良い URI スキームが
-存在しない。
+文書は様々な場所に置かれうる。したがって現時点では、 任意のフォーマットで書かれた一般のオンライン文書に対する良い URI スキームが 存在しない。
<file:///usr/doc/ZZZ> 形式の参照は使えない。なぜなら
-ディストリビューションやローカルへのインストールの際の条件によって、
-ファイルは異なるディレクトリに置かれることがあるからである
-(/usr/doc か /usr/local/doc か /usr/share かその他の場所か、などなど)。
-また、ディレクトリ ZZZ は通常バージョンが変わると異なったものになる
-(ファイル名のグロブによってある程度克服できるだろうが)。
-最後にもう一つ、文書をインターネットから (ローカルのファイルシステムに
-ファイルをロードするのではなく) 動的にロードする人々は、
-なかなか file: スキームを使ってくれない。
-将来には新たな URI スキーム (例えば "userdoc:" のような) が追加され、
-より詳しい文書へのクロスリファレンスが、
-その文書の正確な場所をプログラムが知らなくても可能になるかもしれない。
-あるいは、ファイルシステム規格の将来の版で
-ファイルの場所の指定をより厳密にして、
-file: スキームによる文書の位置指定が可能になるかもしれない。
-.PP
-プログラムやファイルフォーマットの多くでは、
-URI を使ったリンクを取り込んだり実装したりする方法がない。
-.PP
-プログラムの多くは、これらの URI フォーマットをすべては扱えない。
-ユーザの環境 (テキストかグラフィックか、
-デスクトップ環境、ローカルユーザの好み、
-現在実行されているツール) などを自動的に検知して、
-任意の URI をロードし、その URI に適したツールを起動するような
-標準的な仕組みがあるといいのだろうが。
-.\" .SH 著者
-.\" この man ページは David A. Wheeler (dwheeler@ida.dwheeler.com) が書いた。
+ディストリビューションやローカルへのインストールの際の条件によって、 ファイルは異なるディレクトリに置かれることがあるからである (/usr/doc か
+/usr/local/doc か /usr/share かその他の場所か、などなど)。 また、ディレクトリ ZZZ
+は通常バージョンが変わると異なったものになる (ファイル名のグロブによってある程度克服できるだろうが)。 最後にもう一つ、文書をインターネットから
+(ローカルのファイルシステムに ファイルをロードするのではなく) 動的にロードする人々は、 なかなか file: スキームを使ってくれない。
+将来には新たな URI スキーム (例えば "userdoc:" のような) が追加され、 より詳しい文書へのクロスリファレンスが、
+その文書の正確な場所をプログラムが知らなくても可能になるかもしれない。 あるいは、ファイルシステム規格の将来の版で
+ファイルの場所の指定をより厳密にして、 file: スキームによる文書の位置指定が可能になるかもしれない。
+.PP
+プログラムやファイルフォーマットの多くでは、 URI を使ったリンクを取り込んだり実装したりする方法がない。
+.PP
+.\" .SH AUTHOR
+.\" David A. Wheeler (dwheeler@dwheeler.com) wrote this man page.
+プログラムの多くは、これらの URI フォーマットをすべては扱えない。 ユーザの環境 (テキストかグラフィックか、
+デスクトップ環境、ローカルユーザの好み、 現在実行されているツール) などを自動的に検知して、 任意の URI をロードし、その URI
+に適したツールを起動するような 標準的な仕組みがあるといいのだろうが。
.SH 関連項目
-.BR lynx (1),
-.BR man2html (1),
-.BR mailaddr (7),
-.BR utf-8 (7),
+\fBlynx\fP(1), \fBman2html\fP(1), \fBmailaddr\fP(7), \fButf\-8\fP(7),
.UR http://www.ietf.org/rfc/rfc2255.txt
IETF RFC\ 2255
.UE
OSDN Git Service
