Pourquoi utiliser \x3C au lieu de < lors de la génération de code HTML, de JavaScript?

Je vois le code HTML suivant beaucoup utilisé pour charger jQuery à partir d'un réseau de diffusion de contenu, mais de revenir à une copie locale si la CAN n'est pas disponible (par exemple, dans le Modernizr 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>

Ma question est, pourquoi est le dernier < personnage dans le document.write() déclaration remplacé par la séquence d'échappement \x3C? < est sûr de caractères en JavaScript et est même utilisé plus tôt dans la même chaîne de caractères, alors pourquoi s'en échapper il? Est-il juste pour empêcher les mauvais navigateur implémentations de la pensée l' </script> à l'intérieur de la chaîne est le vrai script balise de fin? Si il y a vraiment tout les navigateurs qui serait un échec sur ce point?

Comme suite à la question, j'ai vu aussi une variante en utilisant unescape() (comme cette réponse) à l'état sauvage d'un couple de fois aussi. Pourquoi est-ce que la version semble toujours remplacer tous la < et > personnages?

  • Serait-ce vrai dans un fichier de script ou de la fonction eval avais bloc?
InformationsquelleAutor Mark Whitaker | 2011-11-22
  1. 55

    Lorsque le navigateur voit </script>, il estime que c'est la fin du bloc de script (depuis l'analyseur HTML n'a pas d'idée à propos de JavaScript, il ne peut pas distinguer entre quelque chose qui apparaît dans une chaîne de caractères, et quelque chose qui est fait à la fin de l'élément script). Donc </script> figurant littéralement dans le JavaScript qui est à l'intérieur d'une page HTML (dans le meilleur des cas) à l'origine d'erreurs, et (dans le pire des cas) être un trou de sécurité énorme.

    C'est pourquoi vous en quelque sorte afin de prévenir cette séquence de caractères à apparaître. Autres solutions de contournement pour ce problème sont "<"+"/script>" et "<\/script>" (ils viennent tous à la même chose).

    Alors que certains considèrent que c'est un "bug", il fait a pour se passent de cette manière, car, comme par la spécification, la partie HTML de l'agent utilisateur est complètement séparée du moteur de script. Vous pouvez mettre toutes sortes de choses dans <script> tags, pas de JavaScript. Le W3C mentionne VBScript et TCL à titre d'exemples. Un autre exemple est la jQuery template de plugin, qui utilise ces balises ainsi.

    Mais même au sein de JavaScript, où vous pourrait suggérer qu'un tel contenu dans les chaînes de caractères peuvent être reconnus et donc de ne pas être traités comme des étiquettes de fin, la prochaine ambiguïté vient quand vous considérez commentaires:

    <script type="text/javascript">foo(42); //call the function </script>

    – qu'est ce que le navigateur faire dans ce cas?

    Et enfin, que sur les navigateurs qui ne prennent pas en JavaScript? Ils ne pouvaient ignorer la partie entre <script> et </script>, mais si vous avez donné des sémantiques différentes de la séquence de caractères </script> basé sur les navigateurs connaissance de JavaScript, vous feriez un coup à deux résultats différents dans la analyse HTML stade.

    Enfin, concernant votre question concernant la substitution de tous angle crochets: je dirais au moins dans 99% des cas, c'est de la confusion, c'est à dire à cacher (à partir du logiciel d'anti-virus, la censure des procurations (comme dans votre exemple (nested parens sont impressionnants), etc.) le fait que votre JavaScript est en train de faire des HTML-y des trucs. Je ne peux pas penser de la bonne technique de raisons de cacher quoi que ce soit mais </script>, au moins pas raisonnablement penser que les navigateurs modernes (et par cela, je veux dire à peu près tout plus récente que celle de la Mosaïque).

    • J'ai juste modifié la question dans ce sens, probablement que vous étiez en tapant votre réponse. Y a t il vraiment tout les navigateurs modernes qui serait un échec sur ce point?
    • La plupart, je pense. Je sais pour sûr que Chrome interprète comme une balise de fermeture. (Vérifié hier)
    • Cela se produit avec une section CDATA enveloppant le script?
    • Tous les navigateurs ne "échec", parce </script> est censés pour être traitée comme une balise de fin.
    • Pas si le document a été signifié que application/xhtml+xml et analysée comme XML, et non pas si le document a été analysé à l'aide d'un véritable analyseur SGML ... mais il serait avec une étiquette de soupe ou de HTML 5 de l'analyseur.
    • génial, merci pour la clarification. Qu'est-ce qu'HTML5 changement de comportement?
    • Élargi ma réponse un peu.
    • Merci! Grande réponse - maintenant acceptée.
    • Désolé, ne peut pas aider moi-même, à partir de l'ajout d'un merci commentaire: un Grand Merci pour la clarté de la réponse!

    InformationsquelleAutor balpha
  2. 2

    Certains analyseurs de gérer la < version que la balise de fermeture et d'interpréter le code que

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

    \x3C est hexadécimal <. Ceux qui sont interchangeables dans le script.

    InformationsquelleAutor J. K.