仕様書

呼称

[164] URL のスキームであることを明確にするため、「URLスキーム」 と呼ぶこともよくあります。

[105] 「スキーム (scheme) 」は、プロトコルを表すものであることから、 しばしばそのまま「プロトコル (protocol) 」とも呼ばれます。

[107] : の前までを scheme ないし protocol と呼ぶ場合もあれば、 scheme であることを明確化するために : まで含めて記述することもあります。

[106] しばしば「スキーマ (schema) 」と混同されます。 近い分野の技術用語に「scheme」と「schema」 の両方があるので、「スキーム」と「スキーマ」 と訳し分ける慣例をもって区別しているのであり、 URL のものを「スキーマ」と呼ぶのは明白な誤りです。

[2] Google のドキュメントが scheme をスキーマと誤訳しているのはどうにかならんものか。 技術文書を正しく雇えるまともな翻訳者を雇うか、 お得意の AI を生かした誤訳検知をしっかりやってくれよ... 2020-02-17T06:34:54.000Z

URL scheme の一覧

[1] URL scheme には標準的なもの、提案されている(た)もの、私的に用いられているものなど、 様々なものが存在します。

[67] 現在、すべての URL scheme の一覧と言えるものは存在していません。 IANA は IETF の RFC などで定義された URI scheme の一覧を管理していますが、 実際に用いられている URL scheme のごく一部しかカバーできていません。 その他 iPhone で用いられている URL scheme など範囲を限った一覧も Web 上に多々存在していますが、そのカバー率はそれぞれです。

[69] 次に示す URL scheme の一覧表は、主に本ウィキに (多かれ少なかれ) 情報がある URL scheme を中心に掲載しています。 >>50 の JSON ファイルは、次に示す一覧表に加え、 より多くの URL scheme の情報を掲載しています (が、それでもカバーできていない URL scheme が尚も数多く存在していると思われます)。

構文

[203] 一般には http:// のように特徴的な :// の記号列で知られていますが、 // は authority が続くことを意味しています。 authority がない URL には // が付きません。

• [10] scheme := 1*( ALPHA / DIGIT / "+" / "-" / "." ) ;; RFC 1808
• [11] scheme := ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) ;; RFC 2396
• [12] RFC 2396 からは、 scheme 名の最初の文字はラテン文字でなければならないことになっています。実際にラテン文字以外で始まった URI scheme 名が使われたことがあるのかは不明です。 (IETF や W3C の規定したもののなかにはないです。)

分類

[108] 次の分類があります。

文脈

[17] URL scheme 名は、 URL や URL から派生した起源などの構文の他に、 次の場面でも用いられます。

[162] 項組起源の scheme >>161 は、 起源のうちの URL scheme の部分を表しています。

相対 URI 参照

• [13] 相対URI参照と絶対URI参照は、 最初に scheme 名があるかどうかで区別できます。 RFC 1808 は scheme 名のついた相対 URL を認めていましたが、 RFC 2396 は認めていません。
• [14] >>13 は間違い。 RFC 1630 は認めていますが、 1808 も 2396 も認めていません。 1808 は、古い実装はそういうのも認識するけどイクナイ!, 2396 は互換性のためには仕方ないけどやっぱりイクナイ! といってます。

URL scheme とプロトコル

[70] 多くの URL scheme は対応するプロトコルが存在しています。

[72] 対応するプロトコルがある場合の多くは HTTP GET に相当する操作が存在していて、それを実行して結果を取得することを URL の dereference (解参照)、retrieve などと呼ぶことがります。

[74] しかし対応するプロトコルがあっても、その性質上、 GET 相当の操作が存在しないことがあります。

[78] 特定のプロトコルと関連付けられていない URL scheme もあります。

web+*:

[101] web+ から始まる URL scheme 名群は、 registerProtocolHandler によって Webアプリケーションが登録して利用する URL scheme となっています。

fb*:

[102] fb から始まり数字列が続く URL scheme 名群は、 スマートフォンアプリが Facebook のアプリと連携するために利用しています。

[103] 本来は当該アプリが Facebook連携機能を実装する手段として用いるものですが、 そのアプリが他に手段を用意していない時に第三者がそのアプリを起動したり、 特定の機能を呼び出したりするために流用されることがあるようです。

