回答:
HttpServerUtility.UrlEncodeHttpUtility.UrlEncode内部的に使用します。特に違いはありません。存在する理由Server.UrlEncodeは、クラシックASPとの互換性です。
以前にこれらのメソッドで大きな頭痛の種があったので、のバリアントを避けUrlEncode、代わりに使用することをお勧めしますUri.EscapeDataString -少なくとも1つは包括的な動作を持っています。
どれどれ...
HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
//standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
// want, since you still need to
// escape special characters yourself
しかし、私の個人的なお気に入りはHttpUtility.UrlPathEncodeでなければなりません -このことは本当に理解できません。それはエンコードします：
また、MSDNのドキュメントには、「Webサーバーからクライアントへの信頼性の高いHTTP送信のためにURL文字列のパス部分をエンコードする」という素敵なドキュメントもあります。-実際にそれが何をするか説明せずに。Uziで足を撃つ可能性は低くなります...
つまり、Uri.EscapeDataStringに固執します。
?、誰がエンコードされ、セパレータとして機能するのですか？スペースについて：どちらの場合もスペースはハッシュ内にあるため、クエリフラグメントの有無は関係ありません。そして最後に、％を含む2番目の例のようにUriを破損することは許されません。このUrlPathEncodeメソッドは単純なものなので、決して使用しないでください。
これが最初に要求されてから約9年早送りします。.NETCoreと.NET Standardの世界では、URLエンコードに使用できる最も一般的なオプションはWebUtility.UrlEncode（下System.Net）とUri.EscapeDataStringです。ここや他の場所で最も人気のある答えから判断すると、Uri.EscapeDataStringが望ましいようです。しかし、そうですか？私は違いを理解するためにいくつかの分析を行いました、そしてここに私が思いついたものがあります：
WebUtility.UrlEncodeスペースをとしてエンコードし+ます。Uri.EscapeDataStringとしてエンコードします%20。Uri.EscapeDataStringパーセント符号化!、(、)、および*、WebUtility.UrlEncodeではない。WebUtility.UrlEncodeパーセントエンコード~; Uri.EscapeDataStringではない。Uri.EscapeDataStringUriFormatException65,520文字を超える文字列に対してをスローします。WebUtility.UrlEncodeではない。（特にURLエンコードされたフォームデータを処理する場合に、考えられるよりも一般的な問題です。）Uri.EscapeDataString高代理文字に a UriFormatExceptionをスローします。ではない。（これはUTF-16のことで、おそらくそれほど一般的ではありません。）WebUtility.UrlEncodeURLエンコードの目的で、文字は次の3つのカテゴリのいずれかに適合します。予約（法的ではなく、あなたがして、特別な意味を持っているかもしれない、それをエンコードしたいです）。その他すべて（常にエンコードする必要があります）。
RFCによれば、予約文字は次のとおりです。:/?#[]@!$&'()*+,;=
また、予約されていない文字は英数字であり、 -._~
Uri.EscapeDataStringはその使命を明確に定義しています：すべての予約済みおよび不正な文字を％エンコードします。WebUtility.UrlEncodeは、定義と実装の両方であいまいです。奇妙なことに、それはいくつかの予約文字をエンコードし、他の文字はエンコードしません（なぜ括弧とブラケットではないのですか??）~。
したがって、私は一般的なアドバイスに同意します- 可能な場合はUri.EscapeDataStringを使用し、予約された文字のような/および?がエンコードされることを理解します。潜在的に大きな文字列、特にURLエンコードされたフォームコンテンツを処理する必要がある場合は、WebUtility.UrlEncodeにフォールバックしてその癖を受け入れるか、そうでなければ問題を回避する必要があります。
編集：、、および静的メソッドを介して、Flurlで前述したすべての癖を修正しようとしました。これらはコアパッケージ（小さなもので、すべてのHTTP 要素は含まれていません）に含まれているか、ソースから自由にリッピングできます。これらについてのコメントやフィードバックがあれば歓迎します。Url.EncodeUrl.EncodeIllegalCharactersUrl.Decode
これは、どの文字が異なってエンコードされているかを見つけるために使用したコードです。
var diffs =
from i in Enumerable.Range(0, char.MaxValue + 1)
let c = (char)i
where !char.IsHighSurrogate(c)
let diff = new {
Original = c,
UrlEncode = WebUtility.UrlEncode(c.ToString()),
EscapeDataString = Uri.EscapeDataString(c.ToString()),
}
where diff.UrlEncode != diff.EscapeDataString
select diff;
foreach (var diff in diffs)
Console.WriteLine($"{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");
おそらくこれらの方法のいずれかを使用するべきではないことに注意してください。MicrosoftのAnti-Cross Site Scripting Libraryには、標準に準拠した、より安全な代替品が含まれHttpUtility.UrlEncodeてHttpUtility.HtmlEncodeいます。おまけとして、JavaScriptEncodeメソッドも取得できます。