¿Se permite que una URL contenga un espacio?


132

¿Se permite que un URI (específicamente una URL HTTP) contenga uno o más caracteres de espacio? Si se debe codificar una URL , ¿es +solo una convención comúnmente seguida o una alternativa legítima?

En particular, ¿alguien puede apuntar a un RFC que indique que una URL con un espacio debe estar codificada?

Motivación para la pregunta: durante la prueba beta de un sitio web, noté que algunas URL se construyeron con espacios en ellas. ¡Firefox parecía hacer lo correcto, lo que me sorprendió! Pero quería poder señalar a los desarrolladores un RFC para que sintieran la necesidad de corregir esas URL.


superconjunto que vino después: ¿cuáles son todos los caracteres no válidos: stackoverflow.com/questions/1547899/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Respuestas:


101

Según RFC 1738 :

Inseguro:

Los personajes pueden ser inseguros por varias razones. El carácter de espacio no es seguro porque pueden desaparecer espacios significativos y pueden introducirse espacios insignificantes cuando las URL se transcriben o se componen o se someten al tratamiento de programas de procesamiento de texto. Los caracteres "<"y ">"no son seguros porque se usan como delimitadores alrededor de las URL en texto libre; la comilla ( """) se usa para delimitar URL en algunos sistemas. El carácter "#"no es seguro y siempre debe codificarse porque se usa en la World Wide Web y en otros sistemas para delimitar una URL de un identificador de fragmento / ancla que pueda seguirlo. El personaje"%"no es seguro porque se usa para codificaciones de otros caracteres. Otros caracteres no son seguros porque se sabe que las puertas de enlace y otros agentes de transporte a veces modifican dichos caracteres. Estos personajes son "{", "}", "|", "\", "^", "~", "[", "]", y "`".

Todos los caracteres inseguros siempre deben estar codificados dentro de una URL . Por ejemplo, el carácter "#"debe codificarse dentro de las URL, incluso en sistemas que normalmente no manejan identificadores de fragmentos o de anclaje, de modo que si la URL se copia en otro sistema que los usa, no será necesario cambiar la codificación de la URL.


2
1738 ha sido reemplazado por 2396. ietf.org/rfc/rfc2396.txt Esa es la especificación Uri actual. Sin embargo, no importa en este caso.
Steve Severance

40
Y 2396 ha sido reemplazado por 3986. Muchas personas se equivocan, ya que los RFC son inmutables y, por lo tanto, no le dicen al lector que han quedado obsoletos. Sugerencia: use tools.ietf.org/html/rfcnnnn , como tools.ietf.org/html/rfc2396 en su lugar, muestra los metadatos que faltan en la parte superior.
Julian Reschke

43

¿Por qué tiene que estar codificado? Una solicitud se ve así:

GET /url HTTP/1.1
(Ignoring headers)

Hay 3 campos separados por un espacio en blanco. Si pone un espacio en su url:

GET /url end_url HTTP/1.1

Usted sabe que tiene 4 campos, el servidor HTTP le dirá que es una solicitud no válida.

GET /url%20end_url HTTP/1.1

3 campos => válido

Nota: en la cadena de consulta (después de?), Un espacio generalmente se codifica como un +

GET /url?var=foo+bar HTTP/1.1 

más bien que

GET /url?var=foo%20bar HTTP/1.1 

¿Qué pasaría si var realmente fuera "foo + bar" y no "foo bar"?
Ivo3185

2
Yo diría que es un requisito de la capa de transporte, no de la especificación de URI en sí. GET es claramente una propiedad de la especificación http: no la especificación de URL. Del mismo modo, podría argumentar que las citas en las URL "deben" estar codificadas porque, de lo contrario, las páginas web se romperían. Pero esa es una propiedad de las limitaciones de formato HTML (contra las cuales existen otras estrategias), no una propiedad de la especificación de URL.
Kent Fredric el

ietf.org/rfc/rfc1738.txt - Los caracteres inseguros, incluido el espacio) deben codificarse
Julien

@KentFredric Es más probable que sea la capa de presentación , no la capa de transporte . Como Julien (casi) escribe, la especificación de URI original ( RFC 1630 ) contiene esta restricción, por lo que es parte de la especificación de URI en sí misma, independientemente de sus sentimientos personales. Dado que la especificación de URI se escribió después de los borradores de HTTP, es muy posible que los URI se hayan diseñado teniendo en cuenta HTTP, incluida la prohibición del uso de espacios, pero en realidad no importa, ¿verdad? La verdad es que la especificación es la especificación.
Christopher Schultz el

38

Respuesta más corta: no, debes codificar un espacio; que es correcta para codificar un espacio +, pero sólo en la cadena de consulta; en el camino que debes usar %20.


1
Hola, también estoy confundido, en algún momento vi que el libro usaba "+" pero en algún momento "% 20", ¿puede mostrar algún ejemplo de esto? Cuando el usuario envía el formulario, ¿cómo codifica el formulario el espacio? con que personaje
GMsoF

1
Vea esta respuesta para detalles adicionales.
DavidRR

¿Qué pasa con el fragmento / parte hash? ¿Cómo deben codificarse los espacios allí?
gumkins

@gumkins: el fragmento (# y después) no se envía al servidor. En la práctica, puede usar% 20 o + en cualquier lugar para codificar un espacio.
Julien

9

Las URL se definen en RFC 3986 , aunque otros RFC también son relevantes, pero RFC 1738 es obsoleto.

Es posible que no tengan espacios, junto con muchos otros personajes. Dado que los caracteres prohibidos a menudo deben representarse de alguna manera, existe un esquema para codificarlos en una URL traduciéndolos a su equivalente hexadecimal ASCII con un prefijo "%".

La mayoría de los lenguajes / plataformas de programación proporcionan funciones para codificar y decodificar URL, aunque es posible que no se adhieran correctamente a los estándares RFC. Por ejemplo, sé que PHP no.


7

Sí, el espacio generalmente está codificado en "% 20". Cualquier parámetro que pase a una URL debe codificarse, simplemente por razones de seguridad.


6

La URL puede tener un carácter de espacio en ellos y se mostrarán como% 20 en la mayoría de los navegadores, pero las reglas de codificación del navegador cambian con bastante frecuencia y no podemos depender de cómo un navegador mostrará la URL.

Por lo tanto, puede reemplazar el carácter de espacio en la URL con cualquier carácter que piense que hará que la URL sea más legible y 'Bonita';) ..... O los caracteres generales que se prefieren son "-", "_", "+" ... pero estas no son las compulsiones, por lo que puedes usar cualquiera de los caracteres que ya no deberían estar en la URL.

Evite el%, &,}, {,], [, /,>, <como reemplazo del carácter de espacio de URL, ya que pueden generar un error en ciertos navegadores y plataformas.

Como puede ver, el desbordamiento de Stak usa el carácter '-' como reemplazo de Espacio (% 20).

Ten un feliz interrogatorio.


5

Las URL no deben tener espacios en ellas. Si necesita abordar uno que lo haga, use su valor codificado de%20


5

¿Alguien puede señalar un RFC que indique que una URL con un espacio debe estar codificada?

Los URI y, por lo tanto, los URL, se definen en RFC 3986.

Si observa la gramática definida allí, eventualmente notará que un carácter de espacio nunca puede ser parte de una URL sintácticamente legal, por lo tanto, el término "URL con un espacio" es una contradicción en sí mismo.


3

Para responder tu pregunta. Diría que es bastante común que las aplicaciones reemplacen espacios en valores que se usarán en las URL. La razón de esto es usualmente para evitar la codificación de porcentaje (URI) más difícil de leer que ocurre.

Consulte este artículo de Wikipedia sobre la codificación porcentual .


2

Firefox 3 mostrará %20s en las URL como espacios en la barra de direcciones.


Esto no es una respuesta adecuada a la pregunta bastante sencilla: "Is a URL allowed to contain a space?". Más bien un comentario.
Roko C. Buljan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.