[104] 数字列部分は (Facebook 内にはアプリとの対応データベースがあるのでしょうが) 第三者にとっては意味のない文字列とみられます。

x-*:

[187] RFC 1630 時代は、 x- から始まる URL scheme は私用とされていました。この規定はなぜかその後削除されています。

[188] しかしその後もいくつか x- から始まる URL scheme が知られています。

木

[90] かつて RFC 2717 は URL scheme に「木 (tree) 」 という概念を導入し、 IETF のプロトコルはIETF木に収容し、 それ以外は vnd-foo-bar のような - で階層化された名前空間に収容することを企てていました >>91。 RFC 2717 はIETF木 (IETF tree) を規定していました。 IETF木の URL scheme 名では - の利用が禁止されていました >>91。

[92] draft-king-vnd-urlscheme は RFC 2717 に基づき vnd- 木 (企業利用目的) と prs- 木 (個人利用目的) を確立しようと試みていました。

[193] URI.ARPA は、登録対象を IETF木に限定していました。

[96] しかしこの方法は支持を集められなかったようで、 I-D は RFC になることがなく、結局木は使われることなく RFC 4395 により廃止されています >>95。

[97] なおこの当時 IANA には - を含む URL scheme は登録されていませんでしたが (現在は登録されています)、現実にはかなり前から view-source: など - を含む URL scheme が存在していました。 IETF は IANA登録簿に登録されていない現実世界の URL scheme の存在を完全に無視していました。

逆ドメイン名

[136] RFC 4395 は私的な URL scheme について、逆ドメイン名の . のかわりに - を区切り文字に使ったものを名前とすることを推奨 (encourage) していました >>128。

[140] RFC 7595 は (置き換えない) 逆ドメイン名そのものを使うべき >>135 としています。それ以外での用途で . を使ってはならない >>135 ともしています。

[141] しかし私的な名前を使う場合であっても登録することが強く推奨 (strongly encouraged) されています >>135。

[142] 実際には URL scheme では逆ドメイン名はほとんど使われていません。 若干数はあります。衝突回避の方法としては vendor prefix の方がむしろ使われていますが、 それもわずかに過ぎません。

[143] . はどちらかといえばプロトコル階層の意味で用いられています。 そのような意味の URL scheme が IANA登録簿にもいくつか既に登録されています。 この慣習を否定するような規定を敢えて加えた意図は不明です。 IETF が IETF/IANA 外の現実世界の用法を無視するのはいつものことだとしても、 IETF 自身の過去の仕様と矛盾する制限を加えるのは不思議です。

衝突

[173] URL scheme 名は、衝突する可能性があります。

[129] 公式には URL scheme にはIANA登録簿 (>>121) がありますが、 破綻状態で、 URL scheme の衝突回避の役目は果たしていません。 木 (>>90) や逆ドメイン名 (>>136) もほとんど使われていません。

[168] 一方で現代的なほとんどのプラットフォームと Webブラウザーは、 任意のネイティブアプリケーションやWebアプリケーションが URL scheme を登録できる機能を提供しています。 (プラットフォームごとの若干の制約はあるとはいえ) 実質的に URL scheme の名前空間は完全に開放されているのが現状です。

[169] このような状況で、異なる意味・用法で同名の URL scheme が現れるのは必然です。 00年代初期には既に衝突例が複数見られました (>>25、>>26)。 もしかすると90年代に既にあったかもしれません。

[170] 00年代末にはスマートフォンアプリ、とりわけ iOS のアプリで標準的で簡易なプロセス間通信の手段として普及し、 URL scheme が爆発的に増加しました。それに伴い衝突例も増えました。

[166] 更には、悪意を持って敢えて他のアプリケーションの URL scheme をプラットフォームに登録し、利用者の操作を妨害したり、情報を漏洩させたり、 その他何らかの利益を得たりしようとする事例が複数報告されています。 こうした攻撃は、 URL Scheme Hijacking と呼ばれています。

[175] プラットフォームは、極めて標準的な URL scheme (https: や about: など) を安易にアプリが登録することを防ぐべきです。

[176] プラットフォームは、それ以外の URL scheme についても、 利用者が気付かないうちに異なるアプリに登録が切り替わることを防ぐべきです。

