Dlaczego warto używać x3C zamiast

Widzę następujący kod HTML często używany do ładowania jQuery z sieci dostarczania treści, ale wraca do lokalnej kopii, jeśli CDN jest niedostępny (np. w Modern docs):

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.1.min.js">\x3C/script>')</script>

Moje pytanie brzmi, dlaczego ostatni znak < w document.write() został zastąpiony sekwencją ucieczki \x3C? < jest bezpiecznym znakiem w JavaScript i jest nawet używany wcześniej w tym samym łańcuchu znaków, więc po co go tam ukrywać? Czy tylko po to, aby zapobiec złym implementacjom przeglądarki z myślisz, że </script> wewnątrz łańcucha jest prawdziwy znacznik końca skryptu? Jeśli tak, to czy naprawdę istnieją jakieś przeglądarki, które by się w tym nie powiodły?

Jako kolejne pytanie, widziałem również wariant używając unescape() (Jak podano w ta odpowiedź) w dziczy też kilka razy. Czy jest jakiś powód, dla którego ta wersja zawsze wydaje się zastępować Wszystkie < i > znaki?

Author: Community, 2011-11-22

2 answers

Kiedy przeglądarka widzi </script>, uważa, że jest to koniec bloku skryptu (ponieważ parser HTML nie ma pojęcia o JavaScript, nie może odróżnić czegoś, co pojawia się w ciągu znaków, a czymś, co w rzeczywistości oznaczało, aby zakończyć element skryptu). Więc </script> pojawianie się dosłownie w JavaScript, który znajduje się wewnątrz strony HTML, spowoduje (w najlepszym przypadku) błędy, a (w najgorszym przypadku) będzie ogromną luką bezpieczeństwa.

Dlatego musisz jakoś zapobiec ta sekwencja znaków, aby się pojawić. Inne wspólne obejścia tego problemu to "<"+"/script>" i "<\/script>" (wszystkie sprowadzają się do tego samego).

Podczas gdy niektórzy uważają to za" błąd", w rzeczywistości musi zdarzyć się w ten sposób, ponieważ, zgodnie ze specyfikacją , HTML część user agenta jest całkowicie oddzielona od silnika skryptowego. W znacznikach <script> można umieszczać różne rzeczy, nie tylko JavaScript. W3C wymienia VBScript i TCL jako przykłady. Inny przykładem jest wtyczka jQuery template plugin , która również używa tych tagów.

Ale nawet w JavaScript, gdzie można sugerować, że taka treść w łańcuchach może być rozpoznawana, a tym samym nie być traktowana jako znaczniki końcowe, Następna niejasność pojawia się, gdy rozważasz komentarze:

<script type="text/javascript">foo(42); // call the function </script>
{–10]} - co powinna w tym przypadku zrobić przeglądarka?

I wreszcie, co z przeglądarkami, które nawet nie znają JavaScript? Zignorowaliby tylko część pomiędzy <script> i </script>, ale gdyby podałeś inną semantykę sekwencji znaków </script> w oparciu o znajomość JavaScript przez przeglądarki , nagle uzyskasz dwa różne wyniki w etapie parsowania HTML .

Na koniec, jeśli chodzi o twoje pytanie dotyczące zastępowania wszystkich nawiasów kątowych: powiedziałbym, że przynajmniej w 99% przypadków, to jest dla zaciemnienia, tj. dla ukrycia (przed oprogramowaniem antywirusowym, cenzurowanie proxy (jak w twoim przykładzie (zagnieżdżone pareny są niesamowite)), itp.) fakt, że Twoje JavaScript robi pewne rzeczy HTML-y. Nie mogę wymyślić dobrych powodów technicznych, aby ukryć cokolwiek, ale </script>, przynajmniej nie dla rozsądnie nowoczesnych przeglądarek (a przez to mam na myśli prawie wszystko, co nowsze niż Mosaic).

 52
Author: balpha,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-11-22 18:06:59

Niektóre parsery obsługują wersję < jako znacznik zamykający i interpretują kod jako

<script>
  window.jQuery || document.write('<script src="js/libs/jquery-1.6.1.min.js">
</script>

\x3C jest szesnastkowe dla <. Są one wymienne w skrypcie.

 2
Author: J. K.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-11-22 17:35:07