URL Standard

[32] URL Standard は、 Web におけるアドレスである URL を定義する仕様書です。 URL の構成要素としてのホスト (ドメインとIPアドレス) の定義も含まれています。

仕様書

[138] URL Standard (2014-04-15 13:16:21 +09:00 版) http://url.spec.whatwg.org/

規定

[177] URL Standard では次のものが規定されています。

URL
- 構文解析
- 直列化
- URLの起源
- DOM URL API
ホスト
- ドメイン
- IPアドレス
  - IPv4アドレス
  - IPv6アドレス
パーセント符号化
application/x-www-form-urlencoded

[180] URL を構成する細かい概念については、 URL の項を参照。

[178] URL Standard は、 URL に関する様々な歴史的な仕様書: RFC 3986, RFC 3987, HTML Standard の URL の章、 URL API, RFC 6454 の URLの起源の章を置き換え、統合的に規定するものです。

歴史の項も参照。

[179] なお IPv6アドレスの記述方法の規定には RFC 4291、 IDNA の取り扱いには UTR #46 を参照しています。

歴史

[33] 本項では主として HTML5 以降の「URL」 (現実世界の Webブラウザーにおける URL) について扱います。 IETF 仕様等での歴史的定義については URI、IRI などの項をご覧ください。

URI の時代

[34] 元々 Web のアドレスは「URL」と呼ばれていました。 RFC 1808 までは仕様上も一般的にも URL でした。しかし、かねてから URL や URN などの上位概念としての「URI」が提唱されていて、 RFC 2396 以後は仕様上は専ら「URI」という語が使われるようになりました。

[35] 仕様上の概念としても「URL」が消滅したわけではなく、 URI の部分集合に過ぎないとされただけでしたが、特に区別の必要の無い時は「URI」と呼称するのが好ましいとその筋の人達には考えられていました。

[36] URI の多文字拡張は、現実には Webブラウザーで「URL」の名前のまま行われていましたが、仕様上は「IRI」という新しい呼称が与えられました。

URL の復調

[37] Web Forms 2.0 は、はじめは当時の仕様の世界の流れに従い input 要素の type 属性の値として uri を定義していましたが、 url に変更されました。

[38] Web では CSS の url() 関数、 JavaScript の document.URL 特性、 HTTP の Refresh: 欄の url 引数など、実質すべての場面で「URI」ではなく「URL」が使われていました。 (namespaceURI など DOM2 / DOM3 に由来する部分だけ「URI」になっています。) そのため、 Web 開発者がより慣れ親しんでいる「URL」で統一することが望ましいと考えられたのです。

[39] ただし、このときはまだ属性値が url となっただけで、仕様書中の表現は「URI (or IRI)」などとされていました。

[51] [whatwg] [wf2] type="url" http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-February/003102.html

url への変更は annevk により提案されました。

[49] [whatwg] [wf2] type="url" http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-March/003201.html

最初は Ian Hickson も uri が良いとしていました。

[50] [whatwg] [wf2] type="url" http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-March/003257.html

他の人の意見を踏まえて url になりました。

新しい定義

[54] Web Applications 1.0 (HTML5。Web Forms 2.0 を含む。) は「URI (or IRI)」という表現を使っていましたが、これだけでは現実のWebブラウザーの挙動と HTML文書の著者の想定を十分記述できておらず、明確化が今後の課題とされていました。

[55] Web Applications 1.0 仕様中の他の課題が大方片付いてきた2008年5月、 URL に関して規定するべき項目のリストアップが行われました。

[52] Web Applications 1.0 r1534 placeholder for URL section (2008-05-07 09:55:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=1533&to=1534

[56] そして2008年6月、「URL」の定義が追加されました。“URI vs URI参照”や “URI vs IRI”、“URI vs 絶対URI”といった専門家にも理解できない混乱した用語の定義を使わず、一般的に使われている意味をベースに「URL」などの語が定義されました。また、 URI/IRI として正しいかどうかに関わらず、URL であるとして与えられたすべての文字列に関して、 scheme や path などの各部の取り出しの処理や絶対URL への解決の処理をどう行うべきか、非ASCII文字をどう処理するべきかが初めて明確に規定されました。動的な DOM の変更によって絶対URLへの解決がどう影響を受けるかも規定されました。

[53] HTML5 Tracker (2008-06-29 版) http://html5.org/tools/web-apps-tracker?from=1776&to=1829

[57] それまでは、 URI/IRI の仕様は正しくない文字列をどう処理するべきかを規定していませんでしたし、 HTML4 など数多くの仕様書が「URI」という語の定義を正しく理解せずに書かれていたりして、何が仕様上正しいのかを確定することもできない状況でした。現実には URI/IRI として正しくない文字列が href 属性などに指定されていることはありふれていますし、非ASCII文字は (IRI 仕様が述べているように) 単純に UTF-8 として解釈するべきではないことも多々あります。既存のWebブラウザーの動作をリバース・エンジニアリングして真似るか、仕様書に従い役に立たないものを作るか、という不健全な時代がやっと終わり始めました。

XXX

メモ

[1] uri@w3.org の長いスレッド超ワロスwwwww (名無しさん 2008-06-26 14:42:02 +00:00)

[2] Ian Hickson もどうせ、通るわけないだろうと最初から諦めてるんだろうね。 HTTP5 同様、議論を持ちかけたけどあっちが蹴ったという記録を残しておくために。

ハイパーテキスト参照

仕様書

規定

歴史

URI の時代

URL の復調

新しい定義

XXX

メモ