相対ハッシュバンURLの互換性のためのUri.IsWellFormedUriString

Question

次のテストで、なぜ最後のものが失敗するのですか？ Uriもし

[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)); 
    } 

はなぜ相対バージョンでは、IsWellFormedUriStringの絶対バージョンでHashbangsを認識しますか？私は何が欠けていますか？

注：Thisは役に立ちません。

Answer 1

ハッシュバンがURI Schemeの一部ではないため、これが期待どおりに動作しない理由があります。この方法では、URI形式の階層部分が必要です。ハッシュマーク（およびその後のハッシュバーン）は、相対的な絶対パスが決定される階層部分のメンバーではありません。絶対URIの例として

<>必須部分である
[]オプションの一部である

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

。私は間違っていない場合、クエリは、ここで

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

フラグメントおよびハッシュマークを含む、無視されるだけでなく、あなたのためにいくつかのより多くの情報です。これは

が文字列 文字列でURIを構築しようとすることによって良好に形成され、文字列がさらにエスケープを必要としないことを保証するかどうかを示しUri.IsWellFormedUriString()方法を説明するすべてのMSDNからのものです。

備考：デフォルトでは

、文字列がRFC 2396とRFC 2732に従って整形式と見なされます。国際リソース識別子（IRI）または国際化ドメイン名（IDN）解析が有効になっている場合、文字列はRFC 3986およびRFC 3987に従って整形式と見なされます。

http://www.contoso.com/path???/file名
文字列が正しくエスケープされていません。

次のいずれかの条件は以下の

を発生した場合、文字列は、メソッドがfalseを返すように引き起こして、不完全に形成され考えられているが、いくつかの失敗例であり、 。

c：¥directory¥filename
文字列は、暗黙のファイルUriを表す絶対Uriです。

file：// c：/ directory/filename
文字列は、パスの前にスラッシュがない絶対URIです。

ます。http：\ホスト/パス/ファイル
文字列は、前方が

www.contoso.com/path/file文字列は、階層絶対URIを表しスラッシュとして、彼らが扱われていてもエスケープされていないバックスラッシュが含まれています"：//"を含んでいません