问题领域
我需要定义特定路径段是否对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
不是因为 non-escaped ?
。为了更正上面的例子,路径段应该写成/fo%3Fo
。
然而,规范只定义到达服务器的 URI 的有效性(想想:在 URL 栏中输入)。
我真正需要验证的是未转义的路径段是否有效。继续上面的例子,/fo?o
这将是一个有效的资源,?
就像你在 unescaping 时得到的一样%3F
。
这也意味着 URLhttp://foo.com/first/sec%2fond
将解析为两个未转义的路径段,/first
和/sec/ond
, 后者不仅必须被视为单个段而不是两个单独的段,而且在语法上也是有效的(作为未转义的路径段)。
问题
- 我是否正确理解规范?
- 任何人都可以为未转义的路径段建议一个 Java 验证器吗?
- 任何人都可以提出一个不平凡的失败案例吗?
- U + 00FF以上的字符怎么样,不能在路径段中使用吗?我认为它们是受支持的,至少在域名方面是这样。
编辑:正如迈克正确指出的那样,RFC3986 已经过时了 RFC2396。无论如何,我相信新的 RFC 比旧的 RFC 处理更多的案例(并且不会使某些路径段变得非法),因此同样的问题也适用。