Khi nào một phần CDATA cần thiết trong thẻ script?


907

Chúng tôi thẻ CDATA có bao giờ cần thiết trong các thẻ script và nếu vậy thì khi nào?

Nói cách khác, đây là khi nào và ở đâu:

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

thích hơn thế này:

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

18
Bây giờ XHTML về cơ bản đã chết, điều này không còn là mối quan tâm có liên quan?
mã allyour

80
@allyourcode: điều gì khiến bạn nghĩ XHTML đã chết? HTML5? Có XHTML5 để đi cùng với nó :)
Doktor J

4
@DoktorJ AFAIK xHTML đã có phiên bản 1. Tương đương với HTML là phiên bản 4. Có một nỗ lực tập trung vào xHTML 2.0 có ý định đẩy các không gian tên xform, xlink, time và svg vào thông số kỹ thuật như một cách cải thiện các tính năng tương tự HTML 5 thêm - xform / xác thực đầu vào, thời gian / hình động, svg / canvas - nhưng những nỗ lực cho thông số xHTML 2 đã được tập trung vào các tính năng HTML 5. Điều đó không có nghĩa là xHTML 2 đã bị loại bỏ hoặc trở nên lỗi thời nhưng nó không được lên kế hoạch trong tương lai gần.
Mihai Stancu

14
XHTML không chết trong quá trình phát triển Java Seam / JSF / Facelets.
JoJo

15
@Mihai Stancu - điều đó không hoàn toàn chính xác. Theo W3C, có một cú pháp XML cho HTML5 : "Cú pháp khác có thể được sử dụng cho HTML5 là XML. Cú pháp này tương thích với các tài liệu và triển khai XHTML1. Các tài liệu sử dụng cú pháp này cần được cung cấp với loại phương tiện XML và các yếu tố cần được đặt trong không gian tên w3.org/1999/xhtml theo các quy tắc được quy định bởi các đặc tả XML. "
BrainSlugs83

Câu trả lời:


585

Cần có phần CDATA nếu bạn cần tài liệu của mình phân tích thành XML (ví dụ: khi trang XHTML được hiểu là XML) và bạn muốn có thể viết bằng chữ i<10a && bthay vì i&lt;10a &amp;&amp; b , vì XHTML sẽ phân tích mã JavaScript dưới dạng dữ liệu ký tự được phân tích cú pháp trái ngược với dữ liệu ký tự theo mặc định. Đây không phải là vấn đề với các tập lệnh được lưu trữ trong các tệp nguồn bên ngoài, nhưng đối với bất kỳ JavaScript nội tuyến nào trong XHTML, bạn có thể sẽ muốn sử dụng phần CDATA.

Lưu ý rằng nhiều trang XHTML không bao giờ có ý định được phân tích cú pháp dưới dạng XML trong trường hợp này sẽ không phải là vấn đề.

Để có một bài viết hay về chủ đề này, hãy xem https://web.archive.org/web/20140304083226/http://javascript.about.com/l Library / blxhtml.htmlm


48
Có nhiều thứ hơn nó chỉ là "xác nhận". Hầu hết các trình phân tích cú pháp XML nghiêm ngặt sẽ không đi qua trang nếu chúng đánh một ký tự bất hợp pháp. Không chỉ đơn giản là làm cho W3C hạnh phúc và có được màu xanh lá cây thay vì màu đỏ.
Loren Segal

40
Nếu bạn tránh &<ký tự, bạn không cần phần CDATA; nó sẽ hoạt động tốt trong cả HTML và XHTML. Bạn có thể dễ dàng đạt được điều này bằng cách đặt tất cả các mã quan trọng vào các tập lệnh bên ngoài và chỉ cần sử dụng các tập lệnh nội tuyến để vd. biến khởi tạo (thoát &/ <đến \x26/ \x3Ctrong chuỗi ký tự nếu bạn cần).
bobince

23
Còn trong trường hợp của HTML5 thì sao?
Mathew Attlee

5
@Mathew Attle - đây là một câu hỏi hay. Hãy là một câu hỏi tuyệt vời để hỏi về một chủ đề riêng biệt để đảm bảo nó nhận được sự chú ý mà nó cần.
Alex KeySmith

3
@Loren: Sau đó, nó vẫn hoàn toàn về xác nhận. Mức độ mà tác nhân người dùng từ chối XML không hợp lệ là trực giao.
Các cuộc đua nhẹ nhàng trong quỹ đạo

