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 , nofoo 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).
Realmente estoy confundido, mi pregunta es, cuando el navegador hace la primera forma, y cuando la segunda forma?
Muhammad Hewedy
11
El navegador creará un 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.
bobince
66
cuál es la función del la marca Javascript foo bara foo+bar?
Sisir
21
@Sisir: no hay una función JS que haga codificación de formulario URL. Naturalmente, puede hacerlo encodeURIComponent(s).replace(/%20/g, '+')si realmente lo necesita+
bobince
2
Ese es un ejemplo muy, muy confuso de algo que está codificado en forma. No tiene nada que ver con las URL.
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.
porque está mal Es parte del antiguo tipo de medio de aplicación / x-www-form-urlencoded que no se aplica a las URL. Además, decodeURIComponentno lo decodifica.
Dave Van den Eynde
3
Sí, probablemente se copió de RFC 1630 y nunca fue realmente un estándar. tools.ietf.org/html/rfc3986 es el estándar (actualizado nuevamente para IPv6 o algo así). Seguro que los navegadores todavía lo "admiten", pero ¿qué significa eso? Es el código del servidor o del cliente el que lee la cadena de consulta y la decodifica, no el navegador. El navegador simplemente lo pasa de un lado a otro, y dado que +es un carácter reservado , el navegador lo conservará.
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.
Para agregar a su respuesta, Chrome codifica de manera predeterminada los espacios en las URL como %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.
x-yuri
Es realmente difícil entender el propósito de agregar URLSearchParams developers.google.com/web/updates/2016/01/urlsearchparams , que funciona de alguna manera heredada (serializar SPACE en '+'). ¡Incluso no es compatible con IE11!
Nymphetamine
9
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
En .Net Framework, UrlEncode usa '+' en QueryString, pero en .Net Core% 20 moderno se usa
Michael Freidgeim
@ MiFreidgeimSO-stopbeingevil Gracias por informarnos. Parece que el .Net Core moderno decidió ser más consistente y compatible.
Maxim Masiutin
2
¿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:
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.
@FlipMcF La página de Wikipedia de falaz argumento de autoridad es sobre "cuando se cita a una autoridad sobre un tema fuera de su área de especialización o cuando la autoridad citada no es un verdadero experto " - Creo, sin embargo, que las computadoras, HTTP y URL la codificación es algo dentro del área de especialización de Google.
KajMagnus
3
@FlipMcF Citar el comportamiento de Google, en este caso, es un argumento válido para usar "+" en las URL. No es que google sea una autoridad, sino que google es probablemente la mayor compañía de internet y si hacen algo de alguna manera, es muy poco probable que algún día los navegadores decidan dejar de apoyar esa práctica. Además, Google Chrome es uno de los navegadores con mayor participación, y admitirá lo que Google quiera. En general, diría que nadie que use "+" en lugar de "% 20" tendrá dificultades por eso en el futuro previsible.
jdferreira
Me encantaría continuar este argumento en otro lugar, donde hay un atractivo para la popularidad para negarse a reconocer un recurso ante la autoridad. Al menos todos podemos estar de acuerdo en una cosa: '+' es superior a '% 20'
FlipMcF
1
En realidad, la URL con% 20 es mucho más fácil de leer porque los navegadores (de escritorio) muestran la URL decodificada en la parte inferior de la ventana si mueve el cursor del mouse sobre el enlace. Los signos más se muestran sin cambios.
Respuestas:
+significa un espacio solo en elapplication/x-www-form-urlencodedcontenido, como la parte de consulta de una URL: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 esfoo+bar, literalmente , nofoo 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
fuente
query+name=query+valueparámetro a partir de un formulario con<input name="query name" value="query value">. No se creará aquery%20namepartir de un formulario, pero es totalmente seguro usarlo, por ejemplo. si está preparando un formulario de envío para unXMLHttpRequest. 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 barafoo+bar?encodeURIComponent(s).replace(/%20/g, '+')si realmente lo necesita+http://www.example.com/some/path/to/resource?param1=value1La 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.fuente
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.
fuente
%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 usandoXMLHTTPRequest.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
fuente
¿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í)
https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces
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.fuente