Server.UrlEncodeとHttpUtility.UrlEncode
質問
Server.UrlEncodeとHttpUtility.UrlEncodeに違いはありますか?
解決
HttpServerUtility.UrlEncode
は、内部で HttpUtility.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 である必要があります-これは本当にわかりにくいです。エンコード:
- " " ==> "%20"
- " 100%true" ==> " 100 %% 20true" (OK、あなたのURLは今壊れています)
- "テストA.aspx#anchor B" ==> " test%20A.aspx #anchor%20B "
- "テストA.aspx?hmm#anchor B" ==> " test%20A.aspx?hmm #anchor B " (以前のエスケープシーケンスとの違いに注意してください!)
また、Webサイトからクライアントへの信頼性の高いHTTP送信のために、URLストリングのパス部分をエンコードする非常に具体的なMSDNドキュメントがあります。 -実際にそれが何をするのか説明せずにUziで足を撃つ可能性は低くなります...
要するに、 Uri.EscapeDataString 。
最初に質問されてからほぼ9年が経ち、.NET Coreと.NET Standardの世界では、URLエンコードの最も一般的なオプションは WebUtility.UrlEncode ( System.Net
の下)および Uri.EscapeDataString 。ここと他の場所で最も人気のある答えから判断すると、 Uri.EscapeDataString が望ましいようです。しかし、それですか?違いを理解するためにいくつかの分析を行ったところ、次のように思いつきました。
-
WebUtility.UrlEncode
は、スペースを+
としてエンコードします。Uri.EscapeDataString
は、%20
としてエンコードします。 -
Uri.EscapeDataString
パーセントエンコード!
、(
、)
、および* コード>;
WebUtility.UrlEncode
はサポートしていません。 -
WebUtility.UrlEncode
percent-encodes〜
;Uri.EscapeDataString
はサポートしていません。 -
Uri.EscapeDataString
は、65,520文字を超える文字列に対してUriFormatException
をスローします。WebUtility.UrlEncode
はサポートしていません。 (特にURLエンコードされたフォームデータを処理する場合に、考えられるよりも一般的な問題 。) -
Uri.EscapeDataString
はUriFormatException をスローしますrel = "noreferrer">高サロゲート文字; WebUtility.UrlEncode
はサポートしていません。 (これはUTF-16のことで、おそらくあまり一般的ではありません。)
URLエンコードの目的で、文字は次の3つのカテゴリのいずれかに適合します。未予約(URLの合法)。予約済み(合法ですが、特別な意味があるため、エンコードする必要があるかもしれません);その他すべて(常にエンコードする必要があります)。
RFC によると、予約文字は次のとおりです。: /?#[] @!$& '()* +、; =
および予約されていない文字は英数字で、 -._〜
評決
Uri.EscapeDataString は、その使命を明確に定義しています。すべての予約文字と不正文字を%エンコードします。 WebUtility.UrlEncode は、定義と実装の両方でより曖昧です。奇妙なことに、いくつかの予約文字をエンコードしますが、他の文字はエンコードしません(括弧ではなく、かっこではないのはなぜですか?)、そして見知らぬ人はまだ無邪気に予約されていない〜
文字をエンコードします。
したがって、私は一般的なアドバイスに同意します。可能な場合は Uri.EscapeDataString を使用し、 /
や?
などの予約文字はエンコードされます。特にURLエンコードされたフォームコンテンツで潜在的に大きな文字列を処理する必要がある場合は、 WebUtility.UrlEncode にフォールバックしてその癖を受け入れるか、そうでなければ問題を回避する必要があります。
編集:すべてを修正するために試行しました Url.Encode
、 Url.EncodeIllegalCharacters
、および Url.Decode
静的メソッド。これらはコアパッケージ(これは非常に小さく、すべてのHTTPを含むわけではありません)にあります。またはソースからそれらを自由にリッピングしてください。これらについてのコメント/フィードバックを歓迎します。
どの文字が異なる方法でエンコードされているかを発見するために使用したコードは次のとおりです。
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(<*>quot;{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");
これらの方法のいずれも使用しないでください。 Microsoftのアンチクロスサイトスクリプティングライブラリには、 HttpUtility.UrlEncode
および HttpUtility.HtmlEncode
。どちらも標準に準拠しており、より安全です。ボーナスとして、 JavaScriptEncode
メソッドも取得できます。
Server.UrlEncode()は、クラシックASPとの後方互換性を提供するためにあります。
Server.UrlEncode(str);
と同等:
HttpUtility.UrlEncode(str, Response.ContentEncoding);
同じ、 Server.UrlEncode()
は HttpUtility.UrlEncode()