[14] かつての URL の仕様では reserved / unreserved の違いがありました。 unreserved は、パーセント符号化してもしなくても同じ意味である文字でした。
結局、
rfc1738.unreserved = <[A-Za-z0-9$_.+!*'(),-]>一方、 RFC2396 では
で、 $,
+,
,
が消えて、 ~
が追加されました。
削除されたものは reserved
へ移動、追加されたものは
national からの編入です。
[10] RFC 2396 と RFC 3986 と比べると5文字 sub-delims に移動しています。
結局、
随分おおざっぱな定義ですが、 pchar (>>3) 参照。
[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 の制約が適用されるのか不明です。
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 がその非予約文字の出現が許されない文脈で使われるのでない限りするべきではありません。
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.
チルダ ~
文字を「非予約」集合に加えました。
この文字は転写し辛い鍵盤があるにもかかわらずインターネットで広く用いられているからです。
~ が追加されたのは、 <http://foo.example/~user/> のような使用が非常に広く行われており、追認せざるを得なかったからです。本来はこの文字は national に分類されていたように存在しない符号化文字集合が多い (その最たる例は日本のシフトJIS。厳密にはシフト JIS で生チルダを含む URI は書けません。) ですし、容易に入力できない鍵盤・入力方式も少なくありませ。 (日本では WWW の普及後雑誌や掲示板などで ~ の入力方法についての記事や質問が激増しました。)[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>