Quando é necessária uma seção CDATA em uma tag de script?


907

As tags CDATA são sempre necessárias nas tags de script e, se sim, quando?

Em outras palavras, quando e onde é isso:

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

preferível a isso:

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

18
Agora que o XHTML está essencialmente morto, isso não é mais uma preocupação relevante?
precisa saber é o seguinte

80
@allyourcode: o que faz você pensar que o XHTML está morto? HTML5? Há XHTML5 para ir junto com ele :)
Doktor J

4
@DoktorJ O AFAIK xHTML estava na versão 1. É equivalente a HTML na versão 4. Houve um esforço concentrado no xHTML 2.0 com a intenção de inserir os namespaces xform, xlink, time e svg nas especificações, como uma maneira de melhorar os mesmos recursos que o HTML 5 adicionando - xform / validação de entrada, tempo / animações, svg / canvas - mas os esforços para as especificações do xHTML 2 foram reorientados para os recursos do HTML 5. Isso não quer dizer que o xHTML 2 foi descartado ou ficou obsoleto, mas não está planejado no futuro próximo.
Mihai Stancu 03/08/2012

14
XHTML não está morto no desenvolvimento Java Seam / JSF / Facelets.
JoJo

15
@ Mihai Stancu - isso não está totalmente correto. De acordo com o W3C, existe uma sintaxe XML para HTML5 : "A outra sintaxe que pode ser usada para HTML5 é XML. Essa sintaxe é compatível com documentos e implementações XHTML1. Os documentos que usam essa sintaxe precisam ser atendidos com um tipo de mídia XML e os elementos precisam para ser colocado no espaço de nome w3.org/1999/xhtml, seguindo as regras definidas pelas especificações XML ".
BrainSlugs83

Respostas:


585

Uma seção CDATA é necessária se você precisar que seu documento analise como XML (por exemplo, quando uma página XHTML for interpretada como XML) e desejar poder escrever literalmente, i<10e a && bnão i&lt;10ea &amp;&amp; b , pois XHTML analisará o código JavaScript como dados de caracteres analisados por oposição aos dados de caracteres por padrão. Isso não é um problema com scripts armazenados em arquivos de origem externos, mas para qualquer JavaScript embutido em XHTML, você provavelmente desejará usar uma seção CDATA.

Observe que muitas páginas XHTML nunca foram planejadas para serem analisadas como XML; nesse caso, isso não será um problema.

Para uma boa descrição sobre o assunto, consulte https://web.archive.org/web/20140304083226/http://javascript.about.com/library/blxhtml.htm


48
Há muito mais do que apenas "validação". A maioria dos analisadores XML estritos não passará pela página se atingir um caractere ilegal. É mais do que simplesmente fazer o W3C feliz e ficar verde em vez de vermelho.
Loren Segal

40
Se você evitar &e <personagens, você não precisa de uma seção CDATA; funcionará bem em HTML e XHTML. Você pode conseguir isso facilmente colocando todo o código significativo em scripts externos e usando scripts embutidos para, por exemplo. inicialize variáveis ​​(escape &/ <para \x26/ \x3Cem literais de string, se necessário).
bobince

23
E no caso do HTML5?
Mathew Attlee

5
@ Matthew Attle - esta é uma boa pergunta. Faça uma ótima pergunta em um tópico separado para garantir que ele receba a atenção necessária.
Alex KeySmith #

3
@ Loren: Então ainda é completamente sobre validação. A extensão em que um agente do usuário rejeita XML inválido é ortogonal.
Lightness Races in Orbit

231

Quando os navegadores tratam a marcação como XML:

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

Quando os navegadores tratam a marcação como HTML:

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

Quando os navegadores tratam a marcação como HTML e você deseja que sua marcação XHTML 1.0 (por exemplo) seja validada.

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

12
Assim como uma questão de segurança de código, é melhor para cercar seus CDATAs com comentários em bloco /* ... */, porque caso contrário, se as quebras de linha são removidos, o código vai quebrar
BryanH

"... como XML" na primeira seção não deveria ser "... como texto não interpretado"? Em stackoverflow.com/questions/2784183/what-does-cdata-in-xml-mean , vemos "... essas cadeias incluem dados que podem ser interpretados como marcação XML, mas não devem ser".
22617

@mattwilkie, o que quero dizer com "como XML" é "Quando os navegadores usam seu analisador XML (em oposição ao analisador HTML) para analisar a marcação porque o documento foi enviado com um tipo MIME baseado em XML ou o arquivo que contém a marcação possui uma extensão de arquivo baseada em XML ".
Shadow2531

127

HTML

Um analisador de HTML tratará tudo entre <script>e </script>como parte do script. Algumas implementações nem precisam de uma tag de fechamento correta; eles param a interpretação do script em " </", o que é correto de acordo com as especificações .

Atualização No HTML5, e nos navegadores atuais, esse não é mais o caso.

Portanto, em HTML, isso não é possível:

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

Uma CDATAseção não tem efeito algum . É por isso que você precisa escrever

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

ou similar.

Isso também se aplica aos arquivos XHTML servidos como text/html. (Como o IE não suporta tipos de conteúdo XML, isso ocorre principalmente).

XML

