html - attribute - ¿Realmente necesito codificar ''&'' como ''& amp;''?

title html css (17)

Estoy usando un símbolo '' & '' con HTML5 y UTF-8 en el <title> mi sitio. Google muestra el ampersand fine en sus SERPs, al igual que todos los navegadores en sus títulos.

http://validator.w3.org/ me está dando esto:

& no comenzó una referencia de personaje. (y probablemente debería haberse escapado como & )

¿Realmente necesito hacer & ?

No me preocupa que mis páginas validen por el mero hecho de validar, pero tengo curiosidad por escuchar las opiniones de las personas sobre esto y si es importante y por qué.

¿Podrías mostrarnos cuál es tu title realidad? Cuando presento

<!DOCTYPE html> <html> <title>Dolce & Gabbana</title> <body> <p>am i allowed loose & mpersands?</p> </body> </html>

a http://validator.w3.org/ - pidiéndole explícitamente que use el modo experimental HTML 5 - no tiene quejas sobre el & s ...

Bueno, si proviene de la entrada del usuario, entonces sí, por razones obvias. Piense si este mismo sitio web no lo hizo: el título de esta pregunta aparecerá, ¿realmente necesito codificar ''&'' como ''&''?

Si es algo así como echo ''<title>Dolce & Gabbana</title>''; entonces estrictamente hablando, no es necesario. Sería mejor, pero si no lo hace, ningún usuario notará la diferencia.

Creo que esto se ha convertido en una cuestión más de "por qué seguir las especificaciones cuando a los navegadores no les importa". Aquí está mi respuesta generalizada:

Los estándares no son algo "presente". Son una cosa "futura". Si nosotros, como desarrolladores, seguimos los estándares web, entonces es más probable que los proveedores de navegadores implementen correctamente esos estándares, y nos acercamos a una web completamente interoperable, donde los hacks de CSS, detección de características y detección de navegadores no son necesarios. Donde no tenemos que descubrir por qué se rompen nuestros diseños en un navegador en particular, o cómo solucionarlo.

Específicamente, si HTML5 no requiere el uso de & amp; En su situación específica, y está usando un doctype HTML5 (y también espera que sus usuarios usen navegadores compatibles con HTML5), entonces no hay razón para hacerlo.

Dejando a un lado la validación, sigue siendo cierto que la codificación de ciertos caracteres es importante para un documento HTML, por lo que puede representarse de forma correcta y segura como una página web.

Codificación & como & bajo todas las circunstancias, para mí, es una regla más fácil de vivir, reduciendo la probabilidad de errores y fallas.

Compare lo siguiente: ¿cuál es más fácil? ¿ Cuál es más fácil de molestar ?

Metodología 1

Escribe un contenido que incluya caracteres y signos.
Codifícalos todos.

Metodología 2

(con un grano de sal, por favor;))

Escriba un contenido que incluya un ampersand caracteres.
En una base de caso por caso, mira cada uno de ellos. Determine si:
- Está aislado, y como tal, sin ambigüedades, un signo comercial. p.ej. volt & amp
  > En ese caso, no te molestes en codificarlo.
- No está aislado, pero sientes que no es ambiguo, ya que la entidad resultante no existe y nunca existirá, ya que la lista de entidades nunca podría evolucionar. por ejemplo amp&volt
  > En ese caso, no te molestes en codificarlo.
- No es aislado y ambiguo. p.ej. volt&amp
  > Codifícalo.

Depende de la probabilidad de que un punto y coma termine cerca de su & , causando que muestre algo bastante diferente.

Por ejemplo, cuando se trata de las aportaciones de los usuarios (por ejemplo, si incluye el tema proporcionado por el usuario de una publicación del foro en sus etiquetas de título), nunca se sabe dónde podrían estar poniendo puntos y coma al azar, y podría mostrar entidades extrañas al azar. Así que siempre escapa en esa situación.

Para su propio html estático, seguro, podría omitirlo, pero es tan trivial incluir el escape adecuado, que no hay una buena razón para evitarlo.

El enlace tiene un buen ejemplo de cuándo y por qué es posible que necesite escapar & a &

https://jsfiddle.net/vh2h7usk/1/

Curiosamente, tuve que escapar del personaje para representarlo correctamente en mi respuesta aquí. Si tuviera que usar la opción de muestra de código incorporada (desde el panel de respuestas), solo puedo escribir & y aparece como debería. Pero si tuviera que usar manualmente el elemento <code></code> , entonces tengo que escapar para representarlo correctamente :)

En HTML a & marca el comienzo de una referencia, ya sea de una referencia de personaje o de una entidad . A partir de ese momento, el analizador espera un # denote una referencia de carácter, o un nombre de entidad que denote una referencia de entidad, ambos seguidos por a ; . Ese es el comportamiento normal.

Pero si el nombre de referencia o solo la abertura de referencia & es seguido por un espacio en blanco u otros delimitadores como " , '' , < , > , & , la terminación ; e incluso una referencia para representar un plano & se puede omitir:

<p title="&">foo & bar</p> <p title="&amp">foo &amp bar</p> <p title="&">foo & bar</p>

Solo en estos casos el final ; o incluso la referencia misma puede omitirse (al menos en HTML 4). Creo que HTML 5 requiere el final ; .

Pero la especificación recomienda usar siempre una referencia como la referencia de personaje & o la referencia de la entidad & para evitar confusión:

Los autores deben usar " & " (ASCII decimal 38) en lugar de " & " para evitar confusiones con el comienzo de una referencia de caracteres (delimitador abierto de referencia de entidad). Los autores también deben usar " & " en los valores de los atributos ya que las referencias de caracteres están permitidas dentro de los valores de los atributos CDATA.

Estaba comprobando por qué la URL de la imagen necesita escaparse, por lo tanto, lo probé en https://validator.w3.org . La explicación es bastante buena. Resalta que incluso las URL deben ser escapadas. [PD: supongo que se desaparece cuando se consume desde la necesidad de URL & . ¿Alguien puede aclarar?]

<img alt="" src="foo?bar=qut&qux=fop" />

Se encontró una referencia de entidad en el documento, pero no se definió ninguna referencia por ese nombre. A menudo, esto se debe a un error de ortografía en el nombre de referencia, los signos de unión no codificados o al dejar fuera el punto y coma (;). La causa más común de este error es el uso de signos y símbolos no codificados en las URL tal como lo describe el WDG en "Símbolos en las URL". Las referencias de entidades comienzan con un símbolo de unión (&) y terminan con un punto y coma (;). Si desea utilizar un símbolo literal en su documento, debe codificarlo como "&" (¡incluso dentro de las URL!). Tenga cuidado de terminar las referencias de entidad con un punto y coma o la referencia de su entidad puede interpretarse en relación con el siguiente texto. También tenga en cuenta que las referencias a entidades nombradas distinguen entre mayúsculas y minúsculas; Y Aelig; y æ son diferentes personajes. Si este error aparece en alguna etiqueta generada por el código de manejo de sesión de PHP, este artículo tiene explicaciones y soluciones para su problema.

Hace un par de años, obtuvimos un informe de que una de nuestras aplicaciones web no se mostraba correctamente en Firefox. Resultó que la página contenía una etiqueta que parecía

<div style="..." ... style="...">

Cuando se enfrenta con un atributo de estilo repetido, IE combina ambos estilos, mientras que Firefox solo usa uno de ellos, de ahí el comportamiento diferente. Cambié la etiqueta a

<div style="...; ..." ...>

y efectivamente, ¡resolvió el problema! La moraleja de la historia es que los navegadores tienen un manejo más consistente del HTML válido que del HTML no válido. ¡Así que arregla tu maldito marcado ya! (O use HTML Tidy para solucionarlo).

Investigué esto a fondo y escribí sobre mis hallazgos aquí: mathiasbynens.be/notes/ambiguous-ampersands

También creé una herramienta en línea que puede usar para verificar el marcado en símbolos ampersands ambiguos o referencias de caracteres que no terminan con un punto y coma, ninguno de los cuales es válido. (Ningún validador de HTML hace esto correctamente).

Las reglas de HTML5 son diferentes de HTML4. No es necesario en HTML5, a menos que el signo "&" parezca que comienza un nombre de parámetro. "& copy = 2" sigue siendo un problema, por ejemplo, desde & copy; es el símbolo de copyright.

Sin embargo, me parece que es más difícil decidir si codificar o no codificar según el siguiente texto. Entonces, la ruta más fácil es codificar todo el tiempo.

Sí, debes intentar mostrar un código válido si es posible.

La mayoría de los navegadores corregirá silenciosamente este error, pero existe un problema al confiar en el manejo de errores en los navegadores. No existe un estándar para la forma de manejar el código incorrecto, por lo que depende de cada proveedor de navegador intentar averiguar qué hacer con cada error, y los resultados pueden variar.

Algunos ejemplos donde es probable que los navegadores reaccionen de manera diferente es si coloca elementos dentro de una tabla pero fuera de las celdas de la tabla, o si anida enlaces dentro de la otra.

Para su ejemplo específico, no es probable que cause ningún problema, pero la corrección de errores en el navegador podría hacer que el navegador cambie del modo compatible con los estándares al modo peculiar, lo que podría hacer que su diseño se rompa por completo.

Por lo tanto, debe corregir errores como este en el código, si no fuera por algo más, para mantener corta la lista de errores en el validador, de modo que pueda detectar problemas más serios.

Sí. Tal como decía el error, en HTML, los atributos son #PCDATA, lo que significa que están analizados. Esto significa que puede usar entidades de caracteres en los atributos. El uso de & por sí mismo es incorrecto y si no fuera por navegadores indulgentes y el hecho de que esto es HTML no XHTML, rompería el análisis sintáctico. Solo escapéalo como & y todo estaría bien.

HTML5 le permite dejarlo sin guardar, pero solo cuando los datos que siguen no se parecen a una referencia de caracteres válida. Sin embargo, es mejor escapar de todas las instancias de este símbolo que preocuparse por cuáles deberían ser y cuáles no.

Mantenga este punto en mente; si no está escapando & & amp ;, es lo suficientemente malo para los datos que crea (donde el código podría no ser válido), es posible que tampoco esté escapando los delimitadores de etiquetas, que es un gran problema para los datos enviados por el usuario, que bien podría conducir a la inyección de HTML y script, robo de cookies y otros exploits.

Por favor, solo escapa de tu código. Le ahorrará muchos problemas en el futuro.

Si el usuario se lo transfiere o terminará en una URL, debe escapar.

Si aparece en texto estático en una página? Todos los navegadores obtendrán este derecho de cualquier manera, no te preocupes mucho, ya que funcionará.

no estoy seguro de si esto es útil para alguien ... Estuve peleando esto por un tiempo ... aquí hay una gloriosa expresión regular que puedes usar para arreglar todos tus enlaces, javascript, contenido. Tuve que lidiar con una tonelada de contenido heredado que nadie quería corregir.

Agregue esto a su anulación de Render en su página maestra o control:

Por favor no me llame por poner esto en el lugar equivocado:

// remove the & from href="blaw?a=b&b=c" and replace with & //in urls - this corrects any unencoded & not just those in URL''s // this match will also ignore any matches it finds within <script> blocks AND // it will also ignore the matches where the link includes a javascript command like // <a href="javascript:alert{''& & &''}">blaw</a> html = Regex.Replace(html, "&(?!(?<=(?<outerquote>[/"''])javascript:(?>(?!//k<outerquote>|[>]).)*)//k<outerquote>?)(?!(?:[a-zA-Z][a-zA-Z0-9]*|#//d+);)(?!(?>(?:(?!<script|///script>).)*)///script>)", "&", RegexOptions.Singleline | RegexOptions.IgnoreCase);

si & se usa en html, entonces deberías escapar

If & se utiliza en cadenas de javascript, por ejemplo, una alert(''This & that''); o document.href no es necesario que lo use.

Si está utilizando document.write, entonces debe usarlo, por ejemplo document.write(<p>this & that</p>)

Si realmente estás hablando del texto estático

<title>Foo & Bar</title>

almacenado en algún archivo en el disco duro y servido directamente por un servidor, entonces sí: probablemente no necesite ser escapado.

Sin embargo, dado que actualmente hay muy poco contenido HTML completamente estático, agregaré la siguiente exención de responsabilidad que supone que el contenido HTML se genera a partir de otra fuente (contenido de la base de datos, entrada del usuario, resultado de la llamada al servicio web, resultado API heredado). ..):

Si no escapa de un & simple, entonces es probable que tampoco escape de un & o a   o <b> o <script src="http://attacker.com/evil.js"> o cualquier otro texto inválido. Eso significa que, en el mejor de los casos, muestra su contenido incorrectamente y es más probable que sea sospechoso de ataques XSS .

En otras palabras: cuando ya está revisando y escapando de los otros casos más problemáticos, entonces no hay casi ninguna razón para dejar el autónomo no totalmente roto, pero todavía algo sospechoso, sin protección.