Uri.IsWellFormedUriString用于相对Hashbang网址的兼容性

在下面的测试中,为什么(仅)最后一个失败?

    [Fact]
    public void IsWellFormedUriString_AbsolutNonHashTagUri_ReturnsTrue()
    {
        Assert.True(Uri.IsWellFormedUriString("http://www.RegularSite.org/Home", UriKind.Absolute));
    }

    [Fact]
    public void IsWellFormedUriString_RelativeNonHashTagUri_ReturnsTrue()
    {
        Assert.True(Uri.IsWellFormedUriString("Home", UriKind.Relative));
    }

    [Fact]
    public void IsWellFormedUriString_AbsolutHashTagUri_ReturnsTrue()
    {
        Assert.True(Uri.IsWellFormedUriString("http://www.w3.org/#!Home", UriKind.Absolute));
    }

    [Fact]
    public void IsWellFormedUriString_RelativeHashTagUri_ReturnsTrue()
    {
        // Fails!
        Assert.True(Uri.IsWellFormedUriString("#!Home", UriKind.Relative));
    }

如果Uri在绝对版本的IsWellFormedUriString识别Hashbangs,为什么不在Relative版本中? 我错过了什么?

注意:这没有帮助。


这不是你所期望的,因为hashbang不是URI Scheme的一部分。 该方法期望URI格式的分层部分和散列标记(以及随后的hashbang)不是从中确定相对路径和绝对路径的分层部分的成员。

<>是必需的部分
[]是可选部分

<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]

作为绝对URI的例子; 如果我没有弄错,查询将被忽略,其中包括碎片和散列标记

http://domain.com/path/to/something/?query=1#fragment

这里还有一些关于你的更多信息。 这些都来自描述Uri.IsWellFormedUriString()方法的MSDN

通过尝试使用字符串构造URI来确定字符串是否格式正确,并确保字符串不需要进一步转义。

备注:

默认情况下,根据RFC 2396和RFC 2732将字符串视为格式良好。如果启用国际资源标识符(IRI)或国际化域名(IDN)解析,则根据RFC 3986将字符串视为良好格式,并且RFC 3987。

如果出现以下任何情况,字符串被认为形成不良,导致该方法返回false

以下是一些失败的例子:

http://www.contoso.com/path???/文件名
该字符串未正确转义。

C:目录文件名
该字符串是一个绝对的Uri,代表一个隐式文件Uri。

文件:// C:/目录/文件名
该字符串是绝对URI,在路径前缺少斜线。

HTTP:主机/路径/文件
该字符串包含未转义的反斜杠,即使它们将被视为正斜杠

www.contoso.com/path/file
该字符串表示层次绝对的Uri,不包含“://”

链接地址: http://www.djcxy.com/p/11097.html

上一篇: Uri.IsWellFormedUriString for relative Hashbang urls compatibility

下一篇: eglSwapBuffers is erratic/slow