No XML, regras diferentes se aplicam. Observe que navegadores (não IE) usam apenas um analisador XML se o documento XHMTL for servido com um tipo de conteúdo XML.

Para o analisador XML, uma scriptmarca não é melhor que qualquer outra marca. Particularmente, um nó de script pode conter nós filhos que não são de texto, acionados por " <"; e um &sinal " " indica uma entidade de caractere.

Portanto, em XHTML, isso não é possível:

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

Para contornar isso, você pode agrupar o script inteiro em uma CDATAseção. Isso diz ao analisador: 'Nesta seção, não trate " <" e " &" como caracteres de controle .' Para impedir que o mecanismo JavaScript interprete as marcas " <![CDATA[" e " ]]>", você pode agrupá-las nos comentários.

Se o seu script não contiver " <" ou " &", você não precisará de uma CDATAseção.


2
A declaração "Uma seção CDATA não tem efeito nenhum" não é verdadeira para o HTML5 (proposto), que reconhece a construção. w3.org/TR/html5/syntax.html#cdata-sections
danorton

3
@danorton Interessante. Eu acho que é uma mistura muito feia. Ainda não há efeito no conteúdo do script.
user123444555621

2
Não sabia que nenhuma </ tag de script interna é ruim.
precisa

3
@SalmanA Essa é uma das peculiaridades do HTML e é oficialmente chamada ETAGO . Saiba mais: mathiasbynens.be/notes/etago (enquanto o artigo afirma que nenhum navegador já implementados esse recurso, eu tenho certeza que causou alguns problemas para mim Talvez em alguma outra ferramenta.)
user123444555621

1
Na verdade, tive problemas de validação - <script>var b = "<b>bold</b>";</script>falha na validação, mas depois de ler sua resposta e mudar para <script>var b = "<b>bold<\/b>";</script>corrigi-la.
Salman A

30

Basicamente, é para permitir escrever um documento que seja XHTML e HTML. O problema é que, dentro de XHTML, o analisador XML interpretará os caracteres &, <,> na tag de script e causará erro de análise XML. Então, você pode escrever seu JavaScript com entidades, por exemplo:

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

Mas isso é impraticável. O maior problema é que, se você ler a página em HTML, o script da tag será considerado CDATA 'por padrão' e esse JavaScript não será executado. Portanto, se você deseja que a mesma página esteja OK, usando os analisadores XHTML e HTML, é necessário incluir a tag de script no elemento CDATA em XHTML, mas NÃO em HTML.

Este truque marca o início de um elemento CDATA como um comentário JavaScript; em HTML, o analisador JavaScript ignora a tag CDATA (é um comentário). No XHTML, o analisador XML (que é executado antes do JavaScript) o detecta e trata o restante até o final do CDATA como CDATA.


24

É uma coisa de X (HT) ML. Quando você usa símbolos como <e >dentro do JavaScript, por exemplo, para comparar dois números inteiros, isso teria que ser analisado como XML, assim eles seriam marcados como o início ou o fim de uma tag.

O CDATA significa que as seguintes linhas (tudo até o momento ]]>não é XML e, portanto, não devem ser analisadas dessa maneira.


18

Você não usar CDATA em HTML4, mas você deve usar CDATA em XHTML e deve usar CDATA em XML se você tiver símbolos unescaped como <e>.


11
CDATA não é válido em HTML4. Simplificando, não faz parte da gramática. CDATA é uma sintaxe de XML e XHTML é um subconjunto XML. Portanto, ele deve ser usado apenas dentro do XML (e seus subconjuntos). HTML, por outro lado, não é XML.
Loren Segal

17

É para garantir que a validação XHTML funcione corretamente quando você tiver JavaScript incorporado em sua página, em vez de fazer referência externa.

O XHTML exige que sua página esteja em conformidade estrita com os requisitos de marcação XML. Como o JavaScript pode conter caracteres com significado especial, você deve agrupá-lo no CDATA para garantir que a validação não o sinalize como malformado.

Com páginas HTML na Web, você pode incluir apenas o JavaScript necessário entre as tags e. Quando você valida o HTML em sua página da web, o conteúdo JavaScript é considerado CDATA (dados de caractere) que é, portanto, ignorado pelo validador. O mesmo não se aplica se você seguir os padrões XHTML mais recentes na configuração da sua página da web. Com o XHTML, o código entre as tags de script é considerado PCDATA (dados de caracteres analisados), que é, portanto, processado pelo validador.

Por esse motivo, você não pode simplesmente incluir JavaScript entre as tags de script da sua página sem 'quebrar' sua página da Web (pelo menos no que diz respeito ao validador).

Você pode aprender mais sobre CDATA aqui e mais sobre XHTML aqui .



9

Quando você deseja uma conformidade estrita com XHTML, precisa do CDATA, para que menos e comercial não sejam sinalizados como caracteres inválidos.


8

para evitar erros de xml durante a validação de xhtml.


8

O CDATA diz ao navegador para exibir o texto como está e não para processá-lo como um HTML.


6

CDATA indica que o conteúdo dentro não é XML.




2

Dessa forma, o navegador mais antigo não analisa o código Javascript e a página não quebra.

Compatibilidade com versões anteriores. Tem que amar isto.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.