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


907

¿Son necesarias las etiquetas CDATA en las etiquetas de script y, en caso afirmativo, 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>

18
Ahora que XHTML está esencialmente muerto, ¿ya no es una preocupación relevante?
allyourcode

80
@allyourcode: ¿qué te hace pensar que XHTML está muerto? HTML5? Hay XHTML5 para ir junto con él :)
Doktor J

44
@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 insertar los espacios de nombres xform, xlink, time y svg en 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 caído o se haya vuelto obsoleto, pero no está planeado en un futuro próximo.
Mihai Stancu

14
XHTML no está muerto en el desarrollo Java Seam / JSF / Facelets.
JoJo

15
@Mihai Stancu: eso no es del todo correcto. Según el W3C, existe una sintaxis XML para HTML5 : "La otra sintaxis que se puede usar para HTML5 es XML. Esta sintaxis es compatible con documentos e implementaciones XHTML1. Los documentos que usan esta sintaxis deben ser entregados con un tipo de medio XML y elementos necesarios se colocará en el espacio de nombres w3.org/1999/xhtml siguiendo las reglas establecidas por las especificaciones XML ".
BrainSlugs83

Respuestas:


585

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 caracteres 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, es probable que desee utilizar una sección CDATA.

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

Para una buena redacción sobre el tema, consulte https://web.archive.org/web/20140304083226/http://javascript.about.com/library/blxhtml.htm


48
Hay mucho más que simplemente "validación". Los analizadores XML más estrictos no pasarán por la página si tocan un carácter ilegal. Se trata más que simplemente de hacer feliz al W3C y volverse verde en lugar de rojo.
Loren Segal

40
Si se evitan &y <personajes, que no es necesario 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, por ejemplo. inicializar variables (escapar &/ <a \x26/ \x3Cen literales de cadena si es necesario).
bobince

23
¿Qué pasa en el caso de HTML5?
Mathew Attlee

55
@ Matthew 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.
Alex KeySmith

3
@Loren: Entonces todavía se trata completamente de validación. La medida en que un agente de usuario rechaza XML inválido es ortogonal.
Carreras de ligereza en órbita

231

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>

12
Solo como una 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

¿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".
Matt Wilkie

@mattwilkie, lo que quiero decir con "como XML" es "cuando los navegadores usan su analizador XML (en oposición al 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 ".
Shadow2531

127

HTML

Un analizador 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 " </", lo cual es correcto según las especificaciones .

Actualización en HTML5, y con los navegadores actuales, ese ya no es el caso.

Entonces, en HTML, esto no es posible:

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

Una CDATAsección no tiene ningún efecto . Por eso 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 principalmente cierto).

XML

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

Para el analizador XML, una scriptetiqueta no es mejor que cualquier otra etiqueta. Particularmente, 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 evitar esto, puede ajustar 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 ajustarlas en comentarios.

Si su script no contiene ningún " <" o " &", no necesita una CDATAsección de todos modos.


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
danorton

3
@danorton Interesante. Creo que es una mezcla bastante fea. Sin embargo, todavía no tiene efecto en el contenido del script.
user123444555621

2
No sabía que ninguna </ etiqueta de script interna es mala.
Salman A

3
@SalmanA Esa es una de las rarezas de HTML y oficialmente llamada ETAGO . Obtenga más información: mathiasbynens.be/notes/etago (aunque el artículo establece que ningún navegador implementó esa característica, estoy bastante seguro de que me causó algunos problemas. Quizás en alguna otra herramienta)
user123444555621

1
En realidad, me encontré con problemas de validación; <script>var b = "<b>bold</b>";</script>no puedo validar, pero después de leer su respuesta y cambiar para <script>var b = "<b>bold<\/b>";</script>solucionarlo.
Salman A

30

Básicamente es permitir escribir un documento que sea XHTML y HTML. El problema es que dentro de XHTML, el analizador XML interpretará los caracteres &, <,> en la etiqueta del script y causará un error de análisis XML. Por lo tanto, 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, el script de etiqueta se considera CDATA 'por defecto', y dicho JavaScript no se ejecutará. Por lo tanto, si desea que la misma página esté bien tanto con los analizadores XHTML como HTML, debe encerrar la etiqueta del script en el elemento CDATA en XHTML, pero NO encerrarla 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 X (HT) ML. Cuando utiliza símbolos como <y >dentro del JavaScript, por ejemplo, para comparar dos enteros, esto debería analizarse como XML, por lo que se marcarían como un principio o un final de una etiqueta.

El CDATA significa que las siguientes líneas (todo hasta el ]]>no es XML y, por lo tanto, no deben 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>.


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.
Loren Segal

17

Para garantizar que la validación XHTML funciona correctamente cuando tiene JavaScript incrustado en su página, en lugar de hacer referencia externamente.

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 envolverlo en CDATA para asegurarse de que la validación no lo marque como malformado.

Con las páginas HTML en la web, puede incluir el JavaScript requerido entre y etiquetas. Cuando valida el HTML en su página web, el contenido de JavaScript se considera CDATA (datos de caracteres) que, por lo tanto, el validador ignora. Lo mismo no es cierto si sigue los estándares XHTML más recientes al configurar su página web. Con XHTML, el código entre las etiquetas de script se considera PCDATA (datos de caracteres analizados) que, por lo tanto, es procesado por el validador.

Debido a esto, no puede simplemente incluir JavaScript entre las etiquetas de script en su página sin 'romper' su página web (al menos en lo que respecta al validador).

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



9

Cuando se trata de un cumplimiento estricto de XHTML, necesita el CDATA por lo tanto, y los símbolos no se marcan como caracteres no válidos.



8

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


6

CDATA indica que los contenidos dentro no son XML.




2

De esa manera, los navegadores más antiguos no analizan el código Javascript y la página no se rompe.

Compatibilidad con versiones anteriores. Voy a amarlo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.