other versions
other languages
other sections
URI(7) | Linux Programmer's Manual | URI(7) |
名前¶
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
- hostport
- クエリーを行う LDAP サーバ。ホスト名を書く。続けてコロンとポート番号を 追加することもできる。 LDAP のデフォルトのポートは TCP ポート 389 である。 省略されると、どの LDAP サーバを用いるかはクライアントが決定する。
- dn
- LDAP の Distintuished Name (識別名)。 LDAP 検索の base オブジェクトを指定するものである (
- attributes
- コンマ区切りの、返される属性 (attribute) のリスト。 RFC 2251 の section 4.1.5 を見よ。省略されると全ての属性が返される。
- scope
- 検索のスコープを指定する。 "base" (base オブジェクト検索), "one" (1 レベル検索), "sub" (サブツリー検索) のいずれかを指定する。 省略すると "base" が仮定される。
- filter
- 検索フィルタ (返されるエントリのサブセット) を指定する。 省略されると、全てのエントリが返される。
- extensions
- コンマで区切られた type=value ペアのリスト。 ここで =value の部分は、それを要求しないオプションに対しては 省略できる。 '!' が前置された extension は critical (サポートしていなければならない) であり、 そうでなければ critical ではない (省略できる)。
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US郵便用の住所属性だけを取得する場合は、 次のようにリクエストする:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddresshost.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
文字エンコード¶
URI では、色々な状況下で入力できるように、文字の種類を制限している。 以下の文字は予約されている。すなわち、これらの文字は URI に登場することがあるが、それらの利用法 (解釈のされ方) は 予約された目的に制限されている (衝突するデータは URI にする前にエスケープしなければならない)。-
; / ? : @ & = + $ ,
-
- _ . ! ~ * ' ( )
- 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 を使ってはならない。 上述の標準フォーマットを使うこと。準拠¶
http://www.ietf.org/rfc/rfc2396.txt (IETF RFC 2396), http://www.w3.org/TR/REC-html40 (HTML 4.0).注意¶
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この文書について¶
この man ページは Linux man-pages プロジェクトのリリース 3.41 の一部 である。プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。2000-03-14 | Linux |