Provided by:
manpages-ja_0.5.0.0.20060115-1_all 
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 のセクション
を見よ)。 古い文書では、 "URL:" という文字列を URI
の直前に挿入することを
勧めているものもあるが、しかしこの形式はまったく流行しなかった。
URI の書式は曖昧さを排除するように設計されている。 しかし URI が-
まるにつれ、昔ながらのメディア (TV、ラジオ、新聞、 看板などなど) は URI
参照を省略したかたち、すなわち
機関部とパス部だけでリソースを指定することが多くなっている (例:
<www.w3.org/Addressing>)。
このような参照はマシンというよりは人間向けのもので、 コンテ-
ストベースの推測によって URI の補完が可能であることを
あてにしているのである (例えば "www" ではじまるホスト名なら "http://"
がつくだろうし、 "ftp" ではじまるホスト名なら "ftp://" がつくだろう)。
多くのクライアントの実装では、この種の参照を推測によって解決する。
このような推測は時代とともに変わりうる。 特に新しいス-
ームが導入されるとそうである。 URI の省略形では相対 URL
パスの区別が付けられないので、 省略形 URI 参照は相対 URI の利用で-
るところでは使えない。 つまり定義済みのベース (ダイアログボックスなど)
がない場合に限って利用でい襦 文書内部でのハイパーテ-
ストリンクには省略形 URI を使ってはならない。
上述の標準フォーマットを使うこと。
意
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 の ただしその 'password'
のパラメータを意図的に公開したい場合は別であるが。
拠
IETF RFC 2396, HTML 4.0.
グ
文書は様々な場所に置かれうる。したがって現時点では、
任意のフォーマットで書かれた一般のオンライン文書に対する良い URI ス-
ームが 存在しない。 <file:///usr/doc/ZZZ>
形式の参照は使えない。なぜなら
ディストリビューションやローカルへのインストールの際の条件によって、
ファイルは異なるディレクトリに置かれることがあるからである (/usr/doc か
/usr/local/doc か /usr/share かその他の場所か、などなど)。
また、ディレクトリ ZZZ は通常バージョンが変わると異なったものになる
(ファイル名のグロブによってある程度克服でい襪世蹐Δ)。
最後にもう一つ、文書をインターネットから (ローカルのファイルシステムに
ファイルをロードするのではなく) 動的にロードする人々は、 なかなか file:
スァ璽爐鮖箸辰討れない。 祥茲砲録靴燭 URI スァ璽 (例えば "userdoc:"
のような) が追加され、 より詳しい文書へのクロスリファレンスが、
その文書の正確な場所をプログラムが知らなくても可能になるかもしれない。
あるいは、ファイルシステム規格の祥茲糧任
ファイルの場所の指定をより厳密にして、 file: ス-
ームによる文書の位置指定が可能になるかもしれない。
プログラムやファイルフォーマットの多くでは、 URI
を使ったリンクを取り込んだり実装したりする方法がない。
プログラムの多くは、これらの URI フォーマットをすべては扱えない。
ユーザの環 (テゥ好箸グラフィックか、 デスクトップ環-
、ローカルユーザの好み、 現在実行されているツール)
などを自動的に検知して、 任意の URI をロードし、その URI
に適したツールを起動するような 標準的な仕組みがあるといいのだろうが。
者
この man ページは David A. Wheeler (dwheeler@ida.dwheeler.com)
が書いた。
目
lynx(1), man2html(1), mailaddr(7), utf-8(7) IETF RFC 2255.