A veces, los espacios obtienen la URL codificada para el +signo, otras veces para %20. ¿Cuál es la diferencia y por qué debería suceder esto?
Respuestas:
+significa un espacio solo en el application/x-www-form-urlencodedcontenido, 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 está query namecon un espacio y el valor está query valuecon un espacio, pero el nombre de la carpeta en la ruta es foo+bar, literalmente , no foo bar .
%20es una forma válida de codificar un espacio en cualquiera de estos contextos. Entonces, si necesita codificar en URL una cadena para incluirla en parte de una URL, siempre es seguro reemplazar espacios con %20y más con %2B. Esto es lo que, por ejemplo. encodeURIComponent()lo hace en JavaScript. Desafortunadamente, no es lo que hace urlencode en PHP ( rawurlencode es más seguro).
Consulte también Aplicación de especificación HTML 4.01 / x-www-form-urlencoded
query+name=query+valueparámetro a partir de un formulario con <input name="query name" value="query value">. No se creará a query%20namepartir de un formulario, pero es totalmente seguro usarlo, por ejemplo. si está preparando un formulario de envío para un XMLHttpRequest. Si tiene una URL con un espacio, como <a href="http://www.example.com/foo bar/">, entonces el navegador lo codificará %20para que pueda corregir su error, pero probablemente no sea confiable.
foo bara foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')si realmente lo necesita+
http://www.example.com/some/path/to/resource?param1=value1
La parte anterior al signo de interrogación debe usar la codificación% ( %20por lo tanto, para el espacio), después del signo de interrogación puede usar %20o +para un espacio. Si necesita un real +después del uso del signo de interrogación %2B.
decodeURIComponentno lo decodifica.
+es un carácter reservado , el navegador lo conservará.
+por defecto ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
Entonces, las respuestas aquí están todas un poco incompletas. El uso de un '% 20' para codificar un espacio en URL se define explícitamente en RFC3986 , que define cómo se construye un URI. En esta especificación no se menciona el uso de un '+' para codificar espacios; si se limita únicamente a esta especificación, un espacio debe codificarse como '% 20'.
La mención de usar '+' para codificar espacios 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 de formulario.
Ahora, la especificación HTML 2.0 (RFC1866) 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 un '+' en la URL en la cadena de consulta (después de '?').
Pero ... ¿de verdad? Recuerde, HTML es en sí mismo una especificación de contenido, y las URL con cadenas de consulta se pueden usar con contenido que no sea HTML. Además, aunque las versiones posteriores de la especificación HTML continúan definiendo '+' como legal en el contenido 'application / x-www-form-urlencoded', omiten por completo la parte que dice que las cadenas de consulta de solicitud GET se definen como ese tipo. De hecho, no se menciona en absoluto 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 MUCHO código heredado que admite '+' en las cadenas de consulta, y mucho código que también lo genera. Entonces, las probabilidades son buenas que no romperá si usa '+'. (Y, de hecho, hice toda la investigación sobre esto recientemente porque descubrí un sitio importante que no aceptaba '% 20' en una consulta GET como un espacio. En realidad no pudieron decodificar CUALQUIER porcentaje de caracteres codificados. está 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 transferida a versiones posteriores, las URL están cubiertas completamente por RFC3986, lo que significa que los espacios deben convertirse a '% 20'. Y definitivamente ese debería ser el caso si está solicitando algo que no sea un documento HTML.
%20( <a href="?q=a b">), pero cuando envía un formulario, utiliza el +signo. Puede anular eso usando explícitamente el +signo ( <a href="?q=a+b">), o enviando el formulario usando XMLHTTPRequest.
Es mejor codificar siempre los espacios como% 20, no como "+".
Fue RFC-1866 (especificación HTML 2.0), que especificó que los caracteres de espacio deben codificarse como "+" en los pares clave-valor de tipo de contenido "application / x-www-form-urlencoded". (Ver párrafo 8.2.1. subpárrafo 1.). Esta forma de codificar los datos del formulario también se proporciona en las especificaciones HTML posteriores. Busque párrafos relevantes sobre application / x-www-form-urlencoded.
Aquí hay un ejemplo de una cadena de este tipo en URL donde RFC-1866 permite codificar espacios como ventajas: "http://example.com/over/there?name=foo+bar". Entonces, solo después de "?", Los espacios pueden ser reemplazados por más, de acuerdo con RFC-1866. En otros casos, los espacios deben codificarse en% 20. Pero como es difícil determinar el contexto, es la mejor práctica nunca codificar espacios como "+".
Recomendaría codificar en porcentaje todos los caracteres excepto "sin reservas" definidos en RFC-3986, p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
¿Cuál es la diferencia? Ver otras respuestas.
Cuando uso en +lugar de %20? Úselo +si, por alguna razón, desea que la cadena de consulta de URL ( ?.....) o el fragmento de hash ( #....) sean más legibles. Ejemplo: en realidad puedes leer esto:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
Pero lo siguiente es mucho más difícil de leer: (al menos para mí)
Creo que +es poco probable que rompa algo, ya que Google usa +(vea el primer enlace más arriba) y probablemente hayan pensado en esto. Me voy a usar +solo porque legible + Google cree que está bien.