为什么Uri在不同的scheme下表现不同？

Question

在回答另一个问题时，我正在使用Uri类进行探索，发现了一些让我感到奇怪的东西：

考虑这两个Uri：

var u1 = new Uri("http://a.b:33/abc%2fdef/c?d=f");
var u2 = new Uri("foobar://a.b:33/abc%2fdef/c?d=f");

他们之间的不同只在于他们的方案。提供的标识符的所有其他元素都是相同的。

那么，为什么当我转储这些Uri实例的“Segments”属性时，我会看到对于“u1”的以下输出：

/ abc/ def/ c

但对于“u2”却有不同的输出？

/ abc%2fdef/ c

为什么不同的方案具有不同的解析行为？

- spender

Answer 1

Uri类针对不同的URI方案使用不同的解析器。例如，对于http和https URI，它使用HttpStyleUriParser，而对于ftp URI，它使用FtpStyleUriParser等等。未知方案的URI将由GenericUriParser解析。您可以使用UriParser.Register方法注册新的方案。

UriParser.Register(new HttpStyleParser(), "foobar", 33);

- dtb

---

好的回答。+1。你能告诉我是什么要求使得这些“专业”的方案非通用吗？我原本以为URI就是URI，人们可以合理地期望它们被同等对待。 - spender

所有的URI都符合RFC 3986，但并不是所有的方案都利用了所有的特性，或者它们对URI语法施加了更多的限制。.NET Framework中的UriParser工具在内部实现上相当丑陋；我建议你使用你喜欢的反编译器自己看一下。 - dtb

谢谢。我正在查看RFC1738第3.3节，它并没有明确表明转义斜杠是否可接受。Apache中AllowEncodedSlashes指令的存在表明他们认为转义斜杠可能被考虑。这对我来说意味着我看到了过度谨慎的非转义和Uri行为不正确，但也许我读错了。 - spender

首先，RFC 1738已经过时了。http/https URI方案的最新规范在draft-ietf-httpbis-p1-messaging中。 （该草案在撰写本文时是稳定的，但尚未作为RFC发布。从技术上讲，RFC 2616是当前的规范。）其次，你是正确的。路径段中的%2F不应解码为/。但是，HttpStyleUriParser可能会出于与Apache中AllowEncodedSlashes指令相同的原因执行此操作。 - dtb

总的来说，.NET Framework 中似乎有多个版本的 URI 解析器（至少有 3 个），并且它们似乎支持不同 URI 方案的各种“怪癖”。如果您需要符合标准的 URI 解析器，您应该在 MSDN 上查找提示或自定义自己的 UriParser。更新： 显然，在您的 App.config 中，对于 http 和 https URI，您可以设置一个 DontUnescapePathDotsAndSlashes 选项。 - dtb