punto y coma como separador de consulta URL

Question

retira enlace Imageshack muertos - signo vs punto y coma

Aunque se recomienda encarecidamente (W3C source, a través de Wikipedia) para los servidores web para apoyar la coma como separador de elementos de consulta URL (además de ampersand), no parece ser seguido en general.

Por ejemplo, comparar

http://www.google.com/search?q=nemo&oe=utf-8

http://www.google.com/search?q=nemo;oe=utf-8

resultados. (En este último caso, punto y coma es, o era en el momento de escribir este texto, tratados como cadena de caracteres ordinarios, como si la url era: http://www.google.com/search?q=nemo%3Boe=utf-8)

Aunque el primer análisis de URL de la biblioteca he intentado, se comporta bien :

>>> from urlparse import urlparse, query_qs 
>>> url = 'http://www.google.com/search?q=nemo;oe=utf-8' 
>>> parse_qs(urlparse(url).query) 
{'q': ['nemo'], 'oe': ['utf-8']} 

¿Cuál es el estado actual de aceptar el punto y coma como separador, y cuáles son los posibles problemas o algunas notas interesantes? (desde el punto de vista tanto del servidor como del cliente)

Answer 1

El W3C Recommendation from 1999 es obsoleto. El estado actual, de acuerdo con la 2014 W3C Recommendation, es que punto y coma es ahora ilegal como un separador de parámetro:

para decodificar cargas útiles/x-www-form-urlencoded de aplicación, el siguiente algoritmo debe ser utilizado. [...] El resultado de este algoritmo es una lista ordenada de pares nombre-valor. [...]

1. cadenas dejar ser el resultado de dividir la carga útil estrictamente cadena en + 0026 caracteres ampersand U (&).

En otras palabras, ?foo=bar;baz significa que el parámetro foo tendrá el valor bar;baz; mientras que ?foo=bar;baz=sna debería dar como resultado foo que es bar;baz=sna (aunque técnicamente ilegal ya que el segundo = debe escaparse a %3D).

Answer 2

Siempre que su servidor HTTP y su aplicación del lado del servidor acepten puntos y comas como separadores, debería estar listo. No puedo ver ningún inconveniente. Como dijo, W3C spec is on your side:

Recomendamos que los implementadores de servidores HTTP y, en particular, los implementadores de CGI admitan el uso de ";" en lugar de "&" para salvar a los autores el problema de escapar de los caracteres "&" de esta manera.

Answer 3

Estoy de acuerdo con Bob Aman. La especificación W3C está diseñada para facilitar el uso de hipervínculos de anclaje con URL que se parecen a las solicitudes GET de formulario (por ejemplo, http://www.host.com/?x=1&y=2). En este contexto, el ampersand entra en conflicto con el sistema de referencias de entidad de caracteres, que comienzan con un signo de unión (por ejemplo, "). Por lo tanto, W3C recomienda que los servidores web permitan usar un punto y coma como un separador de campo en lugar de un ampersand, para que sea más fácil escribir estas URL. Pero esta solución requiere que los escritores recuerden que el ampersand debe ser reemplazado por algo, y que un ; es un delimitador de campo igualmente válido, aunque los navegadores web usen universalmente los símbolos en la URL cuando envían formularios. Eso es posiblemente más difícil que recordar reemplazar el ampersand con un & en estos enlaces, tal como se haría en otra parte del documento.

Para empeorar las cosas, hasta que todos los servidores web permitan puntos y comas como delimitadores de campo, los escritores de URL solo pueden usar este acceso directo para algunos hosts, y deben usar & para otros. También tendrán que cambiar su código más adelante si un host determinado deja de permitir los delimitadores de punto y coma. Esto es ciertamente más difícil que simplemente usar &, que funcionará para todos los servidores para siempre. Esto, a su vez, elimina cualquier incentivo para que los servidores web permitan los puntos y comas como separadores de campo. ¿Por qué molestarse, cuando todo el mundo ya está cambiando el ampersand al & en lugar de ;?

Answer 4

En resumen, HTML es un gran desastre (debido a su indulgencia), y el uso de punto y coma ayuda a simplificar mucho esto.Estimo que cuando tomo en cuenta las complicaciones que he encontrado, ¡el uso de ampersands como separador hace que el proceso sea tres veces más complicado que utilizar puntos y comas para separadores!

Soy un programador .NET y que yo sepa, .NET no no inherentemente permiten ';' separadores, así que escribí mis propios métodos de análisis y manejo porque vi un gran valor en el uso de puntos y comas en lugar del ya problemático sistema de usar los signos y símbolos como separadores. Desafortunadamente, las personas muy respetables (como @Bob Aman en otra respuesta) no ven el valor de por qué el uso de punto y coma es muy superior y mucho más simple que el uso de símbolos. Así que ahora comparto algunos puntos a tal persuadir a otros desarrolladores respetables que no reconocen el valor todavía de utilizar punto y coma en su lugar: '? A = 1 b = 2 &'

Usando una cadena de consulta como en una página HTML es inadecuada (sin HTML codificándolo primero), pero la mayoría de las veces funciona. Sin embargo, esto solo se debe a que la mayoría de los navegadores son tolerantes, y esa tolerancia puede provocar errores difíciles de encontrar cuando, por ejemplo, el valor del par de valores clave se publica en una URL de página HTML sin la codificación adecuada (directamente como '? a = 1 & b = 2 'en la fuente HTML). Un QueryString como '? Who = me + & + you' también es problemático.

Nosotros las personas podemos tener sesgos y podemos estar en desacuerdo sobre nuestros prejuicios durante todo el día, por lo que es muy importante reconocer nuestros prejuicios. Por ejemplo, estoy de acuerdo en que solo pienso en separarme con ';' se ve 'más limpio'. Estoy de acuerdo en que mi opinión "limpia" es puramente parcial. Y otro desarrollador puede tener un sesgo igualmente opuesto e igualmente válido. Entonces mi parcialidad en este punto no es más correcto que el sesgo opuesto.

Pero dado el apoyo imparcial del punto y coma que facilita la vida de todos a largo plazo, no se puede cuestionar correctamente cuando se tiene en cuenta la imagen completa. En resumen, el uso de punto y coma simplifica la vida de todos, con una excepción: un pequeño obstáculo para acostumbrarse a algo nuevo. Eso es todo. Siempre es más difícil hacer algo cambiar. Pero la dificultad de hacer el cambio palidece en comparación con la dificultad continua de continuar usando &.

Usando; como un separador QueryString lo hace MUCHO más simple. Los separadores Ampersand son más del doble de difíciles para codificar correctamente que si se utilizaran puntos y comas. (Creo) que la mayoría de las implementaciones no están codificadas correctamente, por lo que la mayoría de las implementaciones no son el doble de complicadas. Pero luego rastrear y corregir los errores conduce a una pérdida de productividad. Aquí, señalo 2 etapas de codificación separados necesarios para codificar adecuadamente una cadena de consulta cuando & es el separador:

• Paso 1: Codificar URL tanto las claves y valores de la cadena de consulta.
• Paso 2: concatenar los claves y valores como 'a = 1 & b = 2' después de que son URL codificada desde el paso 1.
• Paso 3: A continuación, HTML codifican toda la cadena de consulta en el código HTML de la página.

Por lo tanto, la codificación especial se debe realizar dos veces para una correcta codificación URL (libre de errores), y no solo eso, pero las codificaciones son dos tipos de codificación distintas y distintas. El primero es una codificación URL y el segundo es una codificación HTML (para código fuente HTML). Si alguno de estos es incorrecto, entonces puedo encontrar un error. Pero el paso 3 es diferente para XML. Para XML, en su lugar se necesita la codificación de entidad de caracteres XML (que es casi idéntica). Mi punto es que la última codificación depende del contexto de la URL, ya sea en una página web HTML o en documentación XML.

Ahora, con los separadores de punto y coma mucho más simples, el proceso es como una wud esperar:

• 1: URL codificar las claves y valores,
• 2: concatenar los valores. (Sin codificación para el paso 3.)

Creo que la mayoría de los desarrolladores web omiten el paso 3 porque los navegadores son muy indulgentes. Pero esto lleva a errores y más complicaciones al buscar esos errores o usuarios que no pueden hacer cosas si esos errores no estaban presentes, o escribir informes de errores, etc.

Otra complicación en el uso real es cuando se escribe el marcado de documentación XML en mi código fuente tanto en C# como en VB.NET. Como el & debe estar codificado, es una verdadera resistencia, literalmente, a mi productividad. Ese paso 3 adicional hace que sea más difícil leer el código fuente también. Por lo tanto, este déficit más difícil de leer se aplica no solo a HTML y XML, sino también a otras aplicaciones como C# y código VB.NET porque su documentación utiliza documentación XML. Por lo tanto, la complicación de codificación del paso n. ° 3 también prolifera en otras aplicaciones.

Por lo tanto, en resumen, utilizando; como separador es simple porque el proceso (correcto) cuando se utiliza el punto y coma es la forma en que un wud normalmente espera que el proceso sea: solo se necesita un paso de codificación.

Quizás esto no fue demasiado confuso. Pero toda la confusión o dificultad se debe al uso de un carácter de separación que se codifica en HTML. Por lo tanto, '&' es el culpable. Y el punto y coma alivia toda esa complicación.