Server.UrlEncode vs.HttpUtility.UrlEncode

StackOverflow https://stackoverflow.com/questions/602642

  •  03-07-2019
  •  | 
  •  

Frage

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

War es hilfreich?

Lösung

HttpServerUtility.UrlEncode wird HttpUtility.UrlEncode intern verwenden. Es gibt keinen spezifischen Unterschied. Der Grund für die Existenz von Server.UrlEncode ist die Kompatibilität mit klassischen ASP.

Andere Tipps

Ich hatte erhebliche Kopfschmerzen, die mit diesen Methoden vor, Ich empfehle Sie vermeiden jeder Variante von UrlEncode, und verwenden Sie stattdessen Uri.EscapeDataString zumindest hat man ein verständliches Verhalten.

Lassen Sie uns sehen...

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 hat HttpUtility.UrlPathEncode - diese Sache ist wirklich unverständlich.Es kodiert:

  • " " ==> "%20"
  • "100% true" ==> "100%%20true" (ok, die url ist nun gebrochen)
  • "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 mit der vorherigen escape-Sequenz!)

Es hat auch die lovelily bestimmten MSDN-Dokumentation "wird der Pfad der Teil der URL-Zeichenfolge für eine zuverlässige HTTP-übertragung vom Webserver zum client." - ohne wirklich zu erklären, was es tut.Sie sind weniger wahrscheinlich, um zu Schießen selbst in den Fuß mit einer Uzi...

Kurz gesagt, halten Sie sich an Uri.EscapeDataString.

Vorspulen fast 9 Jahre, da dies war zunächst gefragt, und in der Welt des .NET-Core und .NET-Standard scheint es, die am häufigsten verwendeten Optionen, die wir für die URL-Codierung haben, sind WebUtility.UrlEncode (unter System.Net) und Uri.EscapeDataString . Gemessen an der beliebtestenen Antwort hier und anderswo, Uri.EscapeDataString erscheint vorzuziehen zu sein. Aber ist es? Ich habe einige Analyse, die Unterschiede zu verstehen und hier ist, was ich kam mit:

Für URL-Codierung Zwecke Zeichen passen in eine von drei Kategorien: unreserved (legal in einer URL); reserviert (legal in aber besondere Bedeutung hat, so dass Sie könnte es kodieren möchten); und alles andere (muss immer codiert werden).

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

Und das nicht reservierten Zeichen sind alphanumerische und -._~

Das Urteil

Uri.EscapeDataString klar definiert seine Mission:% -encode alle reservierten und ungültige Zeichen. WebUtility.UrlEncode ist weniger eindeutig sowohl in der Definition und Umsetzung. Merkwürdig ist, dass es kodiert einige reservierte Zeichen, andere aber nicht (warum Klammern und nicht Klammern ??), und Fremde noch codiert, dass unschuldig unreserved ~ Charakter.

Daher schließe ich mich mit dem beliebten Rat - mit Uri.EscapeDataString , wenn möglich, und versteht, dass reservierte Zeichen wie / und ? erhalten codiert. Wenn Sie mit potenziell großen Strings befassen müssen, insbesondere mit URL-kodierter Form Inhalt, müssen Sie entweder fallen zurück auf WebUtility.UrlEncode und seine Macken akzeptieren, oder auf andere Weise um das Problem zu umgehen.

EDIT: Ich habe versucht ALL zu korrigieren der Macken oben in Flurl über die Url.Encode, Url.EncodeIllegalCharacters und Url.Decode statischen Methoden erwähnt. Diese sind in der Kernpaket (das ist klein und umfasst nicht alle HTTP-Material), oder fühlen sich frei, um sie von der Quelle zu reißen. Ich begrüße alle Kommentare / Feedback, das Sie auf diese haben.

Hier ist der Code, den ich verwendet, um herauszufinden, welche Zeichen codiert sind unterschiedlich: 

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

Beachten Sie, dass Sie sollten wahrscheinlich auch nicht eine dieser Methoden verwenden. Microsofts Anti-Cross-Site-Scripting-Bibliothek Ersatz enthält für HttpUtility.UrlEncode und HttpUtility.HtmlEncode, die beide mehr standardkonform sind, und sicherer zu machen. Als Bonus erhalten Sie auch eine JavaScriptEncode Methode.

Server.UrlEncode () gibt es die Abwärtskompatibilität mit klassischen ASP zur Verfügung zu stellen, 

Server.UrlEncode(str);

Ist äquivalent zu: 

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Das gleiche, Server.UrlEncode() nennt HttpUtility.UrlEncode()

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top