Server.UrlEncode vs. HttpUtility.UrlEncode
Pregunta
¿Hay alguna diferencia entre Server.UrlEncode y HttpUtility.UrlEncode?
Solución
HttpServerUtility.UrlEncode
utilizará HttpUtility.UrlEncode
internamente. No hay diferencia específica. El motivo de la existencia de Server.UrlEncode
es la compatibilidad con ASP clásico.
Otros consejos
Anteriormente tuve algunos dolores de cabeza con estos métodos, te recomiendo que evites cualquier variante de UrlEncode
, y en su lugar use Uri.EscapeDataString
: al menos eso 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 " (ok, tu url está roto ahora)
- " prueba A.aspx # anchor B " == > " prueba% 20A.aspx # anchor% 20B "
- " prueba A.aspx? hmm # anchor B " == > " prueba% 20A.aspx? hmm #anchor B " ( ¡note la diferencia con la secuencia de escape anterior! )
También tiene la preciosa documentación específica de MSDN " Codifica la parte de la ruta de una cadena URL para una transmisión HTTP confiable desde el servidor web a un cliente. " - Sin realmente explicar lo que hace. Es menos probable que te dispares en el pie con un Uzi ...
En resumen, manténgase en Uri.EscapeDataString .
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 (debajo de System.Net
) y Uri.EscapeDataString . A juzgar por la respuesta más popular aquí y en otros lugares, parece que es preferible Uri.EscapeDataString . ¿Pero es? Hice un análisis para comprender las diferencias y esto es lo que se me ocurrió:
-
WebUtility.UrlEncode
codifica el espacio como+
;Uri.EscapeDataString
lo codifica como% 20
. -
Uri.EscapeDataString
percent-encodes!
,(
,)
, y* ;
WebUtility.UrlEncode
no lo hace. -
WebUtility.UrlEncode
percent-encodes~
;Uri.EscapeDataString
no lo hace. -
Uri.EscapeDataString
lanza unaUriFormatException
en cadenas de más de 65,520 caracteres;WebUtility.UrlEncode
no lo hace. ( un problema más común de lo que podría pensar, especialmente cuando se trata de datos de formularios con codificación URL .) -
Uri.EscapeDataString
lanza unaUriFormatException
en caracteres sustitutos altos ;WebUtility.UrlEncode
no lo hace. (Eso es una cosa de UTF-16, probablemente mucho menos común.)
Para propósitos de codificación de URL, los caracteres se ajustan a una de las 3 categorías: sin reserva (legal en una URL); reservado (legal en pero tiene un significado especial, por lo que puede desear codificarlo); y todo lo demás (siempre debe estar codificado).
Según el RFC , los caracteres reservados son: : /? # [] @! $ & amp; '() * +,; =
Y los caracteres no reservados son alfanuméricos y -._~
El veredicto
Uri.EscapeDataString define claramente su misión:% -codificar todos los caracteres reservados e ilegales. WebUtility.UrlEncode es más ambiguo tanto en la definición como en la 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 ~
inocuamente inoculado.
Por lo tanto, estoy de acuerdo con el consejo popular: use Uri.EscapeDataString cuando sea posible, y entiendo que los caracteres reservados como /
y ?
ser codificado Si necesita lidiar con cadenas potencialmente grandes, particularmente con contenido de formulario codificado en URL, deberá recurrir a WebUtility.UrlEncode y aceptar sus peculiaridades, o bien solucionar el problema.
EDITAR: He intentado para rectificar TODO de las peculiaridades mencionadas anteriormente en Flurl a través del Url.Encode
, Url.EncodeIllegalCharacters
y Url.Decode
métodos estáticos. Estos se encuentran en el paquete principal (que es pequeño y no incluye todas las cosas HTTP), O siéntase libre de arrancarlos de la fuente. Doy la bienvenida a cualquier comentario / retroalimentación que tenga sobre estos.
Aquí está el código que utilicé 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(<*>quot;{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");
Tenga en cuenta que probablemente no debería usar ninguno de esos métodos. La biblioteca de secuencias de comandos de sitios cruzados de Microsoft incluye reemplazos para HttpUtility.UrlEncode
y HttpUtility.HtmlEncode
que son más compatibles con los estándares y más seguros. Como beneficio adicional, también obtienes el método JavaScriptEncode
.
Server.UrlEncode () está ahí para proporcionar compatibilidad con versiones anteriores con Classic ASP,
Server.UrlEncode(str);
Es equivalente a:
HttpUtility.UrlEncode(str, Response.ContentEncoding);
Lo mismo, Server.UrlEncode ()
llama a HttpUtility.UrlEncode()