Câu hỏi Thoát JavaScript [/ CSS] giữa các thẻ

Tôi là một nhà phát triển web với sự nhấn mạnh về lập trình phía máy chủ. Tôi đã làm việc với JavaScript, tôi đã thực hiện với các tệp tham chiếu bên ngoài hoặc trình xử lý sự kiện và mức tối thiểu barest của một cuộc gọi hàm khởi tạo giữa các thẻ <script>.

Như vậy nó đã đến như là một bất ngờ với tôi khoảng một tuần trước rằng các dữ liệu giữa các thẻ <script> không phải là thường thoát. Trong thực tế ... nó không thể được. Thoát nó sẽ ném một khối lolwut-ohnoez-Xấu thành các tác phẩm của trình phân tích cú pháp JavaScript, theo như tôi biết, mọi trình duyệt trên mặt đất.

Điều này dẫn chúng ta đến cụm từ (IMO) phải sử dụng CDATA cho các tài liệu có các khối JavaScript trong HTML để vượt qua quá trình xác thực (trong XHTML), mà vẫn phá vỡ hilariously thời điểm bạn có ]]> trong mã của bạn vì bất kỳ lý do tùy ý nào.

Như một cái gì đó của một purist mã hóa / thoát, tôi nhận được các twitches nhìn vào điều này. Và trong nhiều ngày tôi đã tự hỏi:

Tại sao?

Ý tưởng của ai là nó để loại bỏ <script> (và, ví dụ, khá rõ ràng không phải các trình xử lý sự kiện JS như onclick) từ nguyên tắc thánh thiện khác 'nội dung không phải HTML giữa các thẻ HTML phải được HTML thoát', và tại sao? Nó là một trường hợp 'điều này chỉ phát triển theo cách đó trong lịch sử, nó đã bị hỏng bây giờ, đối phó với nó', hay ai đó ngồi xuống và nghĩ ra điều gì đó mà tôi không thấy?

Điều này cũng đúng (mặc dù ít rõ ràng hơn) đối với CSS và thẻ <style>.

Chúng ta thậm chí còn biết điều gì đã thúc đẩy điều này - hay nó là một trường hợp mất kiến ​​thức? Google-fu của tôi về chủ đề này đã cực kỳ yếu, và tôi đã không tìm thấy bất cứ điều gì, nhưng kể từ khi điều này thực sự bugging tôi theo cách OCD pathetically, tôi rất muốn nghe giải thích nếu có ai có bất kỳ.


9
2017-09-15 18:57


gốc




Các câu trả lời:


Bởi vì nó là rất phổ biến để muốn sử dụng các ký tự như & và < trong kịch bản, và trốn thoát chúng là một nỗi đau.

Mặt khác, <script> và <style> không thể có các phần tử con, do đó không cần phải bao gồm thẻ dễ dàng.

Kết quả - HTML định nghĩa <script> và <style> như có chứa CDATA trong DTD, vì vậy bạn không cần phải làm điều đó bằng tay trong tài liệu, do đó làm cho cuộc sống dễ dàng hơn.

XHTML là khác nhau. Theo nhiều cách, XML đơn giản hơn SGML và các DTD của nó không (theo như tôi biết) có cơ sở đó. Do đó, bạn cần phải rõ ràng về các đánh dấu CDATA (hoặc sử dụng các thực thể) trong XHTML. Lý do duy nhất nó là một "clusterfuck" là bởi vì mọi người tuyên bố XHTML của họ là HTML bằng cách phục vụ nó với một loại nội dung văn bản / html (thay vì ứng dụng chính xác / xhtml + xml).

Đối với các thuộc tính sự kiện nội tại, SGML không thể nói rằng các ký tự đặc biệt không nên được xử lý như vậy, nhưng khi chúng được sử dụng, chúng không được chứa nhiều hơn một lời gọi hàm và tránh được không phô trương JS anyway.


7
2017-09-15 19:01