231

Khi trình duyệt coi đánh dấu là XML:

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

Khi trình duyệt coi đánh dấu là HTML:

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

Khi trình duyệt coi đánh dấu là HTML và bạn muốn đánh dấu XHTML 1.0 của mình (ví dụ) để xác thực.

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

12
Cũng giống như vấn đề an toàn mã, tốt hơn là bao quanh các CDATA của bạn với các nhận xét chặn /* ... */bởi vì nếu không, nếu ngắt dòng bị xóa, mã sẽ bị
hỏng

không nên "... dưới dạng XML" trong phần đầu tiên là "... dưới dạng văn bản không được giải thích"? Trong stackoverflow.com/questions/2784183/what-does-cdata-in-xml-mean chúng tôi thấy "... các chuỗi này bao gồm dữ liệu có thể được hiểu là đánh dấu XML, nhưng không nên."
matt wilkie

@mattwilkie, ý của tôi với "as XML" là "Khi các trình duyệt sử dụng trình phân tích cú pháp XML của họ (trái ngược với trình phân tích cú pháp HTML) để phân tích đánh dấu vì tài liệu được gửi với loại mime dựa trên XML hoặc tệp có chứa đánh dấu một phần mở rộng tệp dựa trên XML ".
Shadow2531

127

HTML

Trình phân tích cú pháp HTML sẽ coi mọi thứ giữa <script></script>như một phần của tập lệnh. Một số triển khai thậm chí không cần thẻ đóng chính xác; họ dừng giải thích tập lệnh tại " </", đúng theo thông số kỹ thuật .

Cập nhật Trong HTML5 và với các trình duyệt hiện tại, đó không còn là vấn đề nữa.

Vì vậy, trong HTML, điều này là không thể:

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

Một CDATAphần không có tác dụng gì cả . Đó là lý do tại sao bạn cần viết

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

hoặc tương tự.

Điều này cũng áp dụng cho các tệp XHTML được phân phát dưới dạng text/html. (Vì IE không hỗ trợ các loại nội dung XML, nên điều này gần như đúng.)

XML

Trong XML, các quy tắc khác nhau được áp dụng. Lưu ý rằng các trình duyệt (không phải IE) chỉ sử dụng trình phân tích cú pháp XML nếu tài liệu XHMTL được cung cấp cùng với loại nội dung XML.

Đối với trình phân tích cú pháp XML, một scriptthẻ không tốt hơn bất kỳ thẻ nào khác. Đặc biệt, một nút script có thể chứa các nút con không phải văn bản, được kích hoạt bởi " <"; và dấu " &" biểu thị một thực thể ký tự.

Vì vậy, trong XHTML, điều này là không thể:

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

Để giải quyết vấn đề này, bạn có thể gói toàn bộ tập lệnh trong một CDATAphần. Điều này nói với trình phân tích cú pháp: 'Trong phần này, đừng coi " <" và " &" là các ký tự điều khiển .' Để ngăn công cụ JavaScript diễn giải các dấu " <![CDATA[" và " ]]>", bạn có thể gói chúng trong các nhận xét.

Nếu tập lệnh của bạn không chứa bất kỳ " <" hoặc " &" nào, bạn không cần một CDATAphần nào.


2
Câu lệnh Một phần CDATA không có hiệu lực ở tất cả các điều không đúng với HTML5 (được đề xuất), nhận ra cấu trúc. w3.org/TR/html5/syntax.html#cdata-sections
danorton

3
@danorton Thú vị. Tôi nghĩ đó là một sự pha trộn khá xấu xí. Vẫn không có hiệu lực trong nội dung kịch bản mặc dù.
dùng123444555621

2
Không biết rằng bất kỳ </ thẻ script bên trong là xấu.
Salman A

3
@SalmanA Đó là một trong những điều kỳ quặc của HTML và được gọi chính thức là ETAGO . Tìm hiểu thêm: mathiasbynens.be/notes/etago (trong khi bài viết nói rằng không có trình duyệt nào từng thực hiện tính năng đó, tôi khá chắc chắn rằng nó đã gây ra một số rắc rối cho tôi. Có thể trong một số công cụ khác)
user123444555621

1
Trên thực tế tôi gặp vấn đề về xác nhận - <script>var b = "<b>bold</b>";</script>không xác thực nhưng sau khi đọc câu trả lời của bạn và thay đổi để <script>var b = "<b>bold<\/b>";</script>sửa nó.
Salman A

