[14] かつての URL の仕様では reserved / unreserved の違いがありました。 unreserved は、パーセント符号化してもしなくても同じ意味である文字でした。
[21] この予約、非予約という概念は非常にわかりにくい上に、 仕様書が改訂されるたびに大きく変更され続けていましたから、 技術者コミュニティーでは十分よく理解されることがなく混乱の元になっていました。
[22] プログラミング言語のライブラリーなどはそうそう頻繁に作り直されるものではありませんから、 今でも当時の古い概念を基に作られていることがあります。それは過去のどれかの仕様書に基づくものかもしれませんし、 開発者の誤解に基づく仕様書とは異なるものであることもままあります。
[23] また、古い時代に書かれた解説はもちろんのこと、最近書かれたものであっても著者が不勉強な低品質な解説の類には、 過去の仕様書に基づく予約、非予約やそれを曲解した誤った予約、非予約の説明がなされていることがあります。
本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
結局、
rfc1738.unreserved = <[A-Za-z0-9$_.+!*'(),-]>[26] RFC1738 及び RFC1808 の定義するところでは:
すなわち、
rfc1738.uchar = <[A-Za-z0-9$_.+!*'(),-]> / escape[27] RFC2068 でも >>26 と同じ定義ですが、 unreserved の定義上、 rffc2068.uchar = (OCTET - (%x00-20 / <"> / "#" / "%" / "<" / ">")) / escape です。 (pchar (>>3) 参照。)
結局、
随分おおざっぱな定義ですが、 pchar (>>3) 参照。
[2] ~ が追加されたのは、 http://foo.example/~user/ のような使用が非常に広く行われており、追認せざるを得なかったからです。本来はこの文字は national に分類されていたように存在しない符号化文字集合が多い (その最たる例は日本のシフトJIS。厳密にはシフト JIS で生チルダを含む URI は書けません。) ですし、容易に入力できない鍵盤・入力方式も少なくありませ。 (日本では WWW の普及後雑誌や掲示板などで ~ の入力方法についての記事や質問が激増しました。)
で、 $,
+,
,
が消えて、 ~
が追加されました。
削除されたものは reserved
へ移動、追加されたものは
national からの編入です。
2.3. Unreserved Characters#✎
Data characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include upper and lower case letters, decimal digits, and a limited set of punctuation marks and symbols.
URI で認められているが予約目的を持たないデータ文字を非予約と呼びます。 これには大文字と小文字, 10進数字, 嗅ぎられた句読点印・記号の集合を含みます。
- unreserved = alphanum | mark
- mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear.
非予約文字は URI の意味を変えることなく escape することが出来ますが、 このことは URI がその非予約文字の出現が許されない文脈で使われるのでない限りするべきではありません。
[20] G.2 (抜粋)
The tilde "~" character was added to those in the "unreserved" set, since it is extensively used on the Internet in spite of the difficulty to transcribe it with some keyboards.
チルダ
~文字を「非予約」集合に加えました。 この文字は転写し辛い鍵盤があるにもかかわらずインターネットで広く用いられているからです。
[10] RFC 2396 と RFC 3986 と比べると5文字 sub-delims に移動しています。
[12] RFC 3986 reserved と RFC 3987 iunreserved
の違いは ucschar です。
[6] IRI (RFC 3987) では bidi の表示の制御に関わる文字
LRM, RLM, LRE,
RLE, LRO, RLO,
PDF
(U+200E, U+200F,
U+202A-U+202E)
の利用が禁じられています。しかし、この制限はなぜか ABNF
に反映されておらず、未予約文字であるかのようにも見えます。
(RFC 3987 4章の本文で禁止されています。)
[7] IRI を参照する仕様の中には、「RFC 3987 の ABNF 構文に合致するもの」のような引用の仕方のものがあり、その場合に >>6 の制約が適用されるのか不明です。
[24] 現在の URL の仕様書である URL Standard には予約、非予約に相当する概念はありません。
[25] 強いて言うならパーセント符号化集合が近い位置にある概念ですが、 混乱した予約、非予約の概念を解体したもので、 用語として直接的機械的に置換できるものではありません。
[4]
RFC 3986 まで一貫して . は非予約文字に分類されてきました。
ということは . と %2E は (許されている場所では) 常に等価です。
ところで、 . または .. だけの path segment は特別な意味を持ちます。
(その扱いの詳細は RFC 3986 で明確化されています。)
従って、 path segment で特別な意味を持たない .
や ..
を使おうと思っても、その方法は存在しないということになります。
(名無しさん)
[5]
>>4 はファイル・システムでは普通 (ファイル・システムでも . や .. を特別な意味に割り当てていることが多いので)
問題になりませんが、ファイル・システム以外のデータベース (たとえば任意の WikiName が使える wiki)
を URI path に写像する場合に問題となり得ます。
回避策としては、 URI で特別な意味を持つのが .
や ..
だけで構成される
path segment であるということから、それ以外の文字を混ぜてやれば、というのが1つ考えられます。
URI scheme の定義に依存しますが、
空の引数があると仮定した .; や ..;
のような path segment を使うのが一番ましな設計かもしれません。
(名無しさん)
[16] R2RML: RDB to RDF Mapping Language ( ()) https://www.w3.org/TR/2012/REC-r2rml-20120927/#dfn-iri-safe