unreserved

unreserved

[14] かつての URL の仕様では reserved / unreserved の違いがありました。 unreserved は、パーセント符号化してもしなくても同じ意味である文字でした。

[15] 現在の URL Standard には reserved / unreserved の区別はありません。

目次

  1. 定義
  2. HTTP での定義
  3. IRI
  4. bidi 文字
  5. 仕様書から
    1. RFC 2396
      1. 2.3. Unreserved Characters
      2. G.2 (抜粋)
  6. RFC の部分の License
  7. 関連
  8. メモ

定義#

[1] RFC1738, RFC1808 では:

結局、

一方、 RFC2396 では

で、 $, +, , が消えて、 ~ が追加されました。 削除されたものは reserved へ移動、追加されたものは national からの編入です。

[10] RFC 2396RFC 3986 と比べると5文字 sub-delims に移動しています。

HTTP での定義#

[3] RFC2068 では:

結局、

随分おおざっぱな定義ですが、 pchar (>>3) 参照。

IRI#

[12] RFC 3986 reservedRFC 3987 iunreserved の違いは ucschar です。

bidi 文字#

[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 3987ABNF 構文に合致するもの」のような引用の仕方のものがあり、その場合に >>6 の制約が適用されるのか不明です。

仕様書から#

RFC 2396 #

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 がその非予約文字の出現が許されない文脈で使われるのでない限りするべきではありません。

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.

チルダ ~ 文字を「非予約」集合に加えました。 この文字は転写し辛い鍵盤があるにもかかわらずインターネットで広く用いられているからです。

RFC の部分の License#

RFCのライセンス

関連#

メモ#

[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>