[174] アプリマーケットは、技術的に可能であれば、 URL scheme を不審な方法で利用するアプリの登録を拒絶するべきです。

[171] 任意の URL を入力として受け取るアプリケーション、 とりわけ UGC 系Webアプリケーションなどは、 悪意ある利用者が他の利用者に攻撃する手段とすることを防ぐため、 既知の標準的な URL scheme (https: や mailto: など) 以外の URL scheme をすべて拒絶すること (ホワイトリスト方式) を原則とするべきです。 自動リンクする URL scheme もホワイトリスト方式とするべきです。

[172] Webサイトからネイティブアプリへの誘導などの目的で特定の既知の標準的でない URL scheme を用いる場合も、悪意あるアプリが登録された状態で情報が漏洩することがないよう、 十分配慮するべきです。例えばアカウントの登録や OAuth のフローの後に利用者にネイティブアプリに戻って欲しい時に、 秘密のトークンを URL に含めたりしてはいけません。フィッシングにも注意する必要がありそうです。

[180] プラットフォームは、より確実に送信先を指定できる IPC の手段を用意するべきです。アプリケーションは、そのような手段が存在するなら、 可能な限りそちらを用い、 URL scheme に頼ることは避けるべきです。

[181] アプリケーションは、独自の URL scheme を定義する場合、 漏洩するべきでない情報を指定できるようにするべきではありません。

URL scheme とアプリケーション

[196] 多くのプラットフォームは、 URL scheme とアプリケーションを関連付ける機能を有しています。

[197] 古くはアプリケーション (Webブラウザー) ごとに、未対応 URL scheme を扱うヘルパーアプリケーションを設定する機能を有していました。 (例えば Lynx や Netscape Navigator にそのような機能がありました。)

[198] Internet Explorer はこれを Windows の機能としました。 以後他の OS も類似の機能を搭載し、 Webブラウザーは OS の機能を使うようになりました。

[199] iOS や Android はネイティブアプリケーションの IPC 機能として活用しています。

[191] WinSCP は既存の URL scheme の前に winscp- をつけることで、 他のアプリケーションではなく WinSCP で開くべきことを指定できるようにしています。

IANA 登録簿

[121] URL scheme には IANA登録簿があります。

[120] URI scheme が IANA に登録されるまでには、 おおむね次の経過をたどります。 (色々の兼ね合いで仔細は異なることがあります。)

[151] 一旦 IESG で承認された後は後戻りすることはありませんが、 各段階のタイムラグがかなりあります。 (RFC Editor や IANA は随分と忙しいらしいです。)

[152] 新しい URI scheme を使いたい時は、 IESG で承認されれば (承認したと ietf-announce で告知されれば) RFC の発行を待つ必要はありません。

[153] 前述の通り、 IANA登録簿は IETF が規定する URI scheme + α 程度しかカバーしておらず、その実質的な効力は限定的なものです。 IANA登録簿に登録されているかどうかに基づき何らかの判断 (ある URL が適切か否かなど) を行うのは不適切と言わざるを得ません。

[155] 予備的な登録ができるようになり、 URL scheme の開発者でない第三者でも登録が可能となったことで、 Dave Thaler が巷で使われている URL scheme を多数登録しています。 しかしそれも実際に使われている URL scheme のごく一部に過ぎません。 登録の雛形には各 scheme の一応の説明はありますが、開発元の公式なものではありませんし、 その後本登録に向けた動きがあるわけでもなく、 scheme 名の (IETF における) 予約程度の意味しかなさそうです。

API

[160] location.protocol など、 DOM API では protocol と呼ばれています。

歴史

実装

[19] URL Schemes Supported in Lynx http://lynx.isc.org/release/lynx2-8-3/lynx_help/lynx_url_support.html

[15] URL Loading Systemを拡張する http://homepage3.nifty.com/kimuraw/misc/nsurlprotocol.html

Mac OS X の URI system。

メモ

[18] UR* new schemes considerations http://www.apps.ietf.org/url-schemes.html (Last modified: Mon Sep 22 09:14:58 1997)

[21] Architecture of the World Wide Web, Volume One http://www.w3.org/TR/webarch/#URI-scheme