2009-01-31 12 views
107

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

En particular, ¿alguien puede señalar a un RFC que indique que se debe codificar una URL con un espacio ?

Motivación por pregunta: Mientras probaba beta 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 con un RFC para que sintieran la necesidad de corregir esas URL.

+0

superconjunto que vino después: cuáles son todos los caracteres inválidos: http://stackoverflow.com/questions/1547899/which-characters-make-a-url-invalid –

+0

** Relacionado: ** [En una URL, ¿los espacios deben codificarse usando% 20 o +?] (http://stackoverflow.com/q/1211229/1497596) – DavidRR

Respuesta

87

Según RFC 1738:

inseguro:

caracteres pueden ser inseguras para una serie de razones. El carácter no es seguro porque los espacios significativos pueden desaparecer y espacios insignificantes pueden introducirse cuando las URL se transcriben tipográficos o se someten al tratamiento de programas de procesamiento de texto. Los caracteres "<" y ">" no son seguros porque se usan como los delimitadores alrededor de las URL en texto libre; la marca de cotización (""") se utiliza para delimitar las URL de en algunos sistemas.El carácter "#" no es seguro y debe codificarse porque se utiliza en la World Wide Web y en otros sistemas para delimitar una URL de un identificador de fragmento/ancla que podría seguirlo. El carácter "%" no es seguro porque se usa para las codificaciones de otros caracteres. Otros caracteres no son seguros porque se sabe que las puertas de enlace y otros agentes de transporte modifican a veces tales caracteres. Estos personajes son "{", "}", "|", "\", "^", "~", "[", "]" y "`".

Todos los caracteres inseguros siempre se deben codificar dentro de una URL. Para el ejemplo , el carácter "#" debe estar codificado dentro de las URL incluso en los sistemas que normalmente no se ocupan de los identificadores de fragmento o ancla, de modo que si la URL se copia en otro sistema que los utiliza, no será necesario cambiar la codificación URL.

+1

1738 ha sido reemplazado por 2396. http://www.ietf.org/rfc/rfc2396.txt Esa es la especificación actual de Uri. Sin embargo, no importa en este caso. –

+33

Y 2396 ha sido reemplazado por 3986. Muchas personas lo malinterpretan, ya que las RFC son inmutables, y por lo tanto no le dicen al lector que se han quedado obsoletas. Sugerencia: utilice http://tools.ietf.org/html/rfcnnnn, como http://tools.ietf.org/html/rfc2396, en su lugar, muestra los metadatos faltantes en la parte superior. –

5

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

-3

No he visto eso. Tal vez pueda configurar el servidor web para aceptar que ...

3

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

2

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

4

Para responder a su pregunta. Yo 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 porcentual (URI) más difícil de leer que ocurre.

Echa un vistazo a este artículo de wikipedia sobre Percent-encoding.

9

Las URL se definen en RFC 3986, aunque otras RFC también son relevantes, pero RFC 1738 está obsoleto.

Es posible que no tengan espacios en ellas, junto con muchos otros caracteres. Como esos caracteres prohibidos a menudo necesitan ser representados 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.

26

Respuesta más breve: no, debe codificar un espacio; es es correcto para codificar un espacio como +, pero solo en la cadena de consulta; en la ruta debe usar %20.

+1

Hola, también estoy confundido, alguna vez vi que el libro usaba "+" pero a veces "% 20", ¿puedes mostrar algún ejemplo para esto? Cuando el usuario envía el formulario, ¿cómo el formulario codifica el espacio? con que personaje? – GMsoF

+1

Consulte [esta respuesta] (http://stackoverflow.com/a/1211256/1497596) para obtener detalles adicionales. – DavidRR

+0

¿qué hay de la parte fragmento/hash? ¿Cómo deberían codificarse los espacios allí? – gumkins

40

¿Por qué tiene que estar codificado? Una solicitud tiene este aspecto:

GET /url HTTP/1.1 
(Ignoring headers) 

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

GET /url end_url HTTP/1.1 

que usted conoce tiene 4 campos, el servidor HTTP le dirá que se trata de una solicitud válida.

GET /url%20end_url HTTP/1.1 

3 campos => válida

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

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

en lugar de

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

¿Qué pasa si var realmente fuera "foo + bar" y no "foo bar"? – Ivo3185

+8

A + tiene que estar codificado como% 2b – Julien

+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 de la especificación URL. Del mismo modo, podría argumentar que las comillas en las URL "deben" estar codificadas porque de lo contrario se romperían las páginas web. Pero eso es una propiedad de las limitaciones de formato HTML (que hay otras estrategias en contra), no una propiedad de la especificación de URL. –

5

¿Puede alguien señalar a un RFC que indique que una URL con un espacio debe ser en codificado?

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

Si nos fijamos en la gramática definida por allí es muy probable que tenga en cuenta que un carácter de espacio no 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í misma.

4

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 crea que hará que la URL sea más legible y 'bonita';) .....O por lo que los caracteres generales que se prefieren son "-", "_", "+" ... pero estas no son las compulsiones, por lo que puede usar cualquiera de los caracteres que no se supone que ya están en la URL.

Por favor, evite el%, &,}, {,], [, /,>, < como el reemplazo de caracteres de espacio de URL ya que pueden generar un error en ciertos navegadores y plataformas.

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

Have a Happy questioning.

Cuestiones relacionadas