Server.UrlEncode vs. HttpUtility.UrlEncode

Gibt es einen Unterschied zwischen Server.UrlEncode und HttpUtility.UrlEncode?

HttpServerUtility.UrlEncodewird HttpUtility.UrlEncodeintern verwendet. Es gibt keinen spezifischen Unterschied. Der Grund für die Existenz Server.UrlEncodeist die Kompatibilität mit klassischem ASP.

Ich hatte vorher erhebliche Kopfschmerzen mit diesen Methoden. Ich empfehle Ihnen , jede Variante zu vermeidenUrlEncode und stattdessen zu verwendenUri.EscapeDataString - zumindest hat diese ein verständliches Verhalten.

Mal schauen...

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

Aber mein persönlicher Favorit muss HttpUtility.UrlPathEncode sein - dieses Ding ist wirklich unverständlich. Es codiert:

• ==>% 20
• "100% true" ==> "100 %% 20true" (ok, deine URL ist jetzt kaputt)
• "test A.aspx # anchor B" ==> "test% 20A.aspx # anchor% 20B "
• "test A.aspx? hmm # anchor B" ==> "test% 20A.aspx? hmm #anchor B " ( beachten Sie den Unterschied zur vorherigen Escape-Sequenz! )

Es enthält auch die sehr spezifische MSDN-Dokumentation "Codiert den Pfadabschnitt einer URL-Zeichenfolge für eine zuverlässige HTTP-Übertragung vom Webserver zu einem Client." - ohne wirklich zu erklären, was es tut. Es ist weniger wahrscheinlich, dass Sie sich mit einem Uzi in den Fuß schießen ...

Kurz gesagt, bleiben Sie bei Uri.EscapeDataString .

Fast 9 Jahre, seit dies zum ersten Mal gefragt wurde, und in der Welt von .NET Core und .NET Standard scheinen WebUtility.UrlEncode (unter System.Net) und Uri.EscapeDataString die häufigsten Optionen für die URL-Codierung zu sein . Nach der beliebtesten Antwort hier und anderswo zu urteilen, scheint Uri.EscapeDataString vorzuziehen zu sein. Aber ist es? Ich habe einige Analysen durchgeführt, um die Unterschiede zu verstehen, und hier ist, was ich mir ausgedacht habe:

• WebUtility.UrlEncodecodiert den Raum als +; Uri.EscapeDataStringcodiert es als %20.
• Uri.EscapeDataStringProzent-codiert !, (, ), und *; WebUtility.UrlEncodenicht.
• WebUtility.UrlEncodeProzent-Codierungen ~; Uri.EscapeDataStringnicht.
• Uri.EscapeDataStringwirft eine UriFormatExceptionZeichenfolge mit mehr als 65.520 Zeichen; WebUtility.UrlEncodenicht. ( Ein häufigeres Problem als Sie vielleicht denken, insbesondere beim Umgang mit URL-codierten Formulardaten .)
• Uri.EscapeDataStringwirft ein UriFormatExceptionauf die hohen Ersatzzeichen ; WebUtility.UrlEncodenicht. (Das ist eine UTF-16-Sache, wahrscheinlich viel seltener.)

Für die URL-Codierung passen Zeichen in eine von drei Kategorien: nicht reserviert (legal in einer URL); reserviert (legal in, hat aber eine besondere Bedeutung, daher möchten Sie es möglicherweise codieren); und alles andere (muss immer verschlüsselt sein).

Laut RFC sind die reservierten Zeichen::/?#[]@!$&'()*+,;=

Und die nicht reservierten Zeichen sind alphanumerisch und -._~

Das Urteil

Uri.EscapeDataString definiert seine Mission klar:% -encode alle reservierten und illegalen Zeichen. WebUtility.UrlEncode ist sowohl in der Definition als auch in der Implementierung mehrdeutig. Seltsamerweise codiert es einige reservierte Zeichen, aber nicht andere (warum Klammern und keine Klammern?), Und seltsamerweise codiert es dieses unschuldig nicht reservierte ~Zeichen.

Daher stimme ich dem beliebten Rat zu: Verwenden Sie nach Möglichkeit Uri.EscapeDataString und verstehen Sie, dass reservierte Zeichen wie /und ?codiert werden. Wenn Sie mit potenziell großen Zeichenfolgen umgehen müssen, insbesondere mit URL-codiertem Formularinhalt, müssen Sie entweder auf WebUtility.UrlEncode zurückgreifen und dessen Macken akzeptieren oder das Problem auf andere Weise umgehen .

EDIT: Ich habe versucht , alle der Macken oben erwähnt zu korrigieren Flurl über die Url.Encode, Url.EncodeIllegalCharactersund Url.Decodestatischen Methoden. Diese befinden sich im Kernpaket (das winzig ist und nicht alle HTTP-Inhalte enthält) oder können von der Quelle kopiert werden. Ich freue mich über Ihre Kommentare / Rückmeldungen zu diesen Themen.

Hier ist der Code, mit dem ich herausgefunden habe, welche Zeichen unterschiedlich codiert sind:

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

Denken Sie daran, dass Sie wahrscheinlich keine dieser Methoden anwenden sollten. Die Anti-Cross Site Scripting Library von Microsoft enthält Ersatz für HttpUtility.UrlEncodeund HttpUtility.HtmlEncodedas ist sowohl standardkonformer als auch sicherer. Als Bonus erhalten Sie auch eine JavaScriptEncodeMethode.

Server.UrlEncode () bietet Abwärtskompatibilität mit Classic ASP.

Server.UrlEncode(str);

Ist äquivalent zu:

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Das gleiche Server.UrlEncode()ruftHttpUtility.UrlEncode()