Servidor.UrlEncode vs HttpUtility.UrlEncode
Hay una diferencia entre el servidor.UrlEncode y HttpUtility.UrlEncode?
6 answers
HttpServerUtility.UrlEncode
utilizará HttpUtility.UrlEncode
internamente. No hay diferencia específica. La razón de la existencia de Server.UrlEncode
es la compatibilidad con el ASP clásico.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-03-02 15:03:07
Tuve dolores de cabeza significativos 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 - esta cosa es realmente incomprensible. Codifica:
- " " ==> "%20"
- "100% true" = = > "100% % 20true" (ok, tu url está rota ahora)
- "test A. aspx#anchor B" ==> "test%20A.aspx#anchor%20B"
- "prueba A. aspx?hmm # anchor B "= = > " test%20A. aspx?hmm # ancla B" (tenga en cuenta la diferencia con la secuencia de escape anterior!)
También tiene la documentación lovelily específica de MSDN "Codifica la porción de ruta de una cadena 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 a ti mismo el pie con una Uzi...
En resumen, apégate a Uri.EscapeDataString.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-11-01 15:44:11
Tenga en cuenta que probablemente no debería usar ninguno de esos métodos. La biblioteca de Scripting Anti-Cross Site de Microsoft incluye reemplazos para HttpUtility.UrlEncode
y HttpUtility.HtmlEncode
que son más compatibles con los estándares y más seguros. Como bono, también obtienes un método JavaScriptEncode
.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-06-22 11:21:40
Avance rápido casi 9 años desde que se preguntó 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 otros lugares, Uri.EscapeDataString parece ser preferible. ¿Pero lo 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
lo codifica como%20
. -
Uri.EscapeDataString
por ciento-codifica!
,(
,)
, y*
;WebUtility.UrlEncode
no. -
WebUtility.UrlEncode
por ciento-codifica~
;Uri.EscapeDataString
no lo hace. -
Uri.EscapeDataString
lanza unUriFormatException
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, particularmente cuando se trata de datos de formulario codificados con URL.) -
Uri.EscapeDataString
lanza unUriFormatException
en los caracteres sustitutos altos;WebUtility.UrlEncode
no lo hace. (Eso es una cosa UTF-16, probablemente mucho menos común.)
Para fines de codificación de URL, los caracteres encajan en una de las 3 categorías: sin reserva (legal en una URL); reservado (legal en pero tiene un significado especial, por lo que podría querer codificarlo); y todo lo demás (siempre debe estar codificado).
De acuerdo con el RFC , los caracteres reservados son: :/?#[]@!$&'()*+,;=
Y los caracteres sin reservas son alfanuméricos y -._~
El Verdict
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 más extraño aún codifica ese carácter inocentemente sin reservas ~
.
Por lo tanto, estoy de acuerdo con el consejo popular - use Uri.EscapeDataString cuando posible, y entiende que los caracteres reservados como /
y ?
se codificarán. Si necesita tratar con cadenas potencialmente grandes, particularmente con contenido de formulario codificado en URL, deberá recurrir a WebUtility.UrlEncode y aceptar sus peculiaridades, o de lo contrario trabajar alrededor del problema.
EDITAR: He intentado rectificar TODAS las peculiaridades mencionadas anteriormente en Flurl a través de la Url.Encode
, Url.EncodeIllegalCharacters
, y Url.Decode
métodos estáticos. Estos están en el paquete principal (que es pequeño y no incluye todas las cosas HTTP), o siéntase libre de extraerlos de la fuente. Agradezco cualquier comentario/retroalimentación que tenga 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}");
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-06-19 14:19:09
Servidor.UrlEncode() está ahí para proporcionar compatibilidad con versiones anteriores con Classic ASP,
Server.UrlEncode(str);
Es equivalente a:
HttpUtility.UrlEncode(str, Response.ContentEncoding);
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-03-02 15:11:36
Lo mismo, Server.UrlEncode()
llama HttpUtility.UrlEncode()
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-12-07 12:30:52