En ASP.NET, ¿por qué hay UrlEncode() Y UrlPathEncode()?

Question

En un proyecto reciente, tuve el placer de solucionar un error que involucraba imágenes que no se cargaban cuando había espacios en el nombre del archivo. Pensé "¡Qué problema tan simple, lo llamaré UrlEncode()!" Pero, NAY! Simplemente usando UrlEncode() no resolvió el problema.

El nuevo problema era el método HttpUtilities.UrlEncode() cambió espacios () para puntos extra (+) en lugar de %20 como el navegador quería. Por lo tanto, file+image+name.jpg devolverá no encontrado mientras se encontró file%20image%20name.jpg correctamente.

Afortunadamente, un compañero de trabajo me señaló HttpUtilities.UrlPathEncode() que usa %20 para espacios en lugar de +.

¿POR QUÉ hay dos formas de manejar la codificación de URL? ¿POR QUÉ hay dos comandos que se comportan de manera diferente?

Answer 1

UrlEncode es útil para uso con una cadena de consulta como los navegadores tienden a utilizar una + aquí en lugar de un espacio cuando el envío de formularios con el método GET.

UrlPathEncode simplemente reemplaza todos los caracteres que no se pueden utilizar dentro de una URL, tales como <, > y .

Ambos enlaces MSDN incluyen esta cita:

puede codificar una URL utilizando el método o el método UrlEncode de UrlPathEncode. Sin embargo, los métodos arrojan resultados diferentes. El método UrlEncode convierte cada carácter de espacio en un carácter más (+). El método UrlPathEncode convierte cada carácter de espacio en la cadena "% 20", que representa un espacio en notación hexadecimal. Use el método UrlPathEncode cuando codifica la porción de ruta de una URL en para garantizar una URL decodificada consistente, independientemente de qué plataforma o explorador realice la decodificación.

Answer 2

Entonces, en una URL, ¿tiene la ruta y luego? y luego los parámetros (es decir, http://some_path/page.aspx?parameters). Las rutas de URL codifican espacios de forma diferente a los parámetros de url, por eso existen las dos versiones. Durante mucho tiempo, los espacios no eran válidos en una URL, pero estaban dentro de los parámetros.

En otras palabras, las URL de formato han cambiado con el tiempo. Durante mucho tiempo, solo los caracteres de ANSI también podrían estar en una URL.