¿Cuándo es necesaria una sección CDATA dentro de una etiqueta de secuencia de comandos?

942

¿Son necesarias las etiquetas CDATA en las etiquetas de secuencia de comandos y, de ser así, cuándo?

En otras palabras, cuándo y dónde es esto:

<script type="text/javascript">
//<![CDATA[
...code...
//]]>
</script>

preferible a esto:

<script type="text/javascript">
...code...
</script>
11
  • 20
    Ahora que XHTML está esencialmente muerto, ¿ya no es una preocupación relevante? 30/01/12 a las 21:49
  • 84
    @allyourcode: ¿qué te hace pensar que XHTML está muerto? HTML5? Hay XHTML5 para acompañarlo :) 22/02/12 a las 14:42
  • 4
    @DoktorJ AFAIK xHTML estaba en la versión 1. Su equivalente en HTML era la versión 4. Hubo un esfuerzo concentrado en xHTML 2.0 con la intención de llevar los espacios de nombres xform, xlink, time y svg a la especificación como una forma de mejorar las mismas características que HTML 5 agregando - xform / input-validation, time / animations, svg / canvas - pero los esfuerzos para la especificación xHTML 2 se reorientaron hacia las características de HTML 5. Eso no quiere decir que xHTML 2 se haya eliminado o se haya vuelto obsoleto, pero no está planeado para un futuro próximo. 3 de agosto de 2012 a las 11:08
  • 14
    XHTML no está muerto en el desarrollo de Java Seam / JSF / Facelets.
    JoJo
    30/08/12 a las 20:03
  • 17
    @Mihai Stancu, eso no es del todo correcto. Según W3C, existe una sintaxis XML para HTML5 : "La otra sintaxis que se puede utilizar para HTML5 es XML. Esta sintaxis es compatible con los documentos y las implementaciones XHTML1. Los documentos que utilizan esta sintaxis deben servirse con un tipo de medio XML y los elementos deben para colocarse en el espacio de nombres w3.org/1999/xhtml siguiendo las reglas establecidas por las especificaciones XML ". 11/10/12 a las 0:03
598

Se requiere una sección CDATA si necesita que su documento se analice como XML (por ejemplo, cuando una página XHTML se interpreta como XML) y desea poder escribir literal i<10y en a && blugar de i&lt;10ya &amp;&amp; b , ya que XHTML analizará el código JavaScript como datos de caracteres analizados. a diferencia de los datos de carácter por defecto. Esto no es un problema con los scripts que se almacenan en archivos de origen externos, pero para cualquier JavaScript en línea en XHTML probablemente querrá usar una sección CDATA.

Tenga en cuenta que muchas páginas XHTML nunca fueron diseñadas para ser analizadas como XML, en cuyo caso esto no será un problema.

Para obtener una buena reseña sobre el tema, consulte https://web.archive.org/web/20140304083226/http://javascript.about.com/library/blxhtml.htm

12
  • 50
    Hay mucho más que solo "validación". La mayoría de los analizadores XML estrictos no pasarán por la página si encuentran un carácter ilegal. Se trata de más que simplemente hacer feliz al W3C y ponerse verde en lugar de rojo. 15 de septiembre de 2008 a las 20:58
  • 42
    Si evita los caracteres &y <, no necesita una sección CDATA; funcionará bien tanto en HTML como en XHTML. Puede lograr esto fácilmente colocando todo el código significativo en scripts externos y simplemente usando scripts en línea para, por ejemplo,. inicialice las variables (escapando &/ <a \x26/ \x3Cen cadenas literales si lo necesita).
    bobince
    20 de sep. De 2009 a las 9:10
  • 24
    ¿Y en el caso de HTML5? 2 dic 2009 a las 11:44
  • 5
    @Mathew Attle: esta es una buena pregunta. Sea una gran pregunta para hacer en un hilo separado para asegurarse de que reciba la atención que necesita. 6/11/10 a las 19:01
  • 3
    @Loren: Entonces todavía se trata completamente de validación. La medida en que un usuario-agente rechaza XML no válido es ortogonal. 9 de junio de 2011 a las 18:09
