[64] スキーム (URL scheme) は、 URL のうち先頭の
: までの部分です。 URL
を解決するために使うプロトコルや、 URL によって表される対象の種類・命名法などを表しています。
[65] 例えば http://www.example.com/ では http がスキームです。
この URL が HTTP プロトコルにおけるアドレスであることを表しています。
[66] tel:0123456789 では tel がスキームです。
この URL が電話番号であることを表しています。
[164] URL のスキームであることを明確にするため、「URLスキーム」 と呼ぶこともよくあります。
[105] 「スキーム」は、プロトコルを表すものであることから、 しばしばそのまま「プロトコル」とも呼ばれます。
[106] しばしば「スキーマ」と混同されます。
[107] : の前までを scheme ないし protocol と呼ぶ場合もあれば、
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 が尚も数多く存在していると思われます)。
scheme := 1*( ALPHA / DIGIT / "+" / "-" / "." ) ;; RFC 1808scheme := ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) ;; RFC 2396%4Baffee のように、大文字・小文字の区別に意味があるために URI符号化を必須としているものもあります [RFC 2324]。K は reserved じゃないから、 %4Baffee と Kaffee は同等で、大文字・小文字の同一視を認めるとすると結局 kaffee なんだけどね。[108] 次の分類があります。
[17] URL scheme 名は、 URL や URL から派生した起源などの構文の他に、 次の場面でも用いられます。
[162] 項組起源の scheme >>161 は、 起源のうちの URL scheme の部分を表しています。
[70] 多くの URL scheme は対応するプロトコルが存在しています。
[72] 対応するプロトコルがある場合の多くは HTTP GET
に相当する操作が存在していて、それを実行して結果を取得することを URL の
dereference (解参照)、retrieve などと呼ぶことがります。
[74] しかし対応するプロトコルがあっても、その性質上、 GET
相当の操作が存在しないことがあります。
[78] 特定のプロトコルと関連付けられていない URL scheme もあります。
[80] 同じアプリケーションプロトコルの下位層プロトコルが異なるものが使われる場合があります。
[82] プロトコルと関連付けられている URL scheme の多くは、特定の下位層プロトコルを想定しており、 複数存在するときはそれぞれ別の URL scheme が用意されています。
[84] 素の TCP の場合と TLS/SSL over TCP の場合がある時は、
TLS/SSL の側は末尾に s を付けるのが一般的です。
[86] UDP などを rtspu: のように表した例もあります。
[85] IETF では iris.beep: や iris.xpc:
のように . 区切りで示す例がいくつもあります。
[87] 世間では svn+ssh: や openvz+unix:
のように + 区切りで示した例もあります。
[190] ffmpeg は、 URL の前に crypto: または crypto+
をつけることで、暗号化されたデータを表しています (cryoto+ 参照)。
crypto: は単独の URL scheme ですし、 crypto+ は
crypto+http のような階層化された URL scheme と解釈できます。
[88] scheme 中の --, -+, +-, ++
に意味を持たせて体系化しようとした提案もありましたが、受け入れられなかったようです >>89。
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 に「木」
という概念を導入し、 IETF のプロトコルはIETF木に収容し、
それ以外は vnd-foo-bar のような - で階層化された名前空間に収容することを企てていました
>>91。 RFC 2717 はIETF木を規定していました。
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 について、逆ドメイン名の
. のかわりに -
を区切り文字に使ったものを名前とすることを推奨していました >>128。
- をそれ以外で使うことを禁止はしていませんでした。[140] RFC 7595 は (置き換えない) 逆ドメイン名そのものを使うべき
>>135 としています。それ以外での用途で .
を使ってはならない
>>135 ともしています。
[141] しかし私的な名前を使う場合であっても登録することが強く推奨されています >>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 についても、 利用者が気付かないうちに異なるアプリに登録が切り替わることを防ぐべきです。
[177] 例えば常に最後にインストールしたアプリが優先されるような状態だと、 フィッシングにより悪意あるアプリをインストールさせ、 既存のアプリを使った処理を乗っ取ることが容易になります。
[178] 新しくインストールされたアプリが既存のアプリと衝突する URL scheme を登録したら、その初回利用時にどちらを使うか利用者に選択させれば、 少なくても利用者が知らないうちに悪意あるアプリに差し替わることは防げます。
[174] アプリマーケットは、技術的に可能であれば、 URL scheme を不審な方法で利用するアプリの登録を拒絶するべきです。
[179] 例えば URL scheme を数十個も登録するアプリは、明らかに不審です。
[171] 任意の URL を入力として受け取るアプリケーション、
とりわけ UGC 系Webアプリケーションなどは、
悪意ある利用者が他の利用者に攻撃する手段とすることを防ぐため、
既知の標準的な URL scheme (https: や mailto: など)
以外の URL scheme をすべて拒絶することを原則とするべきです。
[172] Webサイトからネイティブアプリへの誘導などの目的で特定の既知の標準的でない URL scheme を用いる場合も、悪意あるアプリが登録された状態で情報が漏洩することがないよう、 十分配慮するべきです。例えばアカウントの登録や OAuth のフローの後に利用者にネイティブアプリに戻って欲しい時に、 秘密のトークンを URL に含めたりしてはいけません。フィッシングにも注意する必要がありそうです。
[180] プラットフォームは、より確実に送信先を指定できる IPC の手段を用意するべきです。アプリケーションは、そのような手段が存在するなら、 可能な限りそちらを用い、 URL scheme に頼ることは避けるべきです。
[189] プラットフォームによっては、
独自の URL scheme ではなく、
標準的な URL scheme の一部をアプリケーションに関連付ける機能を提供しています。
Example SNS のアプリケーションは、
example: を登録する代わりに、
https://www.example.com/ で始まる URL を登録できます。
この方法なら、 Example SNS アプリケーションがインストールされていない環境では
Webブラウザーを起動し、インストールされていればアプリケーションが起動するように自動的になりますし、
プラットフォームのアプリマーケットの審査が機能している限り、
悪意ある他のアプリケーションが起動してしまうことを防げます。
[181] アプリケーションは、独自の URL scheme を定義する場合、 漏洩するべきでない情報を指定できるようにするべきではありません。
ただこのアプリは普通じゃありませんでした, なんと297個(2015.02.14時点)もあったんです, それもGoogleやTwitterなど, 他のサードアプリのURLスキームがズラっと並んでいるんですね…
このアプリには画像の通り4つURLスキームが登録されており, 4つ目に twitter: がありますね.
先日紹介した時点ではURLスキームが257点という, この時点でも異常な数なんですが, 2.2で確認したところ, なんと938点に爆増していました…
Yahoo!ブログの方でも書いたんですが, その大半は「既にある別のアプリのURLスキームと同一」であるため, 場合によってはそちらのアプリをランチャなどで開きたいのに, このフリマアプリが起動してしまう…という致命的な問題をはらんでいます.
ポケモンの出現位置をリアルタイムで表示する地図アプリ「ポケモンGO マップ - リアルタイムでポケモンを探そう!」が人気で、AppStoreの無料総合ランキング上位に位置しています。
しかし、このアプリについて、「モンストマルチ掲示板が乗っ取られる」「モンストマルチのLINE募集機能が使えなくなる」などとレビューされています。
リリースしているアプリのURLスキームの数はいづれも3桁という通常ではありえない数, かつ他アプリと競合しておりそちらの起動を妨げる可能性がある
デベロッパーの実態が掴めない(対応サイトがない, あっても活動している節がない)
[195] LINEのBGMを変更やSNOWログインしようとすると全画面広告が表示されてしまう問題の原因と対策 | LINEの仕組み ( 版) http://did2memo.net/2017/07/14/naver-line-bgm-settings-to-facebook-sign-up/
[191] WinSCP は既存の URL scheme の前に winscp- をつけることで、
他のアプリケーションではなく WinSCP で開くべきことを指定できるようにしています。
[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 における) 予約程度の意味しかなさそうです。
[160] location.protocol など、 DOM API では
protocol と呼ばれています。
[28]
1994年頃Dan ConnollyはURI schemeをMIME
message/external-bodyのaccess-typeと共通にするか、少なくても一部の定義を共有しようと考えていたようです。
興味深いことにfile:は非推奨とされ、
MIMEと同じlocal-file:を採用しています。
[115] RFC 2717 (BCP 35) は IANA登録簿を新設し登録手続きを規定するものでした。 また RFC 2718 は URL scheme に対する指針を述べたものでした。
[118] RFC 2396 (URI) の出版後であるにも関わらず、なぜか RFC 2717 は URL scheme の登録手続き >>116 を規定していました。
[23] URI schemeは数多く存在するにもかかわらず、公式なIANA登録簿に登録されているのはそのうちのほんのわずかです。 これは、相互運用性上非常に問題です。
[24] 同じ目的の複数のURI scheme: 多く存在するURI schemeの中には、実際には同じ目的のものがあります。 どちらかにしか対応しない実装があって相互運用性の問題が発生したり、 複数個の (たぶん構文も異なる) URI scheme へ対応しないといけないという実装上の負担になったりします。
[25] 同じ目的・同じ名前の構文の異なるURI scheme: どこかで誰かが思いついたものと同じものを、 それとは独立に別の誰かが思いつくことはよくあります。 しかしURIの構文まで完全に一致することは、なかなかありません。 そうして異なる構文が乱立することになります。 まったく違う構文で見分けられるならまだ良い方で、 構文上区別がつかないこともあり得ます。
例えば、callto: URI schemeは電話の掛け先を表すURI schemeとして複数の実装がありますが、異なる構文であり、また、電話の通信プロトコルも異なっています。
[26] 違う目的の同じ名前のURI scheme: URI schemeの名前が一般的なものだと、 別の目的のURI schemeが同じ名前になってしまったりもします。
例えば、info: URI schemeは、
GNU Texinfo形式のマニュアルを識別するためにGNOMEとKDEで採用されていますが、両者の構文が異なっています
(>>25 の実例)。更に悪いことに、図書館業界でもURN的に使用しています
(>>26 の実例)。幸い、3つはすべて構文的に区別できます。
図書館業界の構文はIETFの正規の手続きによりIANAに登録されました。 実装の利用数で数えれば、おそらくはGNOMEやKDEの方式の方が多く使われていたでしょう (URIの使用数では分かりませんが)。にも関わらず、GNOMEやKDEの関係者が登録を怠ったために、このような事態に陥ってしまいました。
[123] RFC 4395 は RFC 2717/RFC 2718 を統合・改訂して改めて IANA登録簿の登録手続きを規定するものでした。
[125] 前版とは異なり、 URL scheme ではなく URI scheme となっています。 locator と名前との区別は不明瞭なものであると考えるのが当世の風潮であること >>124 が理由とされています。
[126] 前版で導入された木は使われなかったとして廃止されています。
[127] 従来の登録は「永続的」状態とされ、 新たに「予備」や「歴史的」 の状態での登録も可能となりました。
[131] RFC 4395 は BCP 115 として出版されましたが >>124、 RFC 2717 が BCP 35 だったことが後に発覚し、 BCP 115 は廃止されて BCP 35 となっています >>130。
[133] RFC 7595 (BCP 35) は、RFC 4395 を改訂して三度 URI scheme の登録手続きを定義するものです。
[134] IETF における URI/IRI への関心の低下のためか完成まで数年を要しました。 その間 WHATWG で URL Standard が出版されるなど URL を取り巻く状況は大きく変化しており、 そのような動きとの関係が問いただされることもありましたが、 IETF 外での動きは関係ないということなのか、影響を与えられることなく RFC となりました。
[137] example: URL scheme が新たに定義されています。
[138] 前版の「永続的」、「予備」、「歴史的」はそれぞれ別の IANA登録簿となっていましたが、 この改訂により1つの登録簿の「状態」に改められました。更に状態として 「Pending Review」が追加されています。 >>132
[139] 世間での URL scheme と IANA登録簿の乖離が激しくなって久しいですが (というか開設当初からですが...)、今回の改訂でも抜本的な改革は行われなかったようです。
[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
[22] UriSchemes - ESW Wiki http://esw.w3.org/topic/UriSchemes
[20] ちょっとしたメモ - 過剰なURIスキームは有害である http://www.kanzaki.com/memo/2004/02/28-3
[27] URI schemeは、歴史的事情によりURL schemeとも呼ばれます。
URL protocol、URLプロトコル、URL schema、 URLスキーマ、URI schemaなどとも呼ばれますが、それは間違いです。
[29] IANA | URI Schemes http://www.iana.org/assignments/uri-schemes.html
いつのまにか HTML 化されてました。 (名無しさん 2006-06-17 09:01:03 +00:00)
[30]
A prayer to the (demi-)gods of URI - O'Reilly ONJava Blog
(Robert Cooper 著, 2007-07-13 20:41:02 +09:00 版)
http://www.oreillynet.com/onjava/blog/2006/11/a_prayer_to_the_demigods_of_ur.html
[31] IEBlog : Enriching the Web Safely: How to Create Application Protocol Handlers ( 版) http://blogs.msdn.com/ie/archive/2007/07/18/enriching-the-web-safely-how-to-create-application-protocol-handlers.aspx (名無しさん)
[32] Registration timing of new URI schemes (Eran Hammer-Lahav 著, 版) http://lists.w3.org/Archives/Public/uri/2009Aug/0047.html
[33] - App Lookup ( 版) http://applookup.com/
[34] IPhone URL Schemes - akosma wiki ( 版) http://wiki.akosma.com/IPhone_URL_Schemes
[35] URLスキームについて|Enjoy iPhone Life ( 版) http://ameblo.jp/moco-cchi/entry-10811253150.html
[36] [whatwg] Blacklist for regsiterProtocolHandler() ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031220.html
[37] IRC logs: freenode / #whatwg / 20110413 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110413
[38] [whatwg] Blacklist for regsiterProtocolHandler() ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031294.html
[39] New Uniform Resource Identifer Schemes Considered 99% Harmful ( ( 版)) http://infomesh.net/2001/09/urischemes
[40] [whatwg] registerProtocolHandler() whitelist ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032974.html
[42] Web Applications 1.0 r7291 Whitelist another scheme. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7290&to=7291
[43] Web Applications 1.0 r7294 Add ssh and sip to the whitelist. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7293&to=7294
[44] Web Applications 1.0 r7323 Explain why gopher isn't on the list ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7322&to=7323
[45] IRC logs: freenode / #whatwg / 20121124 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121124
[46] IRC logs: freenode / #whatwg / 20121128 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1299
[47] IPhone URL Schemes - akosma wiki ( ( 版)) http://wiki.akosma.com/IPhone_URL_Schemes
[48] IRC logs: freenode / #whatwg / 20130507 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130507
[51] URL Scheme Intro for App Developers – Contrast Tech Support ( ( 版)) http://help.contrast.co/hc/en-us/articles/200865293-URL-Scheme-Intro-for-App-Developers
[52] handleOpenURL: Shared Interapp Communication on iOS ( ( 版)) http://handleopenurl.com/
[53] パラメータ有りiPhoneアプリのURLスキーム一覧 ( (nasimeya 著, 版)) http://nasimeya.blog.fc2.com/blog-entry-820.html
[54] 総計290個以上掲載!iPhoneアプリのURLスキーム一覧 ( (nasimeya 著, 版)) http://nasimeya.blog.fc2.com/blog-entry-157.html
[55] Zwapp ( ( 版)) http://schemes.zwapp.com/?page=218
[56] iPhoneアプリのURLスキーム @ ウィキ - ページ一覧 ( ( 版)) http://www18.atwiki.jp/iphone-urlscheme/list
[57] Windows Phone 8 用の組み込みアプリを起動するための URI スキーム ( ( 版)) http://msdn.microsoft.com/ja-jp/library/windowsphone/develop/jj662937(v=vs.105).aspx
[58] URI schemes for launching built-in apps for Windows Phone 8 ( ( 版)) http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662937(v=vs.105).aspx
[59] Reserved file and URI associations for Windows Phone 8 ( ( 版)) http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207065%28v=vs.105%29.aspx#BKMK_Reservedprotocolnames
[60] URI Association Schemes List - Nokia Developer Wiki ( (Nokia 著, 版)) http://developer.nokia.com/community/wiki/URI_Association_Schemes_List
[61] 用途のわからないURLスキームを解説 « 当サイトは reliphone.jp に移転しました。 ( ( 版)) https://reliphone.wordpress.com/2014/01/04/unknownurlschemes/
[63] iOS App Programming Guide: Advanced App Tricks ( ( 版)) https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/AdvancedAppTricks/AdvancedAppTricks.html#//apple_ref/doc/uid/TP40007072-CH7-SW50
[110] [7100超]iPhone URLスキーム -The theoryの戯言[毎週日曜更新] ( 版) http://www.geocities.jp/thetheorier/iphone_URLscheme.html
Scheme matching in the Android framework is case-sensitive, unlike the RFC. As a result, you should always specify schemes using lowercase letters.
Scheme (protocol) access may be provided by more than one backend. In case the default backend is buggy or simply not working in a specific case it might be worth trying an alternative implementation. Alternative backends can be selected by prefixing the scheme with the name of the alternative backend e.g. ncftp+ftp:// and are mentioned below the scheme’s syntax summary.
Bazaar plugin adding the ability to create custom short names for URLs. This is similar to the bookmarks plugin, but allows a slightly more flexible approach.
This gives the ability to create a shortened version of the start of a URL. For example, if it is desirable to retrieve branches stored
on a server with sftp, you could shorten:
bzr branch sftp://my.username@server.com/path/to/bazaar/projects/work/myproj
to:
bzr branch serv:work/myproj
Any scheme starting with the letters "U" and "R", in particular if it
attaches any of the meanings "uniform", "universal" or "unifying" to
the first letter, is going to cause intense debate, and generate much
heat (but maybe little light).
Any such proposal should either make sure that there is a large
consensus behind it that it will be the only scheme of its type, or
pick another name.
Avoid using names that are either very general purpose or associated
in the community with some other application or protocol. Avoid
scheme names that are overly general or grandiose in scope (e.g.,
that allude to their "universal" or "standard" nature when the
described namespace is not.)
(In
the unfortunate case that there are multiple, different uses of
the same scheme name, the IESG may approve a request to modify an
existing entry to note the separate use.)
[144] 68406 – (protozilla) W3C CUAP: Allow registration of new URI schemes ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=68406
[145] SchemesExtension - Mercurial ( 版) https://mercurial.selenic.com/wiki/SchemesExtension
This project was made as a "proof of concept" demonstration of how to detect apps installed on an iOS device, from early 2011. Since then, it has been used extensively in many apps, to the point where Apple made the decision to ban the excessive use of -canOpenURL:, the method which iHasApp relies upon to determine app installation. As a result, using a list of URL schemes for app detection is no longer a viable method.
[147] Zwapp ( 版) http://zwapp-blog.tumblr.com/
Only 27% support URL Schemes (inter-app communication);
18% of URL Schemes are for the Facebook iOS SDK;
[149] A List of iOS URL Schemes - The Joy of Hack (Aijaz Ansari 著, 版) http://aijazansari.com/2013/07/16/a-list-of-url-schemes/
[156] [rfc-i] BCP 35 and BCP 115 and Auth48 and clerical errors ( 版) https://www.rfc-editor.org/pipermail/rfc-interest/2015-April/008855.html
[157] Reference RFC 7595 instead of RFC 4395 · whatwg/html@ce7112b ( 版) https://github.com/whatwg/html/commit/ce7112b2a2fd73f0fbe906dc45679333717e9a0f
[159] Fix #101: always strip U+0009, U+000A, and U+000D · whatwg/url@7b40216 ( 版) https://github.com/whatwg/url/commit/7b40216f809c7fe3c9a1680b5c1b06a771c9ebd8
iOS5.0以降、Android OS 4.0以降は全部小文字でなければダメ
URLスキームの仕様というよりはブラウザの仕様(*3)により、[○○○://]の○の部分が勝手に小文字に変換されてしまいます。
例えば[<a href="MishukuLand://">]とHTMLに記述した場合、プラウザでは[<a href="mishukuland://">]となってしまいます。何が問題かといいますと、アプリ側では大文字小文字の判別を行っているため、アプリを開くことができなくなってしまいます。
ただしiOS9までのようにprefs:rootでは一切反応してくれず、Prefs:rootとPを大文字にしないと反応しないという変更がされています。
[185] Editorial: give URL syntax components their own terms (annevk著, ) https://github.com/whatwg/url/commit/451696e4297c4c676fae21dbc926aeafb2477e6c
[186] Adding algorithm "Does scheme-part match another scheme-part?" (#136) (Sun77789著, ) https://github.com/w3c/webappsec-csp/commit/cf6dc08055b3b824623187eb56d35e7c242f2296
[192] Can't get gmail for android to open a custom URL scheme, or an intent:// URL - Stack Overflow ( ()) http://stackoverflow.com/questions/38778618/cant-get-gmail-for-android-to-open-a-custom-url-scheme-or-an-intent-url
The :url capability URI MUST contain a "scheme" argument assigned a
comma-separated list of scheme names indicating which schemes the
NETCONF peer supports. For example:
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file