2010-09-15 12 views
9

Soy un desarrollador web con énfasis en la programación del lado del servidor. Lo poco que he modificado con JavaScript, he terminado con los archivos referenciados externamente o los controladores de eventos, y el mínimo de una llamada a la función de inicialización entre <script> etiquetas.Escapar JavaScript [/ CSS] entre <script> [/ <style>] etiquetas: información sobre un statu quo potencialmente roto

Como tal, fue una sorpresa para mí hace aproximadamente una semana que los datos entre <script> etiquetas no se suelen escapar. De hecho ... no puede ser. Al escaparse arrojará un enorme lolwut-ohnoez -wrench en los trabajos del analizador de JavaScript en, hasta donde yo sé, cada navegador en la faz de la tierra.

Esto nos lleva a la clusterfuck (IMO) que es having to use CDATA for documents with in-HTML JavaScript blocks to pass validation (in XHTML), que todavía se rompe hilarantemente en el momento en que tiene ]]> en su código por cualquier motivo arbitrario.

Como algo así como un purista de codificación/escape, obtengo las contracciones que miran esto. Y durante varios días me he preguntado a mí mismo:

¿Por qué?

idea de quién era a EXIMEN < guión > (y, por ejemplo, con toda claridad no los controladores JS-evento como onclick) de la regla de lo contrario santa de 'no HTML cosas entre las etiquetas HTML deben estar HTML escapó ', y ¿por qué? ¿Es un caso de "esto simplemente creció de esa manera históricamente, está mal hecho ahora, lidiar con eso", o alguien se sentó y pensó algo que no estoy viendo?

Lo mismo es cierto (aunque menos obvio) para CSS y etiqueta de estilo >.

¿Sabemos siquiera qué lo provocó, o es un caso de conocimiento perdido? Mi google-fu sobre este tema ha sido increíblemente débil, y no he encontrado nada, pero como esto me está molestando de manera patéticamente OCD, me encantaría escuchar explicaciones si alguien tiene alguna.

Respuesta

7

Porque es muy común querer usar caracteres como & y < en scripts, y escapándolos es un problema.

Por otro lado, <script> y <style> no pueden tener elementos secundarios, por lo que no es necesario que sea fácil incluir una etiqueta.

El resultado: HTML define <script> y <style> como conteniendo CDATA en el DTD, por lo que no es necesario hacerlo manualmente en el documento, lo que hace la vida más fácil.

XHTML es diferente. En muchos sentidos, XML es más simple que SGML, y sus DTD no tienen (por lo que sé) esa facilidad. Por lo tanto, debe ser explícito sobre los marcadores CDATA (o usar entidades) en XHTML. La única razón por la cual es un "clusterfuck" es porque las personas afirman que su XHTML es HTML al servirlo con un tipo de contenido text/html (en lugar de la aplicación correcta/xhtml + xml).

En cuanto a los atributos de eventos intrínsecos, SGML no permite decir que los caracteres especiales no deben tratarse como tales, pero cuando se usan no deben contener mucho más que una llamada a función ... y es mejor evitarlos a favor de JS discreto de todos modos.

+0

Tiene razón acerca de que CDATA es una cosa XHTML (/ XML). Voy a editar eso en mi pregunta, ya que lo sé, pero al parecer he logrado omitirlo. D'oh. :) Responderá a los otros puntos en un segundo (pero definitivamente gracias por responder, y es probable que estés en algo). – pinkgothic

+0

Bien, de regreso a usted. : D No me di cuenta que HTML define el contenido de esas etiquetas como 'CDATA'; ¡Simplemente pensé que los bloques JS que pasan la validación en HTML vinieron de SGML siendo más indulgente que XML! Aprenda algo nuevo cada día. (¿Dónde está ese +2 cuando lo necesitas?) Las otras cosas me han hecho dar vueltas hasta la muerte en la dirección general de MooGoo, así que no voy a repetirlas aquí (si está bien). – pinkgothic

+1

Creo que la razón principal es que los elementos '

2

Porque en Javascript usted es constantemente usando caracteres que deberían escaparse en HTML. Ese es el punto de tener CDATA después de todo, ¿no?

Dime lo que piensa que se ve más razonable

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

O

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

También en la gran mayoría de los casos, tanto CSS y Javascript deben incluirse como enlaces a archivos separados, en lugar de inline en HTML, evitando así el problema de escape por completo.

+0

"También en la gran mayoría de los casos, tanto CSS como Javascript deben incluirse como enlaces a archivos separados, en lugar de estar escritos en HTML, evitando así por completo el problema del escape". Estoy completamente de acuerdo. :) Pero no creo que 'usar constantemente personajes que deban escapar' sea siempre una razón válida para no escapar de algo; sin embargo, cuanto más lo pienso, es más probable que lo que sucedió cuando se definió. :/¿Tiene una idea de por qué CSS lo hace? Es mucho menos frecuente allí. – pinkgothic

+0

Por cierto, simplemente porque probablemente no es lo que espera que diga, pero no obstante es cierto, considero que el primero es más razonable - * en un contexto HTML *. Para mí, los datos escapados siempre se verán más razonables, es el TOC antes mencionado que llega (incluso si es un poco irónico). ;) Sin embargo, entiendo a lo que te refieres. Y acepta que probablemente sea la motivación. – pinkgothic

+0

Diría que '' simplemente cambia los caracteres que necesitan ser escapados. Como dijiste, cualquier instancia de ']]>' rompería la validación, por lo tanto, si fuera incluida en el código JS, tendría que ser representada de una manera que no entre en conflicto con el lenguaje "host". ..escaping it. La probabilidad de ']]>' que aparece en la mayoría de los códigos Javascript es bastante baja, por lo que es una compensación razonable. – MooGoo