asp.net - httputility - urlencode c#

Server.UrlEncode vs. HttpUtility.UrlEncode

Question

¿Hay alguna diferencia entre Server.UrlEncode y HttpUtility.UrlEncode?

Answer 1

Avance rápido casi 9 años desde que se solicitó por primera vez, y en el mundo de .NET Core y .NET Standard, parece que las opciones más comunes que tenemos para la codificación de URL son WebUtility.UrlEncode (en System.Net ) y Uri. EscapeDataString . A juzgar por la respuesta más popular aquí y en todas partes, Uri.EscapeDataString parece ser preferible. ¿Pero es? Hice algunos análisis para entender las diferencias y esto es lo que se me ocurrió:

• WebUtility.UrlEncode codifica el espacio como + ; Uri.EscapeDataString codifica como %20 .
• Uri.EscapeDataString percent-codifica ! , ( , ) y * ; WebUtility.UrlEncode no.
• WebUtility.UrlEncode porcentaje-codifica ~ ; Uri.EscapeDataString no.
• Uri.EscapeDataString arroja una UriFormatException en cadenas de más de 65.520 caracteres; WebUtility.UrlEncode no. ( Un problema más común de lo que podría pensar, especialmente cuando se trata de datos de formularios codificados en URL .)
• Uri.EscapeDataString arroja una UriFormatException en los caracteres substitutos superiores ; WebUtility.UrlEncode no. (Eso es algo de UTF-16, probablemente mucho menos común).

Para propósitos de codificación de URL, los personajes encajan en una de 3 categorías: sin reserva (legal en una URL); reservado (legal pero tiene un significado especial, por lo que es posible que desee codificarlo); y todo lo demás (siempre debe estar codificado).

De acuerdo con el RFC , los caracteres reservados son:: :/?#[]@!$&''()*+,;=

Y los caracteres sin reserva son alfanuméricos y -._~

El veredicto

Uri.EscapeDataString define claramente su misión:% -encode todos los caracteres reservados e ilegales. WebUtility.UrlEncode es más ambiguo tanto en definición como en implementación. Curiosamente, codifica algunos caracteres reservados pero no otros (¿por qué paréntesis y no corchetes?), Y aún más extraño codifica ese carácter inocentemente sin reservas.

Por lo tanto, estoy de acuerdo con el consejo popular: use Uri.EscapeDataString cuando sea posible, y entienda que los caracteres reservados como / y ? se codificará Si necesita manejar cadenas potencialmente grandes, particularmente con contenido de formularios codificados en URL, necesitará recurrir a WebUtility.UrlEncode y aceptar sus caprichos, o bien resolver el problema.

EDITAR: He attempted rectificar TODAS las peculiaridades mencionadas anteriormente en Flurl través de los métodos estáticos Url.Encode , Url.EncodeIllegalCharacters y Url.Decode . Estos se encuentran en el paquete principal (que es muy pequeño y no incluye todo el material HTTP), o puede extraerlos de la fuente. Agradezco cualquier comentario / comentario que tengas sobre estos.

Aquí está el código que usé para descubrir qué caracteres están codificados de manera diferente:

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

Answer 2

He tenido dolores de cabeza importantes con estos métodos antes, te recomiendo evitar cualquier variante de UrlEncode , y en su lugar usar Uri.EscapeDataString , al menos ese tiene un comportamiento comprensible.

Veamos...

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

Pero mi favorito personal tiene que ser HttpUtility.UrlPathEncode - esto es realmente incomprensible. Codifica:

• "" ==> "% 20"
• "100% verdadero" ==> "100 %% 20true" (vale, tu url está roto ahora)
• "prueba A.aspx # anclaje B" ==> "prueba% 20A.aspx # anclaje 20B "
• "prueba A.aspx? hmm # anchor B" ==> "test% 20A.aspx? hmm #anchor B " (¡ fíjate en la diferencia con la secuencia de escape anterior! )

También tiene la documentación de MSDN, muy atractiva "Codifica la porción de ruta de una cadena de URL para una transmisión HTTP confiable desde el servidor web a un cliente". - sin explicar realmente lo que hace. Es menos probable que te dispares en el pie con una Uzi ...

En resumen, quédate con Uri.EscapeDataString .

Answer 3

Lo mismo, Server.UrlEncode() llama a HttpUtility.UrlEncode()

Answer 4

Server.UrlEncode () está ahí para proporcionar compatibilidad con ASP clásico,

Server.UrlEncode(str);

Es equivalente a:

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Answer 5

Tenga en cuenta que probablemente no deba utilizar ninguno de esos métodos. La biblioteca de secuencias de comandos de Microsoft Anti-Cross Site incluye reemplazos para HttpUtility.UrlEncode y HttpUtility.HtmlEncode que son más compatibles con los estándares y más seguros. Como extra, también obtienes un método JavaScriptEncode .

Answer 6

HttpServerUtility.UrlEncode usará HttpUtility.UrlEncode internamente. No hay diferencia específica El motivo de existencia de Server.UrlEncode es la compatibilidad con ASP clásico.