¿Cuándo se debe codificar el espacio en más (+) o %20? [duplicar]
A veces, los espacios se codifican en la URL del +signo y otras veces en %20. ¿Cuál es la diferencia y por qué debería suceder esto?
+significa un espacio solo en application/x-www-form-urlencodedel contenido, como la parte de consulta de una URL:
http://www.example.com/path/foo+bar/path?query+name=query+value
En esta URL, el nombre del parámetro tiene query nameun espacio y el valor tiene query valueun espacio, pero el nombre de la carpeta en la ruta es literalmente foo+bar, no foo bar .
%20es una forma válida de codificar un espacio en cualquiera de estos contextos. Entonces, si necesita codificar una cadena en URL para incluirla en parte de una URL, siempre es seguro reemplazar los espacios con %20y los signos más con %2B. Esto es lo que, por ejemplo, encodeURIComponent()hace en JavaScript. Desafortunadamente, no es lo que hace urlencode en PHP ( rawurlencode es más seguro).
Ver también
Aplicación de especificación HTML 4.01/x-www-form-urlencoded
Entonces, las respuestas aquí están un poco incompletas. El uso de a %20para codificar un espacio en URL se define explícitamente en RFC 3986 , que define cómo se construye un URI. En esta especificación no se menciona el uso de a +para codificar espacios; si sigue únicamente esta especificación, un espacio debe codificarse como %20.
La mención del uso de +espacios para codificar proviene de las diversas encarnaciones de la especificación HTML, específicamente en la sección que describe el tipo de contenido application/x-www-form-urlencoded. Esto se utiliza para publicar datos del formulario.
Ahora, la especificación HTML 2.0 (RFC 1866) dice explícitamente, en la sección 8.2.2, que la parte de consulta de la cadena URL de una solicitud GET debe codificarse como application/x-www-form-urlencoded. Esto, en teoría, sugiere que es legal usar a +en la URL en la cadena de consulta (después de ?).
Pero... ¿realmente lo es? Recuerde, HTML es en sí mismo una especificación de contenido y las URL con cadenas de consulta se pueden utilizar con contenido distinto de HTML. Además, aunque las versiones posteriores de la especificación HTML continúan definiéndose +como application/x-www-form-urlencodedcontenido legal, omiten por completo la parte que dice que las cadenas de consulta de solicitud GET se definen como ese tipo. De hecho, no hay mención alguna sobre la codificación de la cadena de consulta en nada después de la especificación HTML 2.0.
Lo que nos deja con la pregunta: ¿es válido? Ciertamente, hay una gran cantidad de código heredado que admite +cadenas de consulta y también una gran cantidad de código que lo genera. Por lo tanto, es muy probable que no se rompa si usa +. (Y, de hecho, investigué todo sobre esto recientemente porque descubrí un sitio importante que no aceptó %20una consulta GET como espacio. En realidad, no pudieron decodificar ningún porcentaje de carácter codificado. Por lo tanto, el servicio que estás utilizando puede ser relevante también.)
Pero a partir de una lectura pura de las especificaciones, sin el lenguaje de la especificación HTML 2.0 trasladado a versiones posteriores, las URL están cubiertas completamente por RFC 3986 , lo que significa que los espacios deben convertirse a %20. Y definitivamente ese debería ser el caso si solicita algo más que un documento HTML.
