2

问题领域

我需要定义特定路径段是否对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 处理更多的案例（并且不会使某些路径段变得非法），因此同样的问题也适用。

4

2 回答 2

2

我会以与您相同的方式解释规范；也就是说，sec%2Fond是一个单一的路径段。（但是——任何使用这样的段创建 URI 的人都应该受到严厉的惩罚！）

您正在努力解决的问题是无法逃脱的过程是有损的；您不能从转义的 URI 到未转义的 URIString并返回到原始的转义 URI。没有办法解决这个问题。在任何“有用的”处理丢弃该关键信息之前，您必须掌握转义的 URI。

您可以阅读 §2.1 了解有关处理非 ASCII 字符的详细信息，但我的理解是 RFC 2396 中的转义规则适用于URI 字符串经过字符编码后的八位字节字符串（字节）。如何进行字符编码可以由方案指定；没有通用的方法。

于 2011-03-30T17:10:48.933 回答
2

因此，例如， /foo 是一个有效的路径段，但 /fo?o 不是因为没有转义？为了更正上面的例子，路径段应该写成/fo%3Fo。

正确的

这也意味着 URL http://foo.com/first/sec%2fond将解析为两个未转义的路径段，/first 和 /sec/ond，并且后者不仅必须被视为单个段而不是两个独立的，但在语法上也是有效的（作为未转义的路径段）。

正确的。但是有很多实现会出错。

U + 00FF以上的字符怎么样，不能在路径段中使用吗？我认为它们是受支持的，至少在域名方面是这样。

URI 转义（% hex hex）编码字节。不是代码点。您需要知道 URL 的编码。例如，如果编码为 UTF-8，则代码点 U+1234 编码为%E1%88%B4.

域名中不允许使用百分比转义。有关国际域名，请参阅RFC 3492。

于 2011-03-30T17:11:40.757 回答