Quando è necessaria una sezione CDATA all'interno di un tag script?

I tag CDATA sono mai necessari nei tag script e, in caso affermativo, quando?

In altre parole, quando e dove si trova questo:

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

preferibile a questo:

<script type="text/javascript">
...code...
</script>

È necessaria una sezione CDATA se è necessario che il documento analizzi come XML (ad esempio quando una pagina XHTML è interpretata come XML) e si desidera poter scrivere letteralmente i<10e a && binvece di i<10ea && b , poiché XHTML analizzerà il codice JavaScript come dati di carattere analizzati al contrario dei dati dei personaggi per impostazione predefinita. Questo non è un problema con gli script archiviati in file di origine esterni, ma per qualsiasi JavaScript inline in XHTML probabilmente vorrai usare una sezione CDATA.

Si noti che molte pagine XHTML non sono mai state concepite per essere analizzate come XML, nel qual caso questo non sarà un problema.

Per un buon approfondimento sull'argomento, consultare https://web.archive.org/web/20140304083226/http://javascript.about.com/library/blxhtml.htm

Quando i browser trattano il markup come XML:

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

Quando i browser trattano il markup come HTML:

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

Quando i browser trattano il markup come HTML e si desidera validare il markup XHTML 1.0 (ad esempio).

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

HTML

Un parser HTML tratterà tutto tra <script>e </script>come parte dello script. Alcune implementazioni non hanno nemmeno bisogno di un tag di chiusura corretto; interrompono l'interpretazione dello script in " </", che è corretto secondo le specifiche .

Aggiornamento In HTML5, e con i browser attuali, non è più così.

Quindi, in HTML, questo non è possibile:

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

Una CDATAsezione non ha alcun effetto . Ecco perché devi scrivere

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

o simili.

Questo vale anche per i file XHTML serviti come text/html. (Poiché IE non supporta i tipi di contenuto XML, questo è principalmente vero.)

XML

In XML, si applicano regole diverse. Si noti che i browser (non IE) utilizzano un parser XML solo se il documento XHMTL è offerto con un tipo di contenuto XML.

Per il parser XML, un scripttag non è migliore di qualsiasi altro tag. In particolare, un nodo di script può contenere nodi secondari non di testo, attivati ​​da " <"; e un &segno " " indica un'entità personaggio.

Quindi, in XHTML, questo non è possibile:

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

Per ovviare a questo, è possibile avvolgere l'intero script in una CDATAsezione. Questo dice al parser: 'In questa sezione, non trattare " <" e " &" come caratteri di controllo . " Per impedire al motore JavaScript di interpretare i segni " <![CDATA[" e " ]]>", puoi racchiuderli nei commenti.

Se il tuo script non contiene " <" o " &", non hai comunque bisogno di una CDATAsezione.

Fondamentalmente è per consentire di scrivere un documento che è sia XHTML che HTML. Il problema è che all'interno di XHTML, il parser XML interpreterà i caratteri &, <,> nel tag script e causerà un errore di analisi XML. Quindi, puoi scrivere JavaScript con entità, ad esempio:

if (a > b) alert('hello world');

Ma questo non è pratico. Il problema più grande è che se leggi la pagina in HTML, lo script di tag è considerato CDATA "per impostazione predefinita" e tale JavaScript non verrà eseguito. Pertanto, se si desidera che la stessa pagina sia OK sia utilizzando i parser XHTML che HTML, è necessario racchiudere il tag di script nell'elemento CDATA in XHTML, ma NON racchiuderlo in HTML.

Questo trucco segna l'inizio di un elemento CDATA come commento JavaScript; in HTML il parser JavaScript ignora il tag CDATA (è un commento). In XHTML, il parser XML (che viene eseguito prima di JavaScript) lo rileva e considera il resto fino alla fine di CDATA come CDATA.

È una cosa X (HT) ML. Quando si utilizzano simboli come <e >all'interno di JavaScript, ad esempio per confrontare due numeri interi, questo dovrebbe essere analizzato come XML, in modo da contrassegnare come inizio o fine di un tag.

Il CDATA significa che le seguenti righe (tutto fino a ]]>non è XML e quindi non dovrebbero essere analizzate in questo modo.

Do Non utilizzare CDATA in HTML4, ma si dovrebbe usare CDATA in XHTML e devono utilizzare CDATA in XML se si dispone di simboli escape come <e>.

Garantisce che la convalida XHTML funzioni correttamente quando JavaScript è incorporato nella tua pagina, invece di fare riferimento esternamente.

XHTML richiede che la tua pagina sia rigorosamente conforme ai requisiti di markup XML. Poiché JavaScript può contenere caratteri con un significato speciale, è necessario inserirlo in CDATA per assicurarsi che la convalida non lo contrassegni come non valido.

Con le pagine HTML sul Web puoi semplicemente includere il JavaScript richiesto tra i tag e. Quando convalidi l'HTML sulla tua pagina web, il contenuto JavaScript viene considerato come CDATA (dati carattere) che viene quindi ignorato dal validatore. Lo stesso non è vero se segui gli standard XHTML più recenti nella configurazione della tua pagina web. Con XHTML il codice tra i tag di script è considerato PCDATA (dati di carattere analizzati) che viene quindi elaborato dal validatore.

Per questo motivo, non puoi semplicemente includere JavaScript tra i tag di script nella tua pagina senza "interrompere" la tua pagina web (almeno per quanto riguarda il validatore).

Puoi saperne di più su CDATA qui e di più su XHTML qui .

CDATA indica che i contenuti all'interno non sono XML.

Ecco una spiegazione su Wikipedia

Quando stai cercando una rigorosa conformità XHTML, hai bisogno del CDATA, quindi meno di e le e commerciali non sono contrassegnate come caratteri non validi.

per evitare errori xml durante la convalida xhtml.

CDATA dice al browser di visualizzare il testo così com'è e di non renderlo come HTML.

CDATA indica che i contenuti all'interno non sono XML.

CDATA è necessario in qualsiasi dialetto XML, poiché il testo all'interno di un nodo XML viene trattato come un elemento figlio prima di essere valutato come JavaScript. Questo è anche il motivo per cui JSLint si lamenta del <personaggio in regex.

Riferimenti

• Creazione di un linguaggio UI XML dichiarativo
• Il futuro del Web: Rich Client, Rich Browser, Rich Portals

Quando vuoi che venga convalidato (in XML / XHTML - grazie, Loren Segal ).

In questo modo il browser precedente non analizza il codice Javascript e la pagina non si interrompe.

Compatibilità all'indietro. Devi amarlo.