name - URL que codifica el carácter de espacio:+o% 20?
meta name keywords (4)
De Wikipedia (énfasis y enlace añadido):
Cuando se envían los datos que se han ingresado en formularios HTML, los nombres y valores de los campos de formulario se codifican y envían al servidor en un mensaje de solicitud HTTP utilizando el método GET o POST, o, históricamente, por correo electrónico. La codificación utilizada de forma predeterminada se basa en una versión muy temprana de las reglas generales de codificación de porcentaje de URI, con una serie de modificaciones , como la normalización de nueva línea y la sustitución de espacios con "+" en lugar de "% 20". El tipo MIME de datos codificados de esta manera es application / x-www-form-urlencoded, y actualmente está definido (aún de manera muy obsoleta) en las especificaciones de HTML y XForms.
Por lo tanto, el porcentaje real de codificación usa %20 mientras que los datos de formulario en las URL están en una forma modificada que usa + . ¿Entonces es más probable que solo veas + en las URL en la cadena de consulta después de un ? .
¿Cuándo se codifica un espacio en una URL a + y cuándo se codifica a %20 ?
Esta confusión se debe a que la URL todavía está "dañada" hasta el día de hoy.
Tome " http://www.google.com " por ejemplo. Esta es una URL. Una URL es un Localizador de recursos uniforme y es realmente un puntero a una página web (en la mayoría de los casos). Las URL realmente tienen una estructura muy bien definida desde la primera especificación en 1994.
Podemos extraer información detallada sobre la URL " http://www.google.com ":
+---------------+-------------------+
| Part | Data |
+---------------+-------------------+
| Scheme | http |
| Host | www.google.com |
+---------------+-------------------+
Si nos fijamos en una URL más compleja como:
" https://bob:[email protected]:8080/file;p=1?q=2#third "
Podemos extraer la siguiente información:
+-------------------+---------------------+
| Part | Data |
+-------------------+---------------------+
| Scheme | https |
| User | bob |
| Password | bobby |
| Host | www.lunatech.com |
| Port | 8080 |
| Path | /file;p=1 |
| Path parameter | p=1 |
| Query | q=2 |
| Fragment | third |
+-------------------+---------------------+
https://bob:[email protected]:8080/file;p=1?q=2#third
/___/ /_/ /___/ /______________/ /__//_______/ /_/ /___/
| | | | | | /_/ | |
Scheme User Password Host Port Path | | Fragment
/_____________________________/ | Query
| Path parameter
Authority
Los caracteres reservados son diferentes para cada parte.
Para las URL de HTTP, un espacio en una parte del fragmento de la ruta debe codificarse en "% 20" (no, absolutamente no "+"), mientras que el carácter "+" en la parte del fragmento de la ruta se puede dejar sin codificar.
Ahora en la parte de la consulta, los espacios pueden codificarse en "+" (para compatibilidad con versiones anteriores: no intente buscarlos en el estándar URI) o "% 20" mientras que el carácter "+" (como resultado de esta ambigüedad ) tiene que ser escapado a "% 2B".
Esto significa que la cadena "azul + azul claro" debe codificarse de forma diferente en las partes de ruta y consulta:
" http://example.com/blue+light%20blue?blue%2Blight+blue ".
Desde allí puede deducir que la codificación de una URL totalmente construida es imposible sin un conocimiento sintáctico de la estructura de la URL.
A lo que se reduce esto es:
Deberías tener %20 antes del ? y + después.
Un espacio solo se puede codificar a "+" en los pares de clave-valor de tipo de contenido "application / x-www-form-urlencoded", consultar parte de una URL. Este es un mayo, no un deber. En el resto de las URL, se codifica como% 20.
En mi opinión, es mejor codificar siempre los espacios como% 20, no como "+", incluso en la parte de consulta de una URL, porque es la especificación HTML (RFC-1866) la que especifica que los caracteres del espacio deben codificarse como " + "en" application / x-www-form-urlencoded "pares de clave-valor de tipo de contenido. (vea el párrafo 8.2.1. subpárrafo 1.) Esta forma de codificar datos de formulario también se proporciona en las especificaciones HTML posteriores, por ejemplo, busque párrafos relevantes sobre la aplicación / x-www-form-urlencoded en HTML 4.01 Specification, etc. .
Aquí hay una cadena de muestra en la URL donde la especificación HTML permite codificar espacios como ventajas: " http://example.com/over/there?name=foo+bar ". Entonces, solo después de "?", Los espacios pueden reemplazarse por ventajas, de acuerdo con la especificación HTML. En otros casos, los espacios deben estar codificados a% 20. Pero como es difícil determinar correctamente el contexto, es la mejor práctica nunca codificar espacios como "+".
Recomendaría codificar en porcentaje todos los caracteres excepto "sin reservas" definido en RFC-3986, p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
La implementación depende del lenguaje de programación que elijas.
Si su URL contiene caracteres nacionales, primero codifíquelos a UTF-8 y luego codifique en porcentaje el resultado.
Yo recomendaría %20 .
¿Los estás codificando?
Sin embargo, esto no es muy consistente en todos los idiomas. Si no me equivoco, en PHP urlencode() trata los espacios como + mientras que urlencode() de Python urlencode() trata como %20 .
EDITAR:
Parece que estoy equivocado. El urlencode() de Python urlencode() (al menos en 2.7.2) usa quote_plus() lugar de quote() y, por tanto, codifica los espacios como "+". También parece que la recomendación de W3C es el "+" según aquí: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
Y, de hecho, puede seguir este interesante debate sobre el propio rastreador de problemas de Python sobre qué usar para codificar espacios: http://bugs.python.org/issue13866 .
EDICIÓN # 2:
Entiendo que la forma más común de codificación "" es como "+", pero solo una nota, puede ser solo yo, pero esto me parece un poco confuso:
import urllib
print(urllib.urlencode({'' '' : ''+ ''})
>>> ''+=%2B+''