236

Cuando los navegadores tratan el marcado como XML:

<script>
<![CDATA[
    ...code...
]]>
</script>

Cuando los navegadores tratan el marcado como HTML:

<script>
    ...code...
</script>

Cuando los navegadores tratan el marcado como HTML y desea que su marcado XHTML 1.0 (por ejemplo) se valide.

<script>
//<![CDATA[
    ...code...
//]]>
</script>
3
  • 13
    Solo como cuestión de seguridad del código, es mejor rodear sus CDATA con comentarios de bloque /* ... */porque de lo contrario, si se eliminan los saltos de línea, el código se romperá.
    BryanH
    3 de noviembre de 2015 a las 20:05
  • ¿No debería "... como XML" en la primera sección ser "... como texto no interpretado"? En stackoverflow.com/questions/2784183/what-does-cdata-in-xml-mean vemos "... estas cadenas incluyen datos que podrían interpretarse como marcado XML, pero no deberían serlo". 31/01/2017 a las 20:38
  • @mattwilkie, lo que quiero decir con "como XML" es "Cuando los navegadores usan su analizador XML (a diferencia del analizador HTML) para analizar el marcado porque el documento se envió con un tipo mime basado en XML o el archivo que contiene el marcado tiene una extensión de archivo basada en XML ". 1 feb 2017 a las 12:07
134

HTML

Un analizador de HTML tratará todo entre <script>y </script>como parte del script. Algunas implementaciones ni siquiera necesitan una etiqueta de cierre correcta; detienen la interpretación del guión en " </", que es correcto de acuerdo con las especificaciones .

Update In HTML5, and with current browsers, that is not the case anymore.

Entonces, en HTML, esto no es posible:

<script>
var x = '</script>';
alert(x)
</script>

Una CDATAsección no tiene ningún efecto . Es por eso que necesitas escribir

var x = '<' + '/script>'; // or
var x = '<\/script>';

o similar.

Esto también se aplica a los archivos XHTML servidos como text/html. (Dado que IE no admite tipos de contenido XML, esto es mayormente cierto).

XML

En XML, se aplican diferentes reglas. Tenga en cuenta que los navegadores (que no son IE) solo usan un analizador XML si el documento XHMTL se entrega con un tipo de contenido XML.

Para el analizador XML, una scriptetiqueta no es mejor que cualquier otra etiqueta. En particular, un nodo de secuencia de comandos puede contener nodos secundarios sin texto, activados por " <"; y un &signo " " denota una entidad de carácter.

Entonces, en XHTML, esto no es posible:

<script>
if (a<b && c<d) {
    alert('Hooray');
}
</script>

Para solucionar este problema, puede envolver todo el script en una CDATAsección. Esto le dice al analizador: 'En esta sección, no trate " <" y " &" como caracteres de control '. Para evitar que el motor de JavaScript interprete las marcas " <![CDATA[" y " ]]>", puede envolverlas en comentarios.

Si su secuencia de comandos no contiene " <" o " &", no necesita una CDATAsección de todos modos.

7
  • 2
    La afirmación "Una sección CDATA no tiene ningún efecto" no es cierta para (el propuesto) HTML5, que reconoce la construcción. w3.org/TR/html5/syntax.html#cdata-sections 6/03/12 a las 20:29
  • 3
    @danorton Interesante. Creo que es una mezcla bastante fea. Sin embargo, todavía no hay efecto en el contenido del guión. 6 mar 12 a las 22:06
  • 2
    No sabía que las </ etiquetas de script internas son malas. 5 de marzo de 2013 a las 18:38
  • 3
    @SalmanA Esa es una de las rarezas de HTML y se llama oficialmente ETAGO . Obtenga más información: mathiasbynens.be/notes/etago (aunque el artículo afirma que ningún navegador implementó esa función, estoy bastante seguro de que me causó algunos problemas. Tal vez en alguna otra herramienta) 5/0313 a las 20:35
  • 1
    En realidad, me encontré con problemas de validación: <script>var b = "<b>bold</b>";</script>no se valida, pero después de leer su respuesta y cambiar para <script>var b = "<b>bold<\/b>";</script>solucionarlo. 5/0313 a las 21:52
