Kiedy sekcja znacznika CDATA jest niezbędna w znaczniku skryptu?

Czy znaczniki CDATA są kiedykolwiek potrzebne w znacznikach skryptów, a jeśli tak, to kiedy?

Innymi słowy, kiedy i gdzie to jest:

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

lepiej niż to:

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

Sekcja CDATA jest wymagana, jeśli potrzebujesz, aby Twój dokument był analizowany jako XML (np. Gdy strona XHTML jest interpretowana jako XML) i chcesz mieć możliwość pisania literału i<10i a && bzamiast, i<10aa && b ponieważ XHTML będzie analizował kod JavaScript jako analizowane dane znakowe w przeciwieństwie do danych znaków domyślnie. Nie jest to problem ze skryptami przechowywanymi w zewnętrznych plikach źródłowych, ale dla każdego wbudowanego JavaScript w XHTML prawdopodobnie będziesz chciał użyć sekcji CDATA.

Zauważ, że wiele stron XHTML nigdy nie było analizowanych jako XML, w którym to przypadku nie będzie problemu.

Dobry opis na ten temat można znaleźć na stronie https://web.archive.org/web/20140304083226/http://javascript.about.com/library/blxhtml.htm

Gdy przeglądarki traktują znaczniki jako XML:

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

Gdy przeglądarki traktują znaczniki jako HTML:

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

Gdy przeglądarki traktują znaczniki jako HTML i chcesz, aby znaczniki XHTML 1.0 (na przykład) były sprawdzane.

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

HTML

Parser HTML potraktuje wszystko pomiędzy <script>i </script>jako część skryptu. Niektóre implementacje nawet nie wymagają poprawnego tagu zamykającego; zatrzymują interpretację skryptu na „ </”, co jest poprawne zgodnie ze specyfikacją .

Aktualizacja W HTML5 i przy obecnych przeglądarkach tak już nie jest.

W HTML nie jest to możliwe:

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

CDATASekcja ma żadnego efektu . Dlatego musisz pisać

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

lub podobne.

Dotyczy to również plików XHTML obsługiwanych jako text/html. (Ponieważ IE nie obsługuje typów treści XML, jest to w większości prawdą).

XML

W XML obowiązują inne reguły. Uwaga: przeglądarki (inne niż IE) używają analizatora składni XML tylko wtedy, gdy dokument XHMTL jest obsługiwany z typem treści XML.

Dla parsera XML scriptznacznik nie jest lepszy niż jakikolwiek inny znacznik. W szczególności węzeł skryptowy może zawierać nietekstowe węzły potomne, uruchamiane przez „ <”; a znak „ &” oznacza byt postaci.

W XHTML nie jest to możliwe:

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

Aby obejść ten problem, możesz zawinąć cały skrypt w CDATAsekcję. Mówi to parserowi: „W tej sekcji nie traktuj„ <”i„ &”jako znaków kontrolnych .” Aby uniemożliwić silnikowi JavaScript interpretację znaków „ <![CDATA[” i „ ]]>”, możesz zawinąć je w komentarze.

Jeśli twój skrypt nie zawiera żadnych „ <” ani „ &”, i tak nie potrzebujesz żadnej CDATAsekcji.

Zasadniczo pozwala on napisać dokument, który jest zarówno XHTML, jak i HTML. Problem polega na tym, że w XHTML parser XML interpretuje znaki &, <,> w znaczniku skryptu i powoduje błąd analizy XML. Możesz więc napisać JavaScript przy pomocy encji, np .:

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

Ale to jest niepraktyczne. Większy problem polega na tym, że jeśli czytasz stronę w HTML, skrypt znacznika jest domyślnie uznawany za CDATA i taki JavaScript nie będzie działał. Dlatego jeśli chcesz, aby ta sama strona działała poprawnie zarówno przy użyciu parserów XHTML, jak i HTML, musisz umieścić znacznik skryptu w elemencie CDATA w XHTML, ale NIE należy go umieszczać w HTML.

Ta sztuczka oznacza początek elementu CDATA jako komentarz JavaScript; w HTML parser JavaScript ignoruje znacznik CDATA (jest to komentarz). W XHTML parser XML (uruchamiany przed JavaScript) wykrywa go i traktuje resztę do końca CDATA jako CDATA.

To jest X (HT) ML. Gdy używasz symboli takich jak <i >wewnątrz JavaScript, np. Do porównywania dwóch liczb całkowitych, musiałoby to zostać przeanalizowane jak XML, a zatem oznaczałoby to początek lub koniec znacznika.

CDATA oznacza, że ​​następujące wiersze (wszystko do ]]>pliku nie jest XML i dlatego nie powinny być analizowane w ten sposób.

Czy nie używać CDATA w HTML4 ale należy użyć CDATA w XHTML i musi użyć CDATA w XML, jeśli masz kodów zmiany znaczenia symboli, takich jak <i>.

Ma to na celu zapewnienie, że sprawdzanie poprawności XHTML działa poprawnie, gdy JavaScript jest osadzony na stronie, a nie zewnętrznie.

XHTML wymaga, aby strona była ściśle zgodna z wymaganiami znaczników XML. Ponieważ JavaScript może zawierać znaki o specjalnym znaczeniu, musisz owinąć go w CDATA, aby upewnić się, że sprawdzanie poprawności nie oznaczy go jako zniekształcony.

Dzięki stronom HTML w Internecie możesz po prostu dołączyć wymagany kod JavaScript pomiędzy i tagi. Podczas sprawdzania poprawności kodu HTML na stronie internetowej zawartość JavaScript jest uważana za CDATA (dane znakowe), dlatego jest ona ignorowana przez weryfikator. To samo nie jest prawdą, jeśli postępujesz zgodnie z najnowszymi standardami XHTML podczas konfigurowania strony internetowej. W przypadku XHTML kod między znacznikami skryptu jest traktowany jako PCDATA (parsowane dane znakowe), który jest zatem przetwarzany przez walidator.

Z tego powodu nie można po prostu umieszczać JavaScript między znacznikami skryptu na stronie bez „uszkodzenia” strony internetowej (przynajmniej jeśli chodzi o weryfikator).

Możesz dowiedzieć się więcej o CDATA tutaj , a więcej o XHTML tutaj .

CDATA wskazuje, że zawarta w nim zawartość nie jest XML.

Oto wyjaśnienie na Wikipedii

Jeśli dążysz do ścisłej zgodności z XHTML, potrzebujesz CDATA, więc mniej niż i znaki ampersand nie są oznaczane jako nieprawidłowe znaki.

aby uniknąć błędów xml podczas sprawdzania poprawności xhtml.

CDATA mówi przeglądarce, aby wyświetlała tekst w obecnej postaci i nie renderowała go jako HTML.

CDATA wskazuje, że zawarta w nim zawartość nie jest XML.

CDATA jest niezbędny w każdym dialekcie XML, ponieważ tekst w węźle XML jest traktowany jako element potomny, zanim zostanie oceniony jako JavaScript. Jest to również powód, dla którego JSLint narzeka na <postać w wyrażeniach regularnych .

Bibliografia

• Tworzenie deklaratywnego języka interfejsu użytkownika XML
• Przyszłość sieci: bogaci klienci, bogate przeglądarki, bogate portale

Kiedy chcesz to sprawdzić (w XML / XHTML - dzięki, Loren Segal ).

W ten sposób starsza przeglądarka nie analizuje kodu JavaScript, a strona się nie psuje.

Kompatybilność wsteczna. Uwielbiam to.