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