30

Về cơ bản, nó là cho phép viết một tài liệu có cả XHTML và HTML. Vấn đề là trong XHTML, trình phân tích cú pháp XML sẽ diễn giải các ký tự &, <,> trong thẻ script và gây ra lỗi phân tích cú pháp XML. Vì vậy, bạn có thể viết JavaScript của mình với các thực thể, ví dụ:

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

Nhưng điều này là không thực tế. Vấn đề lớn hơn là nếu bạn đọc trang bằng HTML, tập lệnh thẻ được coi là CDATA 'theo mặc định' và JavaScript như vậy sẽ không chạy. Do đó, nếu bạn muốn cùng một trang đều ổn khi sử dụng trình phân tích cú pháp XHTML và HTML, bạn cần đặt thẻ script trong phần tử CDATA trong XHTML, nhưng KHÔNG được đặt trong HTML.

Thủ thuật này đánh dấu sự khởi đầu của một yếu tố CDATA như một nhận xét JavaScript; trong HTML, trình phân tích cú pháp JavaScript bỏ qua thẻ CDATA (đây là một nhận xét). Trong XHTML, trình phân tích cú pháp XML (được chạy trước JavaScript) phát hiện ra nó và xử lý phần còn lại cho đến khi kết thúc CDATA dưới dạng CDATA.


24

Đó là một thứ X (HT) ML. Khi bạn sử dụng các biểu tượng như <> trong JavaScript, ví dụ để so sánh hai số nguyên, điều này sẽ phải được phân tích cú pháp như XML, do đó chúng sẽ đánh dấu là bắt đầu hoặc kết thúc của thẻ.

CDATA có nghĩa là các dòng sau (mọi thứ cho đến ]]>không phải là XML và do đó không nên được phân tích cú pháp theo cách đó.


18

Đừng không sử dụng CDATA trong HTML4 nhưng bạn nên sử dụng CDATA trong XHTML và phải sử dụng CDATA trong XML nếu bạn có những biểu tượng unescaped như <và>.


11
CDATA không hợp lệ trong HTML4. Nói một cách đơn giản, nó không phải là một phần của ngữ pháp. CDATA là một cú pháp của XML và XHTML là một tập hợp con XML. Do đó, nó chỉ nên được sử dụng bên trong XML (và các tập hợp con của nó). Mặt khác, HTML không phải là XML.
Loren Segal

17

Nó để đảm bảo rằng xác thực XHTML hoạt động chính xác khi bạn có JavaScript được nhúng trong trang của mình, thay vì được tham chiếu bên ngoài.

XHTML yêu cầu trang của bạn tuân thủ nghiêm ngặt các yêu cầu đánh dấu XML. Vì JavaScript có thể chứa các ký tự có ý nghĩa đặc biệt, bạn phải bọc nó trong CDATA để đảm bảo rằng xác thực không gắn cờ là không đúng định dạng.

Với các trang HTML trên web, bạn chỉ có thể bao gồm JavaScript được yêu cầu giữa và các thẻ. Khi bạn xác thực HTML trên trang web của mình, nội dung JavaScript được coi là CDATA (dữ liệu ký tự) do đó bị người xác nhận bỏ qua. Điều này cũng không đúng nếu bạn tuân theo các tiêu chuẩn XHTML gần đây hơn trong việc thiết lập trang web của mình. Với XHTML, mã giữa các thẻ script được coi là PCDATA (dữ liệu ký tự được phân tích cú pháp) do đó được trình xác nhận xử lý.

Vì điều này, bạn không thể chỉ bao gồm JavaScript giữa các thẻ script trên trang của mình mà không 'phá vỡ' trang web của bạn (ít nhất là về trình xác nhận có liên quan).

Bạn có thể tìm hiểu thêm về CDATA tại đâythêm về XHTML tại đây .



9

Khi bạn tuân thủ nghiêm ngặt XHTML, bạn cần CDATA để ít hơn và ký hiệu không được gắn cờ là các ký tự không hợp lệ.



8

CDATA yêu cầu trình duyệt hiển thị văn bản như hiện tại và không hiển thị dưới dạng HTML.


6

CDATA chỉ ra rằng nội dung bên trong không phải là XML.




2

Bằng cách đó, trình duyệt cũ hơn không phân tích mã Javascript và trang không bị hỏng.

Khả năng tương thích ngược. Phải yêu nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.