Semicolon como separador de consultas URL

eliminado el enlace muerto de Imageshack – signo ampersand versus punto y coma

Aunque se recomienda encarecidamente ( fuente W3C , vía Wikipedia ) que los servidores web admitan el punto y coma como un separador de elementos de consulta de 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, el punto y coma es, o era en el momento de escribir este texto , tratado como un carácter de cadena normal, como si la URL fuera: http://www.google.com/search?q=nemo% 3B oe = utf-8 )

Aunque la primera biblioteca de análisis de URL que probé, 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 del servidor y del cliente)

La Recomendación W3C de 1999 es obsoleta. El estado actual, de acuerdo con la Recomendación W3C 2014 , es que el punto y coma ahora es ilegal como separador de parámetros:

Para decodificar application / x-www-form-urlencoded payloads, se debe usar el siguiente algoritmo. […] El resultado de este algoritmo es una lista ordenada de pares nombre-valor. […]

  1. Permita que las cadenas sean el resultado de dividir estrictamente la carga útil de cadena en U + 0026 AMPERSAND caracteres (&).

En otras palabras ?foo=bar;baz significa que el parámetro foo tendrá la bar;baz valor bar;baz ; mientras que ?foo=bar;baz=sna debería resultar en foo siendo bar;baz=sna (aunque técnicamente ilegal ya que el segundo = debería escaparse a %3D ).

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 dijiste, la especificación W3C está de tu lado :

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.

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 (p. Ej., http://www.host.com/?x=1&y=2 ). En este contexto, el signo y entra en conflicto con el sistema de referencias a entidades 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 a ; es un delimitador de campo igualmente válido, a pesar de que los navegadores web utilizan universalmente 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 los 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 todos ya están cambiando el ampersand a & en lugar de ; ?

En resumen, HTML es un gran desastre (debido a su indulgencia), y el uso de punto y coma ayuda a simplificarlo MUCHO. 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 progtwigdor de .NET y que yo sepa, .NET no permite intrínsecamente ‘;’ 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 para quizás persuadir a otros desarrolladores respetables que aún no reconocen el valor de usar puntos y comas:

Usar una cadena de consulta como ‘? A = 1 & b = 2’ en una página HTML es incorrecta (sin encoding HTML 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 encoding 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 prejuicios 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 disputar correctamente cuando se tiene en cuenta toda la imagen. En resumen, usar 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 que el cambio palidezca en comparación con la dificultad continua de continuar usando &.

Utilizando ; como un separador QueryString lo hace MUCHO más simple. Los separadores de pares de símbolos son más del doble de difíciles de 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 pasos de encoding separados necesarios para codificar correctamente una QueryString cuando & es el separador:

  • Paso 1: URL codifica las claves y los valores de la cadena de consulta.
  • Paso 2: Concatenar las claves y los valores como ‘a = 1 & b = 2’ después de que estén codificados en URL desde el paso 1.
  • Paso 3: Luego HTML codifica toda QueryString en el código fuente HTML de la página.

Por lo tanto, la encoding especial debe realizarse dos veces para una encoding URL correcta (sin errores), y no solo eso, pero las codificaciones son dos tipos de encoding diferentes y diferentes. El primero es una encoding URL y el segundo es una encoding 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 encoding de entidad de caracteres XML (que es casi idéntica). Mi punto es que la última encoding 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 uno espera:

  • 1: URL codifica las claves y valores,
  • 2: concatenar los valores juntos. (Sin encoding para el paso 3)

Creo que la mayoría de los desarrolladores web se saltan el paso 3 porque los navegadores son tan 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 escribo el marcado de documentación XML en mi código fuente tanto en C # como en VB.NET. Como y debo 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 encoding del paso n. ° 3 también prolifera en otras aplicaciones.

Entonces en resumen, usando el; 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 encoding.

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.