[60] [DFN[[[URL]]]] は、 [[Web]] において[[アドレス]]や[[識別子]]として用いられている[[文字列]]です。 * 仕様書 [63] [[URL]] は、 [[URL Standard]] により定義されています。 [REFS[ - [153] '''[CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) ''' -- [154] [CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) --- [156] [CITE@en[URL Standard]] ([TIME[2016-05-25 22:00:23 +09:00]]) - [31] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-12-03 22:48:19 +09:00]] 版) ]REFS] * URL の構成要素 [155] [[文字列]]表現を [DFN[[RUBYB[URL文字列]@en[URL string]]]] [SRC[>>156]]、 [[データ構造]]を [DFN[[RUBY[URL記録][URLレコード][URL record]]]] [SRC[>>154]]といい、 曖昧でなければどちらも共に [DFN[URL]] と呼びます。 ;; [157] [[仕様書]]の定義上、 [[URL文字列]]は、 [[URL]] としての構文に[[適合]]する[[文字列]]をいいます。 その他に、 [[URL構文解析器]]を通すと [[URL記録]]が得られるが [[URL文字列]]ではない[[文字列]]や、 [[URL構文解析器]]が[[失敗]]する[[文字列]]もあります。 ;; [158] すべての [[URL記録]]は、 [[URL直列化器]]により [[URL文字列]]に変換できます。 すべての [[URL文字列]は、適切な[[基底URL]]を選べば[[URL記録]]に変換できます。 ([[基底URL]]によっては[[失敗]]となることがあります。) [70] [[URL]] はいろいろな要素によって構成されています。 [FIG(list members)[ - [F[scheme][URL scheme]] - [[ASCII文字列]]。初期状態は[[空文字列]]。 - [[authority]] -- [[userinfo]] --- [F[利用者名][userinfo]] - [[ASCII文字列]]。初期状態は[[空文字列]]。 --- [F[合言葉][userinfo]] - [[ASCII文字列]]。初期状態は[[空文字列]]。 -- [CODE[location.host]] --- [F[ホスト]] - [[ホスト]]または [[null]]。初期状態は [[null]]。 --- [F[port]] - [[16ビット符号無し整数]]または [[null]]。初期状態は [[null]]。 - [F[パス][URL path]] - 0個[[以上]]の[[ASCII文字列]]の[[リスト]]。初期状態は空。 -- [[param]] - [F[query][URL query]] - [[ASCII文字列]]または [[null]]。初期状態は [[null]]。 - [F[素片][素片識別子]] - [[文字列]]または [[null]]。初期状態は [[null]]。 ]FIG] [26] [[URL記録]]は、次の状態を持ちます。 [FIG(list members)[ : [F[cannot-be-a-base-URL flag]] : [[boolean]]。初期状態は[[偽]]。 : [F[cannot have a username/password/port]] : : [F[起源][URLの起源]] : : [F[credentialsを含む]] : : [F[blog URL entry]] : [HISTORY[ : [F[オブジェクト][blob]] :[CODE(URI)@en[[[blob:]]]] [[URL]] が関連付けられた [CODE(DOMi)@en[[[Blob]]]] (あれば) です。初期状態は [[null]]。 ]HISTORY] ]FIG] ;; [159] [[URL記録]]は[F[オブジェクト]]を持つことができますが、 [[URL文字列]]はこれに相当するものを持ちません。 [F[オブジェクト]]は [[URL構文解析器]]によってその時点の [[blob URL store]] の状態に基づき設定されます。 ** URL scheme [137] [[URI]] の構造は、大きく [CODE(ABNF)[[[scheme]]]] (識別方式), [CODE(ABNF)[[[authority]]]] (命名権者), [CODE(ABNF)[[[path]]]] (経路), [CODE(ABNF)[[[query]]]] (照会), [CODE(ABNF)[[[fragment]]]] (素片識別子) の5つに分けられます。 このうち、 [CODE(ABNF)[scheme][URL scheme]] は [CODE(ABNF)[[[authority]]]], [CODE(ABNF)[path][URL path]], [CODE(ABNF)[query][URL query]] の詳細な構文と意味を決定します。 URI では様々な scheme が定義・利用されています。 それぞれの [[URI scheme]] はその構文と、 誰が識別子を作ることができるのか、 その識別子がどんな意味を持つのか、 色々な[[プロトコル]]や[[書式]]でどんな風に使うことができるのかなどを規定しています。 [138] このように [[URI scheme]] はそれぞれ独立した識別子の空間を作っています。 この独立性により、新しい[[資源]]の識別方法を URI に取り込むことが可能になっています。 ;; [139] 詳しくは [[URI scheme]] の項をご覧下さい。 ** 素片識別子 [140] URI の5大部品の一つが[[素片識別子]] ([CODE(ABNF)[[[fragment]]]]) です。素片識別子以外の URI が識別した[[資源]]の一部分・一表現を、 素片識別子は更に細かく識別します。 素片識別子は URI の一部ではないなどと呼ばれていた時代もありましたが、 現在では URI の一部分と考えられています。 ;; [141] 詳しくは[[素片識別子]]の項をご覧下さい。 * URL の分類 [61] [[URL]] には、単独で解釈できる[[絶対URL]]と、他の[[絶対URL]]を文脈として解釈される[[相対URL]]があります。 細かな構文要素が認められるか否かにより、更に細かく次のような分類が存在しています。 [FIG(short list)[ - [[絶対URL]] - [[相対URL]] - [[部分URL]] - [[単純参照]] - [[ASCII URL]] - [[ASCII絶対URL]] - [[ハッシュURL]] - [[妥当なURL]] - [[妥当な非空URL]] - [[妥当な間隔に囲まれているかもしれないURL]] - [[妥当な間隔に囲まれているかもしれない非空URL]] - [F[is special]] - [F[is local]] - [F[includes credentials]] ]FIG] [62] [[絶対URL]]には [[URL scheme]] が含まれており、その値によって [[[CODE(URI)@en[http:]] URL]]、 [[[CODE(URI)@en[mailto:]] URL]]、[[[CODE(URI)@en[ftp:]] URL]] などに分類されます。 ;; [[URL scheme]] も参照。 [32] [DFN[[RUBYB[妥当なURL]@en[valid URL]]]]とは、 [[URL]] のうち、 [[URL Standard]] の[[著者]]への要件に[[適合]]するものをいいます [SRC[>>31]]。 ** URL と URI、URN、IRI [199] 1990年代中頃、それまでの[[アドレス]]としての [[URL]] に加えて、 [[名前]]である [[URN]] が提案され、両者の総称が [DFN[URI]] とされました。 [[URN]] は [F[scheme][URL scheme]] が [CODE(URI)@en[urn][urn:]] の [[URI]] で、 [[URL]] はそれ以外の [[URI]] と決められました。 [200] 2000年前後の頃、 [[URI]] には [[URL]] としての性質が強い場合と [[URN]] としての性質が強い場合があり、一概にどちらであるとは言えないと考えられるようになりました。 例えば [CODE(URI)@en[http:]] [[URI]] は [[HTTP]] で[[アドレス]] ([[URL]]) としても使えるし、 [[XML名前空間]]で[[名前]] ([[URN]]) としても使えると解釈されました。 このため技術用語の [[URL]] は徐々に [[URI]] へと置き換えられていきました。 [202] 2000年代前半、 [[ASCII文字]]の [[URI]] に対して、 [[Unicode]] に拡張された [[IRI]] が開発されました。 [[IRI]] は [[URI]] を拡張した事実上の新バージョンでしたが、 形式的には別の名前で別の[[仕様書]]で定義される別の技術とされました。 それまでの [[URI]] は [[IRI]] に置き換えられていきましたが、 [[URI]] を使い続けるものや、 [[URI]] という呼称で実態が [[IRI]] のものもありました。 [203] 2000年代半ば頃、 [[HTML5]] は一部の専門家コミュニティー内でしか通用しない [[URI]] や [[IRI]] といった語を排除し、一般の開発者や市民に浸透した [[URL]] という呼称を復活させました。 2010年代に入ると、呼称だけでなく技術的にも実態に合っていない [[URI]] や [[IRI]] の[[仕様書]]にかわり、 [CITE[URL Standard]] が開発されました。 [204] こうした経緯から、 [[URL]] と [[URN]] の区別の議論や [[URI]] と [[IRI]] (やその他のバリエーション) の違いの説明は、 今となっては意味をなさないものです。 (事情が複雑で「公式」見解がころころ変わるので、1990年代から2000年代にかけて書かれた解説記事などは当時としても不正確なことが多いです。) ;; [201] 詳しくは、歴史の章を参照。 * URL に関する演算 [71] [[URL]] には色々な概念や演算が関係しています。 [FIG(short list)[ - [[URLの解決]] - [[基底URL]] - [[パーセント符号化]] - [[URLの比較]] - [[URLパターン]] - [[URL雛形]] - [[同文書参照]] - [[URLの起源]] ]FIG] ** 相対 URL と URL の解決 [142] URI ([[絶対URI参照]]) は [[URI scheme]] の名前から始まり、一つの[[資源]]を識別するべく説明を加えていきます。 例えば [SAMP(URI)[http://www.example.com/foo/bar/baz]] は特定の [SAMP[baz]] という[[資源]]を識別するために、 [SAMP(URI)[[[http]]:]] URI scheme を使うこと、 [[命名権者]]が [SAMP(URI)[www.example.com]] であること、 その中の [SAMP(URI)[foo]] の中の [SAMP(URI)[bar]] の中の [SAMP(URI)[baz]] が識別したい資源であることを順次説明しています。 しかし、このような説明は冗長なことがあります。 [SAMP(URI)[http://www.example.com/foo/bar/hoge]] が自分と同じ[Q[[[階層]]]]に存在する [SAMP[baz]] を指すためにわざわざ [SAMP(URI)[http:]] からはじめるのは面倒ですし、 不便なことも色々あります。 そこで、 URI の[DFN[[RUBYB[[[相対参照]]] [relative references]]]]という表現が規定されています。 例えば [SAMP(URI)[baz]] が相対参照です。 ただし、 [SAMP(URI)[baz]] だけでは URI (絶対 URI 参照) ではありません。 [SAMP(URI)[http://www.example.com/foo/bar/hoge]] という[Q[文脈]]の情報 ([DFN[[RUBYB[[[基底URI]]] [base URI]]]] と言います。) があって始めて [SAMP(URI)[http://www.example.com/foo/bar/baz]] という URI (絶対 URI 参照) に[DFN[[RUBYB[[[解決]]] [resolve]]]]されます。 ;; 参考: もし同じ相対参照 [SAMP(URI)[baz]] でも基底 URI が [SAMP(URI)[http://example.net/foo]] なら、 [SAMP(URI)[http://example.net/baz]] に解決されます。 ;; [143] 詳しくは[[相対参照]]の項をご覧下さい。 ** URL の一部分の直列化 [160] 次の通り、 [[URL記録]]の一部を取り出して[[直列化]]する操作が必要になることがあります。 [FIG(list)[ - [161] [F[ホスト][URL host]]、[F[ポート][URL port]] (= [F[ホストとポート]]) -- [[ホストとポート]]参照 - [167] [F[パス][URL path]]、[F[クエリー][URL query]] (= [F[pathquery]]) -- [168] [[HTTP]] [[要求対象]] - [174] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]]、 [F[パス][URL path]]、[F[クエリー][URL query]] -- [166] [[HTTP]] [[要求対象]] ([[プロキシ]]利用の場合) -- [175] [[Strip [VAR[url]] for use as a referrer]] - [165] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]]、 [F[パス][URL path]] -- [180] [[基底文字列URL]] - [176] [F[scheme][URL scheme]]、[F[ホスト][URL host]]、[F[ポート][URL port]] -- [177] [[Strip [VAR[url]] for use as a referrer]] - [169] [[URL分解属性]] ]FIG] ** URL の一部分の書き換え [170] 次の通り、 [[URL記録]]の一部を書き換える操作が必要になることがあります。 [FIG(list)[ - [171] [F[クエリー][URL query]]に関する操作 - [172] [[ハイパーリンクをたどる]]操作における[[ハイパーリンク接尾辞]] - [173] [[URL分解属性]] - [183] [[URL scheme]] の書き換え -- [184] [CODE(URI)@en[https:]] → [CODE(URI)@en[http:]], [CODE(URI)@en[http:]] → [CODE(URI)@en[ws:]] --- [CODE(JS)@en[new WebSocket]] ]FIG] ** URL の一部分の取り出し [181] [[URL記録]]の一部から情報を取り出す、次のような操作が使われることがあります。 [FIG(list)[ - [[path segment]] の[[リスト]] -- [[Webアプリケーション]]の[[ルーティング]] - [[URL query]] の [CODE(MIME)@en[application/x-www-form-urlencoded]] としての[[復号]] -- [[直列化]]された[[フォームデータ集合]]へのアクセス ]FIG] ** URL の組み立て [182] [[URL]] を組み立てるための次のような操作が使われることがあります。 [FIG(list)[ - [[URL scheme]]、[[authority]] と、追加の [[path segment]] のリスト → [[URL]] - [[URL]] の接頭辞 ([[URL scheme]]、[[authority]]、[[パス]]) と、 追加の [[path segment]] のリスト → [[URL]] - [[ハイパーリンク接尾辞]]の追加 -- [[サーバー側画像写像]] ]FIG] * API [24] [[DOM]] には次の [[API]] があります。 [FIG(short list)[ - [CODE(JS)@en[[[window.URL]]]] - [CODE(DOMi)@en[[[URLUtils]]]] - [CODE(DOMi)@en[[[Location]]]] - [CODE(DOMi)@en[[[document.URL]]]] ]FIG] [25] [[URL]] で指定された[[資源]]を取得する [[API]] は、 [[fetch]] を参照。 * 応用 [18] [[URL]] は様々な場面で使われています。 [FIG(short list)[ - [[HTTPにおけるURL]] - [[HTMLにおけるURL]] - [CODE[[[uniformResourceIdentifier]]]] - [[fetch]] - [[navigate]] - [[モジュール指定子]] - [[データベースのURL]] - [[VCSのURL]] - [[附属文書系URL]] - [[ファイルのURL]] - [[WebブラウザーのURL scheme]] - [[QRコードにおけるURL]] ]FIG] [186] [[URLの省略]]も参照。 [FIG(short list)[ [222] [[URL]] の性質 - [[潜在的に信頼できるURL]] - [[先験的認証済URL]] ]FIG] ** RSS における URL の利用 [5] [[RSS 2.0]] は [CODE(XMLe)@en[[[url]]]] [[要素]]、 [CODE(XMLe)@en[[[link]]]] [[要素]]、[CODE(XMLa)@en[[[url]]]] [[属性]]、 [CODE(XMLe)@en[[[docs]]]] [[要素]]、[CDE(XMLe)@en[[[comments]]]] [[要素]]、 [CODE(XMLe)@en[[[guid]]]] [[要素]]で [[URL]] を値として使っています。ただし、「[[URL]]」の定義は明記されておらず、 どの仕様も引用されていません。 ;; [[RSS Best Practices Profile]] は [[IRI]] を禁じるにあたって [[RFC 3987]] を引用しているので、それを類推すれば [[RFC 3986]] に従うのかもしれませんが、 [[RFC 3986]] なら [[URL]] ではなく [[URI]] のはずです。 [6] このうち、なぜか [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と [CODE(XMLe)@en[[[link]]]] [[要素]]については [[URL scheme]] に関する制限があります。 仕様書: -[CITE@en[RSS 2.0 Specification (version 2.0.10)]] ([TIME[2008-11-21 18:10:17 +09:00]] 版) -[CITE@en[RSS Best Practices Profile]] ([TIME[2008-11-21 15:11:45 +09:00]] 版) *** 妥当性 [10] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と [CODE(XMLe)@en[[[link]]]] [[要素]]の[[内容]]は妥当な [[URL]] でなければ[['''なりません''']] [SRC@en[[[RSS Best Practices Profile]]]]。 ;; [[IRI]] は使えません [SRC@en[[[RSS Best Practices Profile]]]]。 [7] [[RSS 2.0]] 仕様書や [[RSS Best Practices Profile]] は、「最初の非[[空白]][[文字]]には制限があります」といっています。 つまり、明記されていませんが、 [[URL]] の前に[[空白]]を挿入してもかまわないようです。 [8] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と [CODE(XMLe)@en[[[link]]]] [[要素]]の [[URL]] の [[URL scheme]] は、 [[IANA]] 登録簿に登録されているものでなければ[['''なりません''']] [SRC@en[[[RSS 2.0]], [[RSS Best Practices Profile]]]]。 [9] [CODE(XMLe)@en[[[url]]]] ''[[要素]]''と [CODE(XMLe)@en[[[link]]]] [[要素]]の [[URL]] は[[相対URL]] であっては[['''なりません''']] [SRC@en[[[RSS Best Practices Profile]]]]。 ** 識別子としての利用 [16] 次の場面では [[URL]] が[[アドレス]]としてではなく、 [DFN[[[識別子]]として][識別子としてのURL]]使われています。 [FIG(short list)[ - [[DSig]] - [[名前空間名]] - [[拡張宣言]] - [CODE(XPointerScheme)@en[[[xmlns()]]]] - [CODE(HTTP)@en[DAV:]] [[ヘッダー][HTTPヘッダー]] - [CODE(HTMLa)@en[itemtype]] [[属性][内容属性]] - [[RDF]] [[資源]] - [[WebDAV特性]] - [[状態トークン]] - [[リンク関係型]] - [[HTMLメタ情報プロファイル]] - [[[CODE[profile]] (MIME)]] - [CODE[rel=type]] - [[XML署名]] - [[XML暗号化]] - [CODE(HTTP)@en[SOAPAction:]] [[ヘッダー][HTTPヘッダー]] - [[アクセストークン型]] - [[承諾型]] - [[BEEPプロファイル]] - [[SPDX Document URI]] - [[OAuth scope]] ([[サーバー][OAuthサーバー]]によっては。) ]FIG] [17] 次の場面では [[URL]] が[[アドレス]]としての側面と識別子としての側面の両方を持っています。 [FIG(short list)[ - [[OpenID]] - [CODE[guid]] ]FIG] [216] 元来[[プロトコル]]と結びつかない [[URL]] (例えば [CODE[urn:]] [[URL scheme]] の [[URN]]) がこうした場面で使われることもありますが、 そうでない [[URL]] (例えば [CODE[http:]] [[URL]]) もよく使われています。 後者が用いられる場合は、 [[URL]] の本来の意味 (例えば [CODE[http:]] の場合 [[HTTP]] でアクセスできる[[資源]]という意味) が失われている場合が多いです。 [EG[ [215] [[RDF]] では [CODE[http:]] [[URL]] であっても任意のもの、 例えば現実の[[人]]なども表せるということになっています。 ]EG] [20] [[Semantic Web]] 界では [CODE(URI)@en[[[http:]]]] [[URL]] を[[識別子]]として使っているため、 [[HTTP]] から [[HTTPS]] への移行が難しいという人もいます [SRC[>>19]]。 [[マイクロデータ]]界では実際に [[HTTPS]] 化時に[[識別子]]である [[URL]] を [CODE(URI)@en[[[https:]]]] [[URL]] に書き換えようとした例 [SRC[>>21]] もあり、 [[URL]] を[[識別子]]として用いることの問題が浮き彫りになっています。 元来[[プロトコル]]の[[アドレス]]だったものを、 [[不透明な識別子]]に目的外利用してしまったがために、 認知と理論に齟齬が生じてしまっているのです。 [220] 長くて面倒なので、[[URLの省略]]の仕組みが導入されていることがあります。 [221] [[URL]] を識別子として使うという行為の[[バッドノウハウ]]感が否めないですが、 他によい代案がないこともあります。 -*-*- [214] これらの場面のほとんどでは、[[URLの単純文字列比較]]が用いられています。 [FIG(quote)[ [FIGCAPTION[ [27] [CITE@en[Webmention]] ([TIME[2017-01-11 04:06:01 +09:00]]) ]FIGCAPTION] > If your implementation wants to treat the source and target parameters as URIs, you can prefix the terms with http://www.w3.org/ns/webmention#. ]FIG] [28] >>27 の [CODE[source]] と [CODE[target]] は [CODE[application/x-www-form-urlencoded]] のキーなんだけど、この[[URL]]は何の役に立つんですかね・・・? [REFS[ - [11] [CITE@EN[The Self-Describing Web]] ([TIME[2009-01-16 04:14:18 +09:00]] 版) - [19] [CITE@en[Re: '''['''MIX''']''' Require HTTPS scripts to be able to anything HTTP scripts can do.]] ([[Tim Berners-Lee]] 著, [TIME[2015-02-26 01:03:52 +09:00]] 版) - [21] [CITE@en[Bug 27388 – Use https://schema.org/ in examples if feasible]] ([TIME[2015-02-26 11:44:03 +09:00]] 版) ]REFS] ** URL とプログラミング言語 [118] [[プログラム言語]][[E]]では[[URI]]が言語の構文に組み込まれている。 [CITE[URI Expressions]] [119] 他に[[URI]]を積極的に[[言語]]そのものに取り入れた[[プログラム言語]]といえば[[WMLScript]]がある。 ** URL の前後の区切り文字 [SEE[ [[URLの表示]], [[URLの印刷]], [[URLの省略]], [[URL自動リンク]] ]] *** URL に含められる文字を区切り文字として使う文脈 [13] [[HTTPヘッダー]]である [CODE(HTTP)@en[[[OPES-System:]]]] や [CODE(HTTP)@en[[[OPES-Via:]]]] では、区切り文字として [CODE(HTTP)[[[,]]]] や [CODE(HTTP)[[[;]]]] を使っています。 [CODE(HTTP)@en[[[OPES-Bypass:]]]] では区切り文字として [CODE(HTTP)[[[,]]]] を使っています。 いずれも構文解析方法は決められていません。 [14] [[HTML]] の [CODE(HTMLa)@en[[[srcset]]]] [[属性]]では [CODE(HTTP)[[[,]]]] が[[区切り文字]]として使われています。構文解析方法も明確に規定されています。 [240] [CITE@en[[[RFC 4508]]: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method]], [TIME[2023-07-03T07:17:51.000Z]], [TIME[2023-07-03T07:21:00.442Z]] [241] >>240 [[SIP]] [CODE[Refer-To]] では [[URI]] に[[引数][URL param]]が含まれる時 [CODE[<]] [VAR[...]] [CODE[>]] で括らなければならず、 そうでない場合は[[ヘッダー]]の方の[[引数]]とみなすと定められています。 [231] [[nginx]] の設定ファイルでは [PRE[ return 302 https://example.com/path; ]PRE] のように [[URL]] を記述することになっており、 [[URL]] の後に設定ファイルとしての[[文]]末を表す [CH[;]] が出現します。 (なお厳密にはこれは [[URL]] ではなく [CODE[$1]] や [CODE[$foo]] のような[[変数]]を使って [[URL]] を指定できる[[雛形][URL雛形]]です。) ** scheme のない URL [SEE[ [[URLの省略]] ]] ** URL を組み込んだ構文 - [CODE[url-or-path]] [233] 関連: [[ange-ftp address]] * 壊れたURL [SEE[ [[URLの省略]], [[URLの表示]] ]] ** URL に使えない文字 [238] [[LBRY]] * URL 設計 [191] [[URL]] は、 [[URL scheme]] によって残りの部分の構文と意味が決まります。 残りの部分を誰がどのように決めるかも、 [[URL scheme]] に依存します。 ただし、[[相対URL]]を使う [[URL scheme]] は、ある程度の共通制約があります。 ;; 具体的には[[相対URL]]、[[絶対URL]]、各 [[URL scheme]] の項を参照。 [193] [[x-callback-url]] のような複数の [[URL scheme]] の共通仕様もあります。 [192] [[URL]] の[F[素片識別子]]は、原則として [[URL scheme]] や [[URL]] のその他の部分と独立しており、 [[URL]] を使った取得操作の結果得られるデータの形式に依存して構文と意味が決まります。 (一部の [[URL scheme]] では、 [[URL scheme]] が[[素片識別子]]にも干渉しています。) ;; [[素片識別子]]参照。 [102] [[URL]] 一般の設計論については、[[URLの決め方]]を参照。 -*-*- [164] 特定目的で [[URL]] に別名を与えようとする試みとして、 [[URN]]、 [[PURL]]、 [[短縮URL]] といったものがありました。いずれも一時的に一定の賛同を得たものの、 それぞれの課題があって成功とはいえない状況です。 * URL の表示 [185] [[URLのレンダリング]]、[[アドレスバー]]を参照。 * URL の印刷 [SEE[ [[URLの印刷]] ]] * URL の利用者親和性 [FIG(quote)[ [162] [TIME[2005-11-10 08:39:02 +00:00]] > [TALK[ [[Martin]] URI は元々人間が見るものじゃなかったんすよ。 ]TALK] [TALK[ [[RoyF]] んな阿呆な。 ]TALK] [TALK[ [[Martin]] いやね、 [[TimBL]] の旦那がそう言っとりましたよ。 1990年とかそこらの話だと思いやすけど。 ]TALK] ]FIG] [163] 確かにそんなこと Tim が言ってたのを [[www-talk]] かどこかで見た記憶がある。 * 自由文内の URL の抽出 [29] [[URLの自動リンク]]参照。 * セキュリティー [209] [[URL]] が表示されることが[[セキュリティー]]上重要とされる場合があります。 ;; [[アドレスバー]]参照。 [210] ある程度の専門的知識を有する人は、 [[URL]] からその内容を推測し安全かどうかの判断基準として使うことがあります。 確実ではありませんが、ないよりは有用程度のヒントにはなります。 [EG[ [211] 例えば[[ハイパーリンク]]の[[リンク先]]の [[URL]] の[[ドメイン]]が既知の[[Webサイト]]かどうかで、その[[リンク]]が安全かどうかを推測したりできます。 そのような判断をする人にとっては、[[Webブラウザー]]に[[リンク先]]の [[URL]] の表示機能が備わっていることは重要です。 ]EG] [237] [[URL安全]] ** URL 内の秘密情報 [146] [[URL]] には、漏洩するべきでない情報が含まれることがあります。 そのような[[URLの決め方]]は好ましくありませんが、 現に存在しますし、避けられないこともあります。 [EG[ [147] [[クッキー]]に対応していない古い[[Webブラウザー]]のために、 [[セッションID]]を [[URL]] に付けていた時代もありました。 そのような [[URL]] の漏洩は深刻な[[セキュリティー]]問題でした。 ]EG] [EG[ [149] [[ブログ]]の記事の題名から自動的に [[URL]] が決められる場合、 その[[ブログ]]が非公開で閲覧に[[認証]]が必要であっても、 [[URL]] が漏れると題名が流出してしまうことになりますから、 取り扱いに注意が必要です。 ]EG] [EG[ [150] 特定の[[利用者]]にのみ発行される [[URL]] があり、 その[[文書]]に他の [[Webサイト]]への[[リンク]]が含まれる場合で、 [[URL]] が[[リファラー]]としてその [[Webサイト]]に送信されてしまう場合、 誰がアクセスしてきたかを他の [[Webサイト]]の側が特定できてしまうかもしれません。 場合によっては[[プライバシー]]保護の観点から問題となるかもしれません。 ]EG] [112] [[認証鍵付きURL]]や [[capability URL]] などと称して、 [[bearer]] を [[URL]] に付加することがよくあります。 簡易的な[[認証]]機能としたり、[[利用者]]の確認のために[[電子メール]]で [[URL]] を送信する際に用いたりします。 [EG[ [148] [[無作為]]に決められた十分長い秘密の [[URL]] によって[[認証]]を行ったり、 特定[[利用者]]向けの情報を公開したりすることがあります。 ]EG] [151] [[URL]] の [[userinfo]] 部分は、元々[[利用者名]]と[[合言葉]]を記述する欄として用意されました。 現在では好ましくないと考えられています。しかし利便性が高いため、 しばしば用いられます。 [EG[ [113] [[プロキシを指定する環境変数]]では、[[プロキシ]]の [[URL]] を指定しますが、 [[userinfo]] に[[プロキシ認証]]のための情報を含めることがあります。 ]EG] [EG[ [114] [[Webアプリケーション]]から [[Webアプリケーション]]への [[Web Hooks]] の設定画面では、 [[URL]] を指定する欄が1つだけ用意されていて、 そこに記述する [CODE(URI)@en[https:]] [[URL]] の [[userinfo]] に[[基本認証]]の[[利用者名]]と[[合言葉]]も含められることがあります。 ]EG] ** 構成する文字に関わる問題 [217] [[文字のセキュリティー]]、[[URLにおける文字]]も参照。 * 知的財産権 ** 著作権 [103] あまり意識されることはありませんが、 URI である文字列に対して[[著作権]]が主張される可能性があります。 単に[[資源]]の位置を表すに過ぎない [[URL]] 的な URI の類が[[著作物]]足る要件を満たすとは考えにくいですが、 ほとんどあらゆる種類のものが URI として表現し得ます。 特に、 [FIG(list)[ - [CODE(URI)[[[data]]:]] URI scheme を使った任意のデータを含む URI - [CODE(URI)[[[javascript]]:]] URI scheme を使った任意の [[JavaScript]] 符号を含む URI - [CODE(HTMLa)[[[method]]]] が [CODE(HTML)[get]] な [[HTML]] の[[フォーム]]を[[提出]]した結果得られる URI ]FIG] ... のようなものは、著作物が URI の一部として入り込む可能性が高いといえます。 任意のデータが [CODE(URI)[data:]] URI にした途端著作権が消滅するのはおかしいですから、 著作物たる [CODE(URI)[data:]] URI が存在することは間違いありません。 また、 [[Bookmarklet]] などは創作性が高いと考えられますから、 簡単なものを除いて著作物だとの主張が認められる可能性が高いと思われます。 ;; [104] もちろん、[[百分率符号化]]などの仔細な表現上の違いは著作権が存在するかどうかの議論とは無関係です。 [105] URI が著作物足り得るかどうかの議論は、 [[ハイパーテキストにおけるリンクの自由性]]にも関わってきます。 [106] URI に著作権は及ばないという主張の例: [FIG(list)[ - [108] [CITE[壇弁護士の事務室: ちょっと、変更]] - [109] [CITE[@はんのう]] - [127] [CITE[yoosee.net : copyright & disclaimer]] - [128] [CITE[リンクと著作権のメモ]] - [129] [CITE[著作権および免責事項]] - [130] [CITE[無題ドキュメント]] - [134] [CITE[Webページの作法]] - [135] [CITE[」」」 Kiss The Moon 」」」]] ]FIG] [107] URI に著作権が及ぶという主張の例: [FIG(list)[ - [132] [CITE[Copyright and So on.]] -- この文書の著者が命名権者らしい [CODE(URI)[[[http]]:]] URI の著作権を主張しています。 ]FIG] [110] [CITE[葉っぱ日記 - ぼくはまちちゃん!(Hatena) - urlのポエム化]] ([CODE[2007-01-17 09:25:44 +09:00]] 版) ([[名無しさん]] [WEAK[2007-01-17 00:28:09 +00:00]]) ** 商標権 [111] [[URI]] として使用する文字列の一部が[[商標]]としてみなされることがあります。 特に URI に一部としてよく使われる[[ドメイン名]]は頻繁に商標に関する係争が発生しています。 ドメイン名に限らず、商標を根拠に商標権者が URI の使用者に使用しないように主張する可能性があります。 * テストデータ [120] [CITE[UriTesting - ESW Wiki]] [2004] [CITE[UriTesting - W3C Wiki]] ( ([TIME[2011-01-28 18:05:41 +09:00]] 版)) [121] [CITE[Index of /uri]] ([CODE[2007-01-05 15:38:16 +09:00]] 版) ([[名無しさん]] [WEAK[2007-01-05 06:39:54 +00:00]]) * 歴史 [64] [[URL]] ははじめ [[TimBL]] によって [[World Wide Web]] を構成する技術の一つとして提案されました。 この当時の仕様書は [[W3O]] の [[Webサイト]]や [[www-talk]] [[メーリングリスト]]などで配布されていました。 [228] [CITE[Document identifiers]], [TIME[2003-08-04T15:50:19.000Z]], [TIME[2024-09-29T08:14:41.317Z]] [227] [CITE[Draft: Universal Document Identifiers]], [TIME[2003-08-04T15:50:19.000Z]], [TIME[2024-09-29T07:48:12.037Z]] [226] [CITE[URLs - new document; URL mail server]], [TIME[2003-08-04T15:50:22.000Z]], [TIME[2024-09-29T07:36:18.144Z]] [229] [CITE[MIME, SGML, UDIs, HTML and W3]], [TIME[2003-08-04T15:50:20.000Z]], [TIME[2024-09-29T13:49:31.504Z]] [230] [CITE[IETF BOF on Universal Document Identifiers]], [TIME[2003-08-04T15:50:20.000Z]], [TIME[2024-09-29T13:58:16.331Z]] [65] その後は [[IETF]] によって標準化が行われました。 [66] [[URL]] 本体仕様として、次のものが発行されています。 [FIG(list)[ - [[RFC 1630]] - [[RFC 1738]] - [[RFC 1808]] ([[相対URL]]) - [[RFC 2396]] - [[RFC 2732]] ([[IPv6アドレス]]) - [[RFC 3986]] - [[RFC 3987]] ([[IRI]]) - [[RFC 6874]] ([[ゾーン識別子]]) ]FIG] [212] しかしこれら「正式」な仕様書ではカバーしきれていない現実の問題が多く存在しており、 [[W3C]] は [[IRI]] の様々なバリエーションを規定しましたし、 [[Webブラウザー]]はそのいずれとも違うものを実装していました。 ;; [67] この期間の歴史は本項の他に [[URN]]、[[IRI]] の項も参照してください。 [68] 00年代に [[WHATWG]] で改めて [[URL]] を定義する動きがあり、紆余曲折を経て2012年、 [[Anne van Kesteren]] により [[URL Standard]] が作られました。 ;; [69] この期間の歴史は、 [CITE[URL Standard]] の歴史の項も参照してください。 ** 呼称 [15] [[URL]] の一部または全部を指して、歴史的に様々な呼称が用いられてきました。 [FIG(short list)[ - [[URL]] - [[URI]] - [[IRI]] - [[Web addresses]] - [[HRef]] - [[LEIRI]] - [[XMLRI]] - [[HRRI]] - [[URN]] - [[UDI]] - [[URI参照]] - [[IRI参照]] - [[RDF URI参照]] - [[DOM URI]] - [[完全URI]] - [[絶対URI]] - [[絶対IRI]] - [[絶対URI参照]] - [CODE(ABNF)@en[[[generic-RL]]]] - [[部分URI]] - [[相対参照]] - [[相対IRI参照]] ]FIG] [88] [[IETF]] は [[RFC]] を改版する度に用語やその定義を少しずつ変えていました。 更に、実際に普及した用語や [[DOM]] 等の [[API]] で使われている用語とも一致していませんでした。 そのため、色々な[[仕様書]]や実装で似たような異なるような概念が交錯し、 大混乱していました。 [89] 加えて [[W3C]] は、 [[XML]] 関連仕様を新たに出版する度に、 新しい「URI のようなもの」を定義していました。その定義も少しずつ異なるものでした。 ;; 詳細は [[IRI]] も参照。 [42] URI 関係の古い定義: - [[逃避]], [[escape]], [[URI符号化]] → [[百分率符号化]] - [[素片識別子]]は [[URI]] の一部ではない → [[素片識別子]]も [[URI]] の一部分 - [CODE(ABNF)[[[scheme]]]] の後が [CODE(URI)[//]] の URI でしか[[相対URI]] は使えない → どんな URI でも[[相対参照]]は使える [82] [CITE[fragment identifiers from Roy T. Fielding on 2002-07-23 (www-tag@w3.org from July 2002)]] [83] URI の標準化はかなりいい加減で混乱気味の上に W3C/Martin Durest は [[IRI]] を進めていて、それも [[SP]] を認めるとか [CODE[#]] もどうとか無茶苦茶なこと言ってたし、混乱は当分収まりそうにない。 [84] RFC 2396 は、絶対 URI だけを URI としており、相対 URI や素片識別子がついた URI も含めた名称を URI 参照としています。 (旧版の RFC 1808 も含めて) 旧来の仕様や慣習では絶対 URI と相対 URI の両方を URI と言っていましたし、素片識別子も仕様書には URI の一部ではないと書いてあるけど実際には曖昧に使われていた [WEAK[(古い URI 仕様書まで遡るとこちらも曖昧だった)]] という歴史的経緯がありまして、単に URI とだけ言われると厳密には何を指しているのだかわかったものではありません。[WEAK[たまに論争の火種になります(w]] [85] XML 関連仕様書は URI という名前で IRI を指していたり、「URI と解釈されるもの」というわけのわからんのがでてきたりしますから混迷極まり ([CODE(WikiPage)[[[XML//URI]]]] 参照)。 [86] あと目立たないけど注意しておきたいのは、空文字列。 RFC 2396 的には URI 参照の一種ですが URI じゃないですし、相対 URI でもないかもしれません。 RFC 1808 から意味が変更されたものですから解釈は実装依存になってしまう。その上使えるかどうかは採用する規格に依存。 (URI 参照を使うと書かれている規格でも、よく見ると字数制限1文字以上で使えなかったりする。) [87] 2396bis ではまた変わるみたいです。。。 ** 拡張 [205] 歴史的にいくつも [[URL]] の拡張が提案されていますが、広く採用されたものはありません。 [FIG(short list)[ [206] [[URL]] の拡張の提案 - [[XURL]] - [[XRI]] - [[IRI]] - [[LEIRI]] ]FIG] ** URI [36] [[URI]] ([DFN[Uniform Resource Identifiers]], [DFN[統一資源識別子]]) は、[[資源]]を[[識別]]するための統一的な仕組みとして提案されていました。 簡単に言えば、色々な[Q[もの]]に名前を付けるための仕組みでした。 あるいは、その仕組みによる識別子をも URI と呼んでいました。 また、文脈で意味が曖昧でない場合には、識別子によって参照される資源のことすらも URI と呼ぶことがありました。 [37] 従来の情報システム・計算機システムは、 それぞれで資源を識別する仕組みや[[番地付け]]の仕組みを持っていました。 しかし、それらはあくまでそれぞれのシステムの範囲内でのみ有効な識別子システムでした。 ところが、1990年頃 [[TimBL]] が発明した [[WWW]] では、番地付けのために URI を採用しました。 URI は [[URI scheme]] によって命名システムを識別し、 URI scheme ごとにその中で更に具体的な資源を識別するという構造を持っています。 そのため、従来の情報システムの識別子を URI scheme として再定義することによってあらゆる資源を[Q[統一]]的に扱うことに成功したのです。 参考: そのような設計が採用された背景には、 当時様々な情報システムが提案されて割拠していたことがあります。 WWW は [[HTTP]] だけではなく、それら他のシステムも URI によって[Q[取り込む]]ことで魅力的な情報システムになったのです。 [38] URI で識別される[Q[資源]]は、何も計算機で表現できるものに限りません。 [CODE(URI)[[[urn:isbn:]]]] [[URI]] を使えば [[ISBN]] によって[[書籍]]を識別することができます。 物理的に存在するもの以外でも、 言葉や抽象概念などありとあらゆる[Q[資源]]を識別することが可能です。 [39] URI が元々 [[HTTP]] と [[HTML]] で[[番地付け]]のために使われてきたことから、 単にネットワーク資源の位置を表す[[住所]]のようなものと考えられることがよくあります。 しかし、 >>38 のように URI はネットワークで[Q[[[取出す]]]]ことができないものであっても[Q[識別]]できます。 [[Webブラウザ]]で画面に表示することはできないかもしれませんが、 それだけが URI の役割ではないのです。 [223] [CITE@en[Univeral Resource Identifiers -- Axioms of Web architecture]], [TIME[2009-08-27T21:38:06.000Z]], [TIME[2021-04-12T12:07:39.763Z]] *** URI の定義 [2000] 「[[URI]]」という言葉の定義は、[[URI]] を定義する仕様自体でも歴史的に変化していますし、 [[URI]] を参照する様々な仕様でも様々な意味に用いられています。 仕様内でもそうなのですから、それ以外の世界ではその意味は全く安定していないといっても過言ではありません。 [2001] 最も大きな定義上の混乱の1つは、 [[URI]] と [[URI参照]]の違いです。 最新の [[URI]] の定義である [[RFC 3986]] によると、[[相対参照]]は [[URI参照]]ですが、 [[URI]] ではありません。その前の [[RFC 2396]] の定義によると、[[素片識別子]]を含んだものは [[URI参照]]ですが、[[URI]] ではありませんでした。 仕様書以外の場面 (や多くの関連仕様!) では、「[[URI]]」というと [[URI参照]]を指すことが多くあります。 これらについては [[URI参照]]や[[素片識別子]]の項をごらんください。 [2002] もう1つの最大の混乱は、利用可能な[[文字]]の種類に関するものです。 [[URI]] で本来認められない [[ASCII文字]]や、[[IRI]] では認められる[[非ASCII文字]]の扱いをめぐって、 多くの仕様がいろいろなものを「[[URI]]」と呼んでいます。 詳しくは [[IRI]] の項をご覧ください。 [2003] 前述の2つに比べれば細かい話ですが、 [[URI]] の構文や[[相対参照]]の[[解決]]の方法は新しい仕様書が発行される度に変化しています。 特に最新の [[RFC 3986]] とその1つ前の [[RFC 2732]] あるいは [[RFC 2396]] との関係は、 どちらがどちらの[[部分集合]]でも[[超集合]]でもありません。 [[URI]] を用いる色々な仕様がそれぞれ異なる版の [[URI]] を参照しており、 通常そのような仕様が多数組み合わせて用いられるので、 厳密に解釈すると [[URI]] の扱いは非常にややこしいことになります。 *** IETF における URI の標準化 - [78] ''IETF - Uniform Resource Identifiers (URI) Working Group'' (終了) - [79] ''IETF - Uniform Resource Identifiers (URI) Working Group'' - [80] ''Web Naming and Addressing Overview (URIs, URLs, ...)'' [81] [CITE[URI.NET]] ちょっと古いしちゃんと管理されていないみたい。 ([[名無しさん]] [WEAK[2005-03-11 03:40:22 +00:00]]) ** 既存の識別子との関係 [125] [[URI]] は [[URI]] を意識せずに作られた[[識別子]]体系でもそのまま取り込んでしまうことができます [WEAK[(もちろん相性のようなものはありますが)]]。 既に色々な[[識別子]]を [[URI]] として使う方法が定義されています。 [126] 色々な[[識別子]]の体系を [[URI]] 1つにまとめると、 何かしたいときに各[[識別子]]体系それぞれに対してその方法を考える必要がなくなります。 例えば引用文献を記述する時に、引用する文献が [[Web頁]] ([[URI]]) でも紙の書籍 ([[ISBN]]) でも両方 [[URI]] として扱えると便利になることがあります。 あるいは連絡先が[[インターネット]]の[[電子メイル]] ([[電子メイル・アドレス]]) でも従来の[[電話]] ([[電話番号]]) でも統一して扱えたりもします。 [131] 既存の識別子と URI の対応 ,既存の識別子体系 ,URI ,備考 ,出版物 ,== ,== ,[[ISBN]] ,[CODE(URI)@en[[[urn:isbn]]:]] ,[[ISSN]] ,[CODE(URI)@en[[[urn:issn]]:]] ,[[公開識別子]] ,[CODE(URI)@en[[[urn:publicid]]:]] ,[[RFC]] ,[CODE(URI)@en[[[urn:ietf:rfc]]:]] ,ネットワーク番地 ,== ,== ,[[電話番号]] ,[CODE(URI)@en[[[tel]]:]] ,[[FTP]] ,[CODE(URI)@en[[[ftp]]:]] ,[[インターネット]]の[[電子メイル]] ,[CODE(URI)@en[[[mailto]]:]] ,[[ニュース組]] ,[CODE(URI)@en[[[news]]:]] ,[[チャット]]の[[チャンネル]] ,[CODE(URI)@en[[[irc]]:]] ,言語・文化 ,== ,== ,[[言語札]] ,[CODE(URI)@en[[[urn:x-suika-fam-cx:lang]]:]] ,その他 ,== ,== ,[[UUID]] ,[CODE(URI)@en[[[urn:uuid]]:]] ** RFC 1630 (第1世代) [46] - [[RFC1630]] 『Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web (WWW における普遍資源識別子 : World Wide Web で使われているネットワーク上の物体の 名前と番地の表現の統一構文)』, -- T. Berners-Lee, 1994 年6月, Informational RFC。 -- この文書は、 WWW でインターネット上の物体の名前と番地を符号化するのに使われている構文を定義します。 Web は、既存のプロトコル, web 自体のために新しく開発されたプロトコル, 将来発明されるプロトコルを含めた拡張可能な数のプロトコルを使って接続可能な物体を含むと考えられます。 特定のプロトコルによる個々の物体への接続指示は、 番地文字列の形式に符号化されます。 他のプロトコルは種々の形式の物体名の使用を認めています。 一般物体の抽象的考えのために、 web は物体の普遍的集合の概念及び物体の名前及び番地の普遍的概念を必要としているのです。 [33] - 『A Framework for Identifying, Locating, and Describing Networked Information Resources (ネットワーク情報資源の識別, 位置付け, 記述の枠組み)』 -- -- Clifford Lynch, 1993年3月。 -- インターネット上のネットワーク情報資源の増加につれ、 この資源の体系的で標準的な識別・位置付け・記述手段が益々必要となっています。 そのような方式の開発の動機は様々ですが、 開発を進めるに当たって少なくても3つの大きな応用があります。 1つには、図書館界では伝統的な型録記述をネットワーク資源に拡張する必要があります。 本質的には、 (in the sense that libraries are shifting from collections to access, and increasingly view their catalogs and other databases as bibliographies of materials to which they are prepared to provide, and perhaps subsidize, access) 書誌記述及び統一的に図書館蔵書と協調させるためのネットワーク情報資源の管理を可能とし、 これらへの接続を向上させる必要があります。 As networked information resources become critical to scholarship and research, and come to represent significant investments by institutions, it also becomes essential to apply the practices of information management to this new class of resources. ** RFC 1738 (第2世代) [34] - [[RFC1736]] -- 『Functional Recommendations for Internet Resource Locators (インターネット資源位置子の機能的要件)』 -- J. Kunze, 1995年2月。 Informational RFC。 -- この文書は、位置と資源の接続情報を伝達するインターネット資源位置子の要件の最小集合を規定します。 資源の典型的な例には、ネットワークで接続可能な文書, WAIS データベース, FTP サーバー, Telnet 終点を含みます。 [35] - [[RFC1737]] -- 『Functional Requirements for Uniform Resource Names (統一資源名の機能的要件)』 -- K. Sollins, L. Masinter, 1994年12月。 Informational RFC。 -- この文書は、統一資源名 (URN) として知られるある種のインターネット資源識別子の要件の最小集合を規定します。 URN は、統一資源特性 (URC), 統一資源位置子 (URL) を加えて構成される上位のインターネット情報体系内に fit します。 URN は識別に使用され、 URC はめた情報を含めるのに使用され、 URL は資源の位置付けや探索に用いられます。 この文書は URN の規格を評価する基礎として提供します。 議論はメイリング・リスト 及び IETF の URI 作業部会の部で行われます。 [40] - [[RFC1738]] -- 『Uniform Resource Locators (URL) (統一資源位置子 URL)』 -- T. Berners-Lee, L. Masinter, M. McCahill, 1994年12月。 提案標準。 -- RFC 1808, RFC 2368, RFC 2396 が更新。 -- この文書は、位置及びインターネットを介した資源への接続の形式化された情報の構文及び意味である統一資源位置子 (URL) を規定します。 [92] RFC 1630 (URI) と RFC 1738 は、内容的に大体同じですが、文章としては全然違います。 ** RFC 1808 (第2世代の相対URL) [41] - [[RFC1808]] -- 『Relative Uniform Resource Locators (相対統一資源位置子)』 -- R. Fielding, 1995年6月。提案標準。 -- RFC 1738 を更新。 -- RFC 2368, RFC 2396 が更新。 -- 統一資源位置子 (URL) は、インターネットを介して入手可能な資源の位置及び接続方法の短小な表現です。 URL を基底分書中に埋め込む時には、 絶対形式だと基底文書の取り出しの文脈で、 方式, ネットワーク位置, url-path の一部のように非常に多くの既知の情報を含んでいます。 基底 URL が良く定義されていて解析器 (人間又は機械) がそれを知っている時には、その文脈を実現値毎に際して慰するのではなく、継承した URL 参照を埋め込むことが出来ると便利です。 この文書ではこのような相対統一資源位置子の構文と意味を定義します。 - [1] [CODE(ABNF)[[DFN[URL]] = ( absoluteURL | relativeURL ) [ "#" fragment ] ]] ;; [[RFC 1808]] ** RFC 2396 (第3世代) [43] - [[RFC2396]] -- 『Uniform Resource Identifiers (URI): Generic Syntax (統一資源識別子 (URI): 一般的構文)』 -- T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月。原案標準。 -- RFC 1808, RFC 1738 を更新。 -- 統一資源識別子 (URI) は、抽象資源又は物理資源を識別する短小な文字の列です。 この文書は、絶対形及び相対形の双方を含む、 URI の一般的構文とこれらの使用の指針を定義します。 この文書は RFC 1738 及び RFC 1808 の一般的定義を改訂・置換します。 -- この文書は全ての妥当な URI の超集合である文法を定義します。従って、実装は方式規定の可能な識別型毎の要件を知ること無しに URI 参照の共通の部品を解析することが出来ます。 この文書は URI の生成文法は定義しません。 その作業は各 URI 方式の個々の仕様書が行うことでしょう。 [91] RFC 1738 (URL) と RFC 2396 (URI) は、ほとんど別の文章です。扱う対象はほぼ同じであるにもかかわらず、 2396 は概念的にもかなり整理されていて、 [KBD[[[diff]]]] が役に立つ立たない以前の問題です。それ程違います。 [90] RFC 1808 (相対 URI) と RFC 2396 は、多くの部分が共通しています。節単位で [KBD[diff]] を取ったら違いは [CODE[URL]]→[CODE[URI]] ばっかり、みたいな。それでも、 2396 の包括的な定義に比較すると 1738 的古臭さ(謎)を感じる部分があって、その辺は 2396 にそのまま入ってはいません。 [93] >>92、>>91、>>90 というわけで、 URI の仕様書は毎回全然違う内容で出てくるのであって、同じ WWW でも [[HTTP]] の仕様書 ([[RFC1945]], [[RFC2068]], [[RFC2616]]) が追記的に成長していっているのに比べると、中々興味深いところであります。 [94] >>93 比較的早くまとまった (それでも随分かかってるけど。) HTTP の仕様に比べて、 URI は色々ありましたからねぇ。概念的に成熟するまでが長かったし、未だに不安定な部分も多々あるし・・・。 [95] >>94 HTTP みたいな転送プロトコルは前例が一杯あるからかも。 URI のような規模の番地付けってインターネットでは初めての試みだったと思うし。 [96] WWW のもう一つの要素, [[HTML]] は、[[リッチテキスト]]的構成要素は爆発的に進歩したよね。仕様の安定性って話とはちょっと違うけど、今までの文書処理の経験がやっぱり効いてると思う。一方で単純参照リンク以上の[[リンク]]とか、[[メタ情報]]とか、そっちの方向は全然進まなくて、今になってようやく [[SemanticWeb]] とか大々的に表に出てきた。っていう二面性があって又興味深い。リンクもメタ情報も、やっぱり十分な経験がなかったから。 [97] >>95-96 そういう意味では、 HTTP でも、リンクやメタ情報って蔑ろにされがち。リンクなんてほとんどなかったことにされてるし。。。 [44] - [[RFC2717]] = [[BCP35]] -- 『Registration Procedures for URL Scheme Names (URL 方式名の登録手続き)』 -- R. Petke, I. King, 1999年11月。現状の最善の運用。 -- この文書は、新しい URL 方式を登録する過程を定義します。 [45] - [[RFC2718]] -- 『Guidelines for new URL Schemes (新しい URL 方式の指針)』 -- L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, 1999年11月。情報提供 RFC。 -- 統一資源位置子 (URL) はインターネットを介して入手可能な資源の位置の短小な文字列表現です。 この文書は新しい URL 方式の定義の指針を提供します。 [47] - ''URIs, URLs, and URNs: Clarifications and Recommendations 1.0'' IETF/W3C 合同 URI 特別部会の報告。 ** RFC 2373 (IPv6 拡張) [48] - [[RFC2732]] -- 『Preferred Format for Literal IPv6 Addresses in URL's (URL 中の生 IPv6 番地の好ましい書式)』 -- R. Hinden, B. Carpenter, L. Masinter, 1999年12月。 -- この文書は、 World Wide Web ブラウザの実装での URL 中に生 IPv6 番地の書式を定義します。 この書式は Microsoft Internet Explorer, Mozilla, Lynz を含む幾つかの広く用いられているブラウザの IPv6 版で実装されています。 この書式はサービス位置プロトコルの IPv6 版でも使用される見込みです。 -- この文書は RFC 2396 で定義された統一資源識別子の一般的構文の更新を含みます。 この文書は IPv6 番地の構文を定義し、 この予約目的のために陽に URI 中に [CODE(URI)[[]] 及び [CODE(URI)[] ]] の使用を認めます。 ** RFC 1738 の廃止 [98] [[RFC 4248]] ([CODE(URI)@en[[[telnet]]:]] [[URI scheme]]) が発行されて、遂に [[RFC 1738]] が廃止されました。 [CODE(URI)@en[[[ftp]]:]], [CODE(URI)@en[[[news]]:]], [CODE(URI)@en[[[nntp]]:]], [CODE(URI)@en[[[gopher]]:]] は改訂版が出てないけどいいのかね? [CODE(URI)@en[[[gopher]]:]] は [[RFC編集者]]の[[待ち行列]]にいるからいいとして・・・。 ([[名無しさん]] [WEAK[2005-11-10 10:47:05 +00:00]]) [99] あ、 [CODE(URI)@en[[[file]]:]] も結局放置されたままじゃん? [100] しかし [[RFC 4248]] は全くやる気がないな。 [CODE(URI)@en[[[telnet]]:]] を[[標準化過程]]に残すためにとか書いてあったけど、 もう要らないんじゃないのか? それよりも [CODE(URI)@en[[[ftp]]:]], [CODE(URI)@en[[[news]]:]], [CODE(URI)@en[[[file]]:]] が一時的にせよ[[標準化過程]]から離れることの方がむしろ問題かと。 ([[名無しさん]] [WEAK[2005-11-10 10:52:16 +00:00]]) ** RFC 4395 [101] [[RFC 2717]], [[RFC 2718]]は[[廃止]]されて[[BCP 115]] [[RFC 4395]]になりました。 ([[名無しさん]] [WEAK[2006-02-14 14:11:09 +00:00]]) ** 90年代-00年代の応用仕様における URL [75] - [[RFC1727]] -- 『A Vision of an Integrated Internet Information Service (統合インターネット情報サービスの展望)』 -- C. Weider, P. Deutsch, 1994年12月。 -- この論文は、今後数年間でインターネット情報サービスがいかに統合されるかの展望を示し、 統合を実現するためにどのような手順が必要かの詳細を幾らか議論します。 - [[RFC1728]] -- 『Resource Transponders (資源配送路)』 -- C. Weider, 1994年12月16日。 -- ここ数年で資源の位置とインターネット上の誘導を提供する数多のシステムが作られてきましたが、 これらのシステムに含まれる情報は手動で管理・更新しなければなりません。 この論文では、資源位置情報を維持するために、 自動化機構と資源配送路を記述します。 - [[RFC2016]] -- 『Uniform Resource Agents (URAs) (統一資源エージェント URA)』 -- L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan, 1996年10月。実験的 RFC。 [FIG(quote)[ [FIGCAPTION[ [49] [[RFC 1866]] ([[HTML 2.0]]) における定義 ]FIGCAPTION] > :[DFN@en[URI]]: A Uniform Resource Identifier is a formatted string that serves as an identifier for a resource, typically on the Internet. URIs are used in HTML to identify the anchors of hyperlinks. URIs in common practice include Uniform Resource Locators (URLs)[URL] and Relative URLs [RELURL]. ]FIG] [50] >>49 について、この定義では[[URN]]は[[URI]]に含まれていないのではないかと指摘する人がいますが、単に[[URL]]が[[URI]]に含まれていることを述べているに過ぎず、[[URN]] (や[[URC]]やその他の何か) については何も言及していないと解釈するのが適当だと思います。 [FIG(quote)[ [FIGCAPTION[ [2] [[JIS X 4081]]:2002 ]FIGCAPTION] > :s) URL (Uniform Resource Locator):[[インターネット]]上の[[アドレス]]。 ]FIG] [3] >>2 なにこの定義、ふざけてるの? [76] - 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes) (Updated by RFC2915) (Status: EXPERIMENTAL) - 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL) - 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT=64811 bytes) (Status: INFORMATIONAL) - [[RFC2483]] -- 『URI Resolution Services Necessary for URN Resolution (URN 解決に必要な URI 解決サービス)』 -- M. Mealling, R. Daniel, 1999年1月。実験的 RFC。 -- 統一資源識別子 (URI) によって識別される資源の取り出しは、 URI について施せる処理の1つに過ぎません。 元の URI から、例えばその別名である他の識別子の一覧やその URI が示す資源の書誌的記述を尋ねたり入手したりもするかもしれません。 これは統一資源名 (URN) に対しても統一資源位置子 (URL) に対しても適用されます。 統一資源特性 (URC) はこの文書中で議論しますが、 識別子というよりは資源の記述に過ぎません。 - 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT=26252 bytes) (Status: INFORMATIONAL) [77] - [[RFC2017]] -- 『Definition of the URL MIME External-Body Access-Type (URL MIME 外部本体接続型の定義)』 -- N. Freed, K. Moore, A. Cargille, 1996年10月。提案標準。 - 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD) - 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT=83612 bytes) (Status: INFORMATIONAL) - [224] [CITE@en[[[RFC 3305]] - Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations]], [TIME[2021-04-11T09:04:54.000Z]], [TIME[2021-04-22T09:17:33.809Z]] - [225] [CITE[RFC Errata Report » RFC Editor]], [TIME[2021-04-22T09:17:48.000Z]] ** URI もどき [133] URI が使われる文脈で使われる、 URI でない (又はなさそうな, あってほしくない) ものたち, および [[URL]] っぽいが [[URL]] だとは明言されていないものたち - [[emacs-w3m]] で -- [CODE[eiwa:]], [CODE[kokugo:]], [[CODE[waei:]] に続けて語句を指定すると、その語句を辞書で検索する。 - [[IRI]] ・・・URI の多文字拡張 - [[SuikaWiki]] の URI もどき -- [CODE[IMG:]] (case-sensitive) 画像参照。 -- [CODE[IW:]] (case-sensitive) [[InterWiki]] の接頭辞。 See -- [CODE[MAIL:]] (case-sensitive) 電子メイルの宛先。 -- 詳細は [[SuikaWiki/0.9]] 仕様書を参照。 これらは URI ではありません。 - [CODE[URL:]] [[URL]] の前につける。例: [SAMP(URI)['''<'''URL:http://foo.example/'''>''']] - [[MRL]] - [[QRコード]] - [CODE[gid:]] [136] [CITE[ResourceUtils (Spring Framework)]] [[Java]]の[[パッケージ]]を表す[Q@en[[CODE(URI)@en[classpath:]] pseudo URL]]がある。 ;; [[Java]]の[[クラス]]のための[[URI scheme]]は[CODE(URI)@en[[[java]]:]]など他にも複数ある。 ;; 2008年12月現在、 [CODE(HTTP)[[[404]]]]。 [198] [[Oracle]] の [CODE[DBURIType]] は [[URI]] を名乗っていますが、 実際には [[XPath]] です。 ** HTML5 と URL Standard [145] [[HTML5]] で [[Web]] における [[URL]] が規定されました。紆余曲折を経て、 単独の[[仕様書]] [[URL Standard]] となりました。 ;; [144] [[URL Standard]] 参照。 [239] [CODE[Karasuma::URL]] * メモ [50] [CITE[Document Structure – SVG 1.1 (Second Edition)]] ( ([TIME[2011-08-10 12:35:27 +09:00]] 版)) [51] [CITE[How many ways can you slice a URL and name the pieces? - Tantek]] ( ([TIME[2011-11-07 00:05:48 +09:00]] 版)) [52] [CITE@EN[The use of Metadata in URIs]] ( ([TIME[2007-07-25 03:37:05 +09:00]] 版)) [53] [CITE@en[URL formats · Microformats Wiki]] ([TIME[2012-05-07 14:15:33 +09:00]] 版) [54] [CITE[cweb/iri-tests]] ( ([TIME[2012-06-30 17:53:36 +09:00]] 版)) [55] [CITE[JSON-LD API 1.0]] ( ([TIME[2012-06-27 10:09:09 +09:00]] 版)) [56] [CITE[WWW-Talk Apr-Jun 1993: URL plain text version's URL]] ( ([TIME[2013-03-05 12:47:59 +09:00]] 版)) [57] [CITE[IRC logs: freenode / #whatwg / 20131220]] ( ([TIME[2013-12-24 15:23:05 +09:00]] 版)) [58] [CITE@en[Bug 23968 – Reference the URL spec]] ( ([TIME[2013-12-25 10:48:00 +09:00]] 版)) [59] [CITE@en[draft-ietf-appsawg-uri-get-off-my-lawn-01 - Standardising Structure in URIs]] ( ([TIME[2014-01-30 14:08:55 +09:00]] 版)) [73] [CITE[Clarify URL use in APIs · eece8eb · whatwg/url]] ( ([TIME[2014-05-28 15:31:43 +09:00]] 版)) [74] [CITE@en-US[July 2014 snapshot of the URL Standard for the purposes of patent lawyers and government officials]] ( ([TIME[2014-07-30 19:15:47 +09:00]] 版)) [4] [CITE[How URL started as UDI — a brief conversation with @timberners_lee @W3C #TPAC - Tantek]] ([TIME[2014-11-01 03:29:01 +09:00]] 版) [22] [CITE@en[''''''[''''''whatwg'''''']'''''' Relative URL plan]] ([[Anne van Kesteren]] 著, [TIME[2015-06-16 21:06:50 +09:00]] 版) [23] [CITE@en[Remove incorrect note (URLs with scheme data also have query/fragment… · whatwg/url@d5470b8]] ([TIME[2015-06-17 17:03:27 +09:00]] 版) [28] [CITE@en[1151899 – Integrate the rust-url parser into necko]] ([TIME[2015-08-15 11:51:47 +09:00]] 版) [122] [[mohta]] 氏が script と language の違いを説いてるのがなんか可笑しい。 (1997年の [[ietf-url]] にて。) [2005] [CITE@en[draft-nottingham-uri-get-off-my-lawn-00 - Standardising Structure in URIs]] ( ([TIME[2013-08-03 08:59:10 +09:00]] 版)) [2007] [CITE@en-US[URI Specification Community Group]] ( ([TIME[2014-10-04 05:12:48 +09:00]] 版)) [2008] [CITE[public-urispec@w3.org Mail Archives]] ( ([TIME[2014-10-04 01:31:00 +09:00]] 版)) [2009] [CITE@en[Home · urispec/urispec Wiki]] ( ([TIME[2014-10-04 05:16:54 +09:00]] 版)) [2010] [CITE@en[RFC 7320 - URI Design and Ownership]] ( ([TIME[2014-07-28 17:57:37 +09:00]] 版)) [2011] [CITE@en[draft-ietf-urnbis-semantics-clarif-00 - URN Semantics Clarification]] ( ([TIME[2014-10-17 02:49:34 +09:00]] 版)) [123] [CITE[WWW-Talk Oct-Dec 1993: First URI meeting notes]] ([TIME[2015-01-24 23:55:20 +09:00]] 版) [124] [CITE[WWW-Talk Oct-Dec 1993: What URIs are and are not.]] ([TIME[2015-01-24 23:59:02 +09:00]] 版) [152] [CITE[未踏召喚://ブラッドサイン (電撃文庫) | 鎌池 和馬, 依河 和希 | ライトノベル | Amazon.co.jp]] ([TIME[2016-01-14 15:34:28 +09:00]] 版) [179] [CITE@en[26402 – "Parsed URL" isn't defined in URL]] ([TIME[2016-02-11 11:45:57 +09:00]] 版) [30] [CITE@en[Introduce the terms URL record and URL string for disambiguation. Fix… · whatwg/url@656b803]] ([TIME[2015-08-16 12:01:22 +09:00]] 版) [72] [CITE@en[URLs are parsed and produce records · whatwg/html@30bc255]] ([TIME[2016-02-14 23:04:15 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [178] [CITE@ja[GTFS リファレンス  |  乗換案内  |  Google Developers]] (最終更新日: 11月 25, 2015 ([TIME[2015-11-26 01:10:48 +09:00]])) ]FIGCAPTION] > 完全な URL 値を作成する方法については、http://www.w3.org/Addressing/URL/4_URI_Recommentations.html を参照してください。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [115] [CITE@ja[国会図書館検索でスマホ現在地漏えいの恐れ : 科学 : 読売新聞(YOMIURI ONLINE)]] ([TIME[2016-10-05 18:29:56 +09:00]]) ]FIGCAPTION] > 「位置情報がURLに含まれていることは把握している。URLに含まれるのは位置情報のみであり、個人を特定するものではないので、URLだけが第三者に知られたとしても個人が特定できるわけではない。現時点では改修の予定はない。ただしURLに位置情報を含めない方策についても今後検討していきたい」(国会図書館総務課広報)とのことだった。 ]FIG] [116] [CITE@en[Editorial: give URL syntax components their own terms]] ([[annevk]]著, [TIME[2016-11-01 00:05:41 +09:00]]) [194] [CITE[cpython: 110ec861e5ea Lib/urlparse.py]] ([TIME[2017-02-05 12:03:15 +09:00]]) [195] [CITE@en[Clarify valid URL]] ([[tstarling]]著, [TIME[2017-02-07 20:18:54 +09:00]]) [196] [CITE@en[Define which URLs are valid in the parser examples]] ([[annevk]]著, [TIME[2017-02-10 22:43:20 +09:00]]) [197] [CITE@en[Editorial: use valid URL string from the URL Standard]] ([[annevk]]著, [TIME[2017-02-10 19:54:54 +09:00]]) [207] [CITE@en[Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説 · GitHub]] ( ([TIME[2017-04-23 16:30:11 +09:00]])) [208] [CITE@en[RFC 1736 - Functional Recommendations for Internet Resource Locators]] ([TIME[2017-04-23 19:07:27 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [213] [CITE@en[Concise Binary Object Representation (CBOR)]] ([TIME[2018-02-23 07:30:37 +09:00]]) ]FIGCAPTION] > Tag 32 is for URIs, as defined in '''['''RFC3986''']'''; ]FIG] [117] [CITE@en[URL's object can no longer be a MediaStream]] ([[annevk]]著, [TIME[2018-04-21 01:40:56 +09:00]]) [12] [CITE@en[Editorial: url ➡️ URL]] ([[annevk]]著, [TIME[2018-08-17 20:57:19 +09:00]]) [187] [CITE@en[Editorial: spell URL concepts uppercase · Issue #697 · whatwg/fetch]] ([TIME[2018-09-04 16:22:09 +09:00]]) [188] [CITE@en[Editorial: url ➡️ URL by annevk · Pull Request #795 · whatwg/fetch]] ([TIME[2018-09-04 16:22:16 +09:00]]) [189] [CITE@ja[上原 哲太郎/Tetsu. Ueharaさんのツイート: "URLの//はどこから来たのか、というのはいま生き残っている分散OSではWindowsで使われてるUNCの\\が古いのでこれかな(起源はMS-Net)と思ってたんだけど、どうやらApolloがAEGISで//を1981年ごろには使ってたという指摘が。これが最古かな?https://t.co/tytnLkU1vA Tim先生はどちらを見て決めた?"]] ([TIME[2018-09-21 15:41:30 +09:00]]) [190] [CITE@en[Editorial: url ➡️ URL]] ([[annevk]]著, [TIME[2018-08-17 20:57:19 +09:00]]) [218] [CITE@en[Editorial: spell URL concepts uppercase · Issue #697 · whatwg/fetch]] ([TIME[2019-03-04 16:37:59 +09:00]]) [219] [CITE@en[Editorial: url ➡️ URL by annevk · Pull Request #795 · whatwg/fetch]] ([TIME[2019-03-04 16:38:08 +09:00]])