为什么冒号“:"在 Uri 中传递给 Uri.MakeRelativeUri 会导致异常吗? [英] why does colon ":" in Uri passed to Uri.MakeRelativeUri cause an exception?

问题描述

以下代码行给出了一个例外.这是框架中的错误吗?如果不是，我可以采取什么方法?

The following line of code gives an exception. Is this a bug in the framework? If not what approach could I take instead?

这似乎是导致问题的:"(冒号)，但是我确实看到这样的 URI 在生产网站上工作正常(即在现实世界中似乎是有效的 URI)

It seems to be the ":" (colon) that causes in the issue, however I do see such a URI working on production websites ok (i.e. seems to be a valid URI in the real world)

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xx:yy"));
// gives => System.UriFormatException: A relative URI cannot be created because the 
// 'uriString' parameter represents an absolute URI

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xxyy"));
// this works - removed the colon between the xx and yy

附注.鉴于上述情况，我可以特别问一下，我可以使用什么 .NET 类/方法(注意我正在解析来自网络的 HTML 页面)来获取 (a) 页面 URI 和 (b) 来自 HTML 的相对字符串HREF 参数 [例如在这种情况下会是/xx:yy"]并返回可用于寻址该资源的有效URI?

PS. Specifically can I ask given the above is the case, what .NET class/method could I use (noting I am parsing a HTML page from the web) to take (a) the page URI and (b) the relative string from a HTML HREF argument [e.g. would have been "/xx:yy" in this case] and return the valid URI that could be used to address that resource?

换句话说，我如何模仿浏览器的行为，该浏览器将 HREF 和页面 URI 转换为在您单击该资源时生成用于转到该资源的 URI.

In other words how do I mimic the behavior of a browser that translates the HREF and the page URI to produce the URI it uses to go to that resource when you click on it.

推荐答案

我认为这是一个错误.

RFC1738 规定 :(在其他字符中)可能被保留用于方案中的特殊含义.但是 http 方案并没有在路径部分保留它

RFC1738 says that : (amongst other characters) may be reserved for special meaning within a scheme. However the http scheme does not reserve it in the path part

Within the <path> and <searchpart> components, "/", ";", "?" are reserved.

(不是:.)

hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

所以，http://test.com/xx:yy 是一个有效的 URI.较新的 RFC3968 同意:

So, http://test.com/xx:yy is a valid URI. The newer RFC3968 agrees:

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

当然，相对于 http://test.com/asdf，结果 xx:yy 将是绝对 URI 而不是有效的相对 URI:

However of course, relativised against http://test.com/asdf, the resultant xx:yy would be an absolute URI and not a valid relative URI:

path-noscheme = segment-nz-nc *( "/" segment )
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                ; non-zero-length segment without any colon ":"

所以 MakeRelativeUri 报告存在问题是正确的，但实际上它应该通过对 : 进行编码来自动修复它在相对 URI 的第一段中有效的 %3A 的绝对 URI 中有效.

So MakeRelativeUri is kind of right to report there's a problem, but really it should be fixing it automatically by encoding the : that is valid in an absolute URI to a %3A that is valid in the first segment of a relative URI.

我通常会尽量避免使用 MakeRelativeUri 以支持根相对 URI，它们更容易提取并且没有这个问题(/xx:yy 是好的).

I would generally try to avoid MakeRelativeUri in favour of root-relative URIs, which are easier to extract and don't have this problem (/xx:yy is OK).

这篇关于为什么冒号“:"在 Uri 中传递给 Uri.MakeRelativeUri 会导致异常吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！