問題領域
特定のパス セグメントがRFC2396に対して有効かどうかを定義する必要があります。仕様は次のように述べています。
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
たとえば、/foo
は有効なパス セグメントですが、/fo?o
エスケープされていないためではありません?
。上記の例を修正するには、パス セグメントを次のように記述し/fo%3Fo
ます。
ただし、仕様では、サーバーに到着する URI (URL バーに入力されたと考えてください) の有効性のみを定義しています。
実際に検証する必要があるのは、エスケープされていないパス セグメントが有効かどうかです。上記の例を続けると、エスケープを解除したときに得られるものと/fo?o
同様に、有効なリソースになります。?
%3F
これはまた、URLhttp://foo.com/first/sec%2fond
が 2 つのエスケープされていないパス セグメント/first
およびに解決されることを意味し、後者は 2 つの別々のセグメントではなく1 つ/sec/ond
のセグメントとして扱われる必要があるだけでなく、構文的にも有効です (エスケープされていないパス セグメントとして)。
質問
- 仕様を正しく理解していますか?
- エスケープされていないパスセグメントのJavaバリデーターを提案できる人はいますか?
- 誰かが自明ではない失敗例を提案できますか?
- U+00FF より上の文字はパス セグメントで使用できませんか? 少なくともドメイン名ではサポートされていると思いました。
編集: マイクが正しく指摘したように、RFC3986 は RFC2396 を廃止しました。とにかく、新しい RFC は古いものよりも多くのケースを処理する (そして、一部のパス セグメントを不当にしない) と信じているため、同じ質問が適用されます。