Bạn nói đúng về CDATA là một điều XHTML (/ XML). Tôi sẽ sửa nó thành câu hỏi của tôi, vì tôi biết điều đó, nhưng tôi dường như đã bỏ qua nó. D'oh. :) Sẽ trả lời các điểm khác trong một giây (nhưng chắc chắn cảm ơn bạn đã trả lời và bạn có thể đang làm gì đó). - pinkgothic
Ngay phía sau bạn. : D Tôi không nhận ra HTML xác định nội dung của các thẻ đó là CDATA; Tôi chỉ nghĩ rằng các khối JS đi qua xác thực trong HTML đến từ SGML là khoan dung hơn XML! Học điều mới mỗi ngày. (Khi đó là +2 khi bạn cần nó?) Những thứ khác mà tôi đã sắp xếp cho đến chết theo hướng chung của MooGoo, vì vậy tôi sẽ không lặp lại chúng ở đây (nếu không sao). - pinkgothic
Tôi nghĩ lý do chính là <script> và <style> các yếu tố không cần trẻ em, vì vậy hãy loại bỏ nhu cầu thoát khỏi mọi thứ theo cách thủ công (hoặc đặt nó vào CDATA) có vẻ hợp lý bởi vì bạn sẽ không bao giờ thực ra muốn viết một unescaped < bên trong một tập lệnh. - Sasha Chedygov
@ musicfreak: Ooh, bình luận tuyệt vời cho sự nhấn mạnh. Bây giờ tôi đang nhìn thấy đoạn thứ hai của David trong một ánh sáng hoàn toàn khác. - pinkgothic


Bởi vì trong Javascript bạn liên tục sử dụng các ký tự cần phải được thoát trong HTML. Đó là điểm có CDATA sau khi tất cả phải không?

Cho tôi biết bạn nghĩ gì hợp lý hơn

if (5 &gt; 4 &amp;&amp; 2 &lt; 3) alert('dude');

Hoặc là

if (5 > 4 && 2 < 3) alert('dude');

Cũng trong phần lớn các trường hợp, cả CSS và Javascript nên được bao gồm dưới dạng liên kết đến các tệp riêng biệt, thay vì được gạch chân trong HTML, do đó tránh hoàn toàn vấn đề thoát.


2
2017-09-15 19:05



"Ngoài ra trong phần lớn các trường hợp, cả CSS và Javascript nên được bao gồm dưới dạng các liên kết đến các tệp riêng biệt, chứ không phải được gạch chân trong HTML, do đó tránh hoàn toàn vấn đề thoát." Tôi hoàn toàn đồng ý. :) Nhưng tôi không cảm thấy 'liên tục sử dụng các nhân vật nên được thoát' là một lý do hợp lệ để không thoát khỏi cái gì đó - nhưng tôi càng nghĩ về nó, thì càng có nhiều điều xảy ra khi nó được xác định. : / Bạn có một ý tưởng tại sao CSS không? Nó ít thường xuyên hơn ở đó. - pinkgothic
Nhân tiện, đơn giản bởi vì nó có lẽ không phải là những gì bạn mong đợi tôi nói, nhưng dù sao cũng đúng, tôi coi nó hợp lý hơn - trong ngữ cảnh HTML. Đối với tôi, dữ liệu thoát sẽ luôn trông hợp lý hơn, đó là OCD nói trên đến (ngay cả khi nó hơi lưỡi-in-má). ;) Tuy nhiên, tôi hiểu những gì bạn đang nhận được. Và đồng ý rằng đó có lẽ là động lực. - pinkgothic
Tôi sẽ nói rằng <![CDATA[ ... ]]> chỉ cần thay đổi những ký tự cần được thoát. Như bạn đã nói, bất kỳ trường hợp nào ]]> sẽ phá vỡ xác nhận, vì vậy nếu nó được bao gồm trong mã JS, nó sẽ phải được đại diện theo cách không xung đột với ngôn ngữ "máy chủ", do đó ... thoát nó. Xác suất của ]]> xuất hiện trong hầu hết các mã Javascript là khá thấp, do đó, nó là một sự cân bằng hợp lý. - MooGoo
Cũng lưu ý rằng CDATA có chức năng giống với cú pháp chuỗi "HEREDOC" của nhiều ngôn ngữ lập trình. Thành thật mà nói, những thứ thoát đúng cách có thể là một PIA thực sự, chưa kể đến khả năng nguy hiểm nếu được thực hiện không chính xác, vì vậy bất cứ điều gì để làm cho nó dễ dàng hơn và ít bị lỗi là một điều tốt tôi nghĩ. CSS dường như có ít nhu cầu được gói trong cấu trúc CDATA, như &|<|>hiếm khi được sử dụng trong nó, nhưng có nó ở đó có thể tránh các vấn đề tiềm năng trong tương lai tôi đoán. - MooGoo
Yea ... quy tắc rõ ràng thường dường như nhường chỗ cho sự tiện lợi; đó là cuộc sống, đặc biệt là trong lĩnh vực máy tính. Tôi nghe những gì bạn đang nói về HTML tìm kiếm hợp lý. Đối với tôi, hầu như mọi CSS / JS trong HTML đều xấu. Hoàn toàn thụt lề HTML, mặt khác là một điều đẹp. - MooGoo