Provided by: manpages-ja_0.5.0.0.20060115-1_all bug

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.