XHTML y Y (Ampersand) codificación

Question

Mi sitio es XHTML Transición compatible excepto por una cosa: la & (comercial) en la URL están escritos como es, en lugar de &

Es decir, todas las URL en mis páginas son por lo general como esto:

<a href="http://www.foo.com/page.aspx?x=1&y=2">Foo</a> 

Pero XHTML validator genera este error:

cannot generate system identifier for general entity "y"

... y quiere que la URL que se escribe así:

<a href="http://www.foo.com/page.aspx?x=1&amp;y=2">Foo</a> 

El problema es que el IE y Firefox no manejan correctamente la URL e ignoran el parámetro y. ¿Cómo puedo hacer que este enlace funcione y valide correctamente?

Me parece que es imposible escribir páginas XHTML si los navegadores no funcionan con estrictas URL XHTML codificadas.

¿Quieres ver en acción? Ver la diferencia entre estos dos enlaces (copiar y pegar como son):

http://stackoverflow.com/search?q=ff&sort=newest 

y

http://stackoverflow.com/search?q=ff&sort=newest 

Answer 1

Acabo de probar esto. Lo que intentaste hacer es correcto. En HTML, si está escribiendo un enlace, los caracteres & deben codificarse como &. Solo codificaría & como %26 si desea que un valor de parámetro contenga un símbolo comercial. Acabo de escribir una página HTML simple que contenía un enlace: <a href="Default2.aspx?param1=63&amp;param2=hel">Click me</a> y funcionó bien: default2.aspx recibió los parámetros previstos y la fuente pasó la validación.

Se requiere la codificación de & como & en HTML, no en el enlace. Cuando el navegador ve el & en la fuente HTML de un enlace, lo interpretará como un símbolo y el objetivo del enlace será el deseado.Si pega una URL en la barra de direcciones de su navegador, no espera que sea HTML y no intenta interpretar ninguna codificación HTML que pueda contener. Esta es la razón por la que los enlaces de ejemplo que sugiere que deberíamos copiar/pegar en un navegador no funcionan y por qué no esperamos que funcionen.

Si publica un poco más de su código real, podremos ver lo que ha hecho mal, pero parece que va en la dirección correcta al usar & en sus etiquetas de anclaje.

Answer 2

se podría utilizar en lugar de & & en su url dentro de su página.

Esto debería permitir que sea validada una XHTML Strict ...

<a href="http://www.foo.com/page.aspx?x=1&amp;y=2">Foo</a> 

Nota, si se usa por una función de ASP.NET Request.QueryString, la cadena de consulta no utiliza la codificación XML, se utiliza URL encoding:

/mypath/mypage?b=%26stuff 

lo que necesita para proporcionar una función de traducción '&' en 26%

Nota: en ese caso, Server.URLEncod e ("neetu & geetu"), que produciría neetu +% 26 + geetu, no es lo que desea, ya que necesita traducir & en% 26, no solo '&'. Debe agregar una llamada a replace() aplicada al resultado URLEncode, para reemplazar '% 26amp;' por '% 26'.

Answer 3

que era mi culpa: el control de hipervínculo ya codificada &, por lo que mi url http://foo?x=1&y=2 fue codificado a http://foo?x=1&y=2

Normalmente el amplificador & dentro de la URL se maneja correctamente por los navegadores, como ha afirmado. Gracias

Answer 4

El problema es peor de lo que piensas, pruébalo en Safari. & amp; se convierte a & # 38; y el hash termina la URL. La respuesta correcta es no generar XHTML. No hay ninguna razón que justifique pasar más tiempo en el desarrollo y alienando a los usuarios de mac.

Answer 5

Para ser aún más exhaustivo: use &, referencia de caracteres numéricos.

Debido & es una entidad de referencia carácter:

Character entity references are defined in the markup language definition. This means, for example, that for HTML only a specific range of characters (defined by the HTML specification) can be represented as character entity references (and that includes only a small subset of the Unicode range).

que viene de los sabios en el W3C (leer this para más).

Por supuesto, esto no es un gran problema, pero la sugerencia de W3C es que el número será válido y utilizable en todas partes y siempre, mientras que el nombre es "bueno" para HTML, pero nada más.