31

Básicamente es para permitir escribir un documento que sea tanto XHTML como HTML. El problema es que dentro de XHTML, el analizador XML interpretará los caracteres &, <,> en la etiqueta del script y provocará un error de análisis XML. Entonces, puede escribir su JavaScript con entidades, por ejemplo:

if (a &gt; b) alert('hello world');

Pero esto no es práctico. El mayor problema es que si lee la página en HTML, la secuencia de comandos de la etiqueta se considera CDATA 'por defecto' y dicho JavaScript no se ejecutará. Por lo tanto, si desea que la misma página esté bien usando analizadores de XHTML y HTML, debe incluir la etiqueta de secuencia de comandos en el elemento CDATA en XHTML, pero NO en HTML.

Este truco marca el inicio de un elemento CDATA como un comentario de JavaScript; en HTML, el analizador de JavaScript ignora la etiqueta CDATA (es un comentario). En XHTML, el analizador XML (que se ejecuta antes que JavaScript) lo detecta y trata el resto hasta el final de CDATA como CDATA.

24

Es una cosa de X (HT) ML. Cuando usa símbolos como <y >dentro de JavaScript, por ejemplo, para comparar dos enteros, esto tendría que ser analizado como XML, por lo que se marcarían como el principio o el final de una etiqueta.

El CDATA significa que las siguientes líneas (todo hasta el ]]>no es XML y, por lo tanto, no debe analizarse de esa manera.

18

No , no utilizar CDATA en HTML 4, pero se debe utilizar CDATA en XHTML y debe utilizar CDATA en XML si tiene símbolos sin escape como <y>.

1
  • 11
    CDATA no es válido en HTML4. En pocas palabras, no es parte de la gramática. CDATA es una sintaxis de XML y XHTML es un subconjunto de XML. Por lo tanto, solo debe usarse dentro de XML (y sus subconjuntos). HTML, por otro lado, no es XML. 30 de agosto de 2010 a las 3:59
17

Es para garantizar que la validación XHTML funcione correctamente cuando tiene JavaScript incrustado en su página, en lugar de hacer referencia externa.

XHTML requiere que su página cumpla estrictamente con los requisitos de marcado XML. Dado que JavaScript puede contener caracteres con un significado especial, debe incluirlo en CDATA para asegurarse de que la validación no lo marque como incorrecto.

With HTML pages on the web you can just include the required JavaScript between and tags. When you validate the HTML on your web page the JavaScript content is considered to be CDATA (character data) that is therefore ignored by the validator. The same is not true if you follow the more recent XHTML standards in setting up your web page. With XHTML the code between the script tags is considered to be PCDATA (parsed character data) which is therefore processed by the validator.

Because of this, you can't just include JavaScript between the script tags on your page without 'breaking' your web page (at least as far as the validator is concerned).

Puede obtener más información sobre CDATA aquí y más sobre XHTML aquí .

11

CDATA indica que el contenido no es XML.

Aquí hay una explicación en wikipedia.

9

Cuando busca un cumplimiento estricto de XHTML, necesita el CDATA, por lo que menos que y los símbolos de unión no se marcan como caracteres no válidos.

8

para evitar errores xml durante la validación xhtml.

8

CDATA le dice al navegador que muestre el texto tal cual y que no lo represente como HTML.

5

CDATA indica que el contenido no es XML.

5

CDATA es necesario en cualquier dialecto XML, porque el texto dentro de un nodo XML se trata como un elemento secundario antes de ser evaluado como JavaScript. Esta es también la razón por la que JSLint se queja del <carácter en las expresiones regulares.

Referencias

2

Cuando quieras que se valide (en XML / XHTML - gracias, Loren Segal ).

0
2

De esa manera, el navegador más antiguo no analiza el código Javascript y la página no se rompe.

Compatibilidad con versiones anteriores. Voy a amarlo.