Me gustaría mostrar HTML sin formato. Todos sabemos que uno tiene que escapar cada "<" y ">" así
<PRE> this is a test <DIV> </PRE>
Sin embargo, yo no quiero hacer esto. Me gustaría una manera de mantener el código HTML como es (ya que es más fácil de leer, (dentro del editor) y yo podría querer copiarlo y utilizarlo de nuevo a mí mismo como código HTML real, y no quiero tener que cambiar de nuevo o tener 2 versiones del mismo código uno escapado y uno no escapado).
¿Hay algún otro entorno que sea más "crudo" que PRE que pueda permitir esto? ¿Para no tener que estar editando HTML y cambiándolo todo cada vez que se quiera mostrar código HTML en bruto, tal vez en HTML5?
Algo como <REALLY_VERBATIM> ...... </<REALLY_VERBATIM>
.
captura de pantalla
La solución javascript no funciona en FF 21, aquí está la captura de pantalla
**Captura de pantalla 2
La primera solución todavía no funciona en Firefox, aquí está la captura de pantalla
Puede utilizar el elemento xmp
, consulte https://stackoverflow.com/questions/4545/what-was-the-xmp-tag-used-for. Ha estado en HTML desde el principio y es soportado por todos los navegadores. Las especificaciones no lo ven con buenos ojos, pero HTML5 CR sigue describiéndolo y exige a los navegadores que lo soporten (aunque también indica a los autores que no lo usen, pero en realidad no puede impedírselo).
Todo lo que hay dentro de xmp
se toma como tal, no se reconoce ningún marcado (etiquetas o referencias de caracteres) allí, excepto, por razón aparente, la etiqueta final del propio elemento, </xmp>
.
Por lo demás, xmp
se representa como pre
.
Cuando se utiliza "XHTML real", es decir, XHTML servido con un tipo de medio XML (lo cual es poco frecuente), no se aplican las reglas especiales de análisis sintáctico, por lo que xmp
se trata como pre
. Pero en el "XHTML real", puede utilizar una sección CDATA, que implica reglas de análisis similares. No tiene un formato especial, por lo que probablemente querrá envolverla dentro de un elemento pre
:
<pre><![CDATA[
This is a demo, tags like <p> will
appear literally.
]]></pre>
No veo cómo podrías combinar xmp
y la sección CDATA para conseguir el llamado marcado políglota.
A LOS EDITORES: DEJE LOS NIVELES DE INDENTACIÓN POR FAVOR, SON IMPORTANTES --> Esencialmente la pregunta original se puede dividir en 2 partes:
"algunos "datos" aquí"
o <i>..cerrar cursiva con '</i>'-tag</i>
, donde es obvio que uno debería escapar/codificar (algo en) </i
y "
(o cambiar el carácter de cita del contenedor'de "
a '
).PCDATA
(Parsed Character DATA): expandirá entidades y se debe
escapar <
, &
(y >
dependiendo del lenguaje/versión de marcado).body
, div
, pre
, etc, pero también textarea
(hasta
HTML5) pertenecen a este tipo.<
, &
(,>
)
(como mínimo).RCDATA
(Replaceable Character DATA): no tratará las etiquetas dentro del
texto como marcado (pero siguen rigiéndose por la regla 1), por lo que no es necesario
codificar <
(>
). PERO las entidades siguen expandiéndose, por lo que y#39;ambiguos
ambiguos' (&
) requieren un cuidado especial.RCDATA
y (cita):El texto de los elementos
raw text
yRCDATA
no debe contener ninguna apariciones de la cadena"</"
(U+003C SIGNO MENOR, U+002F SOLIDUS) seguida de caracteres que coincidan de forma insensible a mayúsculas y minúsculas con el nombre de etiqueta de el elemento seguido de uno de los caracteres U+0009 CHARACTER TABULATION (tabulación), U+000A LINE FEED (LF), U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR), U+0020 ESPACIO, U+003E SIGNO MAYOR (>), o U+002F SOLIDUS (/). Así que, pase lo que pase, textarea necesita un gestor de traducción de entidades o si no, ¡acabará Mojibake en las entidades!
CDATA
(Character Data) no tratará las etiquetas dentro del texto como
y no expandirá las entidades.CDATA
?"
y '
) en el fragmento sin procesar y uno necesita algo de javascript para obtener/traducir y establecer el fragmento en otro elemento (visible) (o simplemente establecerlo como valor de un área de texto's). De alguna manera esto me dio problemas con las entidades en FF (al igual que en un textarea). Pero realmente no importa, ya que el 'precio' de tener que escapar/codificar las comillas anidadas es mayor que un textarea (HTML5) (las comillas son bastante comunes en el código fuente..).
¿Qué hay de tratar de (ab)usar <![CDATA[<tag>bla < bla</tag>]]>
?/* */
que envuelve el fragmento sin procesar (las etiquetas de guión pueden tener un id
y se puede acceder a ellas por conteo). Pero como esto obviamente introduce un problema de escape con */
, ]]>
y </script
en el fragmento sin procesar, esto tampoco parece una solución.
Por favor, publica otros 'contenedores' viables en los comentarios a esta respuesta.
Por cierto, codificar o contar el número de caracteres -
y equilibrarlos dentro de una etiqueta de comentario <!-- -->
es una locura para este propósito (aparte de la regla 1).<!-- ATTENTION: replace any occurrence of </xmp with </xmp -->
<xmp id="snippet-container">
<div>
<div>this is an example div & holds an xmp tag:<br />
<xmp>
<html><head> <!-- indentation col 0!! -->
<title>My Title</title>
</head><body>
<p>hello world !!</p>
</body></html>
</xmp> <!-- note this encoded/escaped tag -->
</div>
This line is also part of the snippet
</div>
</xmp>
El bloque de código anterior ilustra un fragmento de marcado sin procesar en el que <xmp id="snippet-container">
contiene un fragmento de código (casi sin procesar) (que contiene div>div>xmp>html-document
).
¿Nota la etiqueta de cierre codificada en este marcado? Para cumplir la regla nº 1, se ha codificado/escapado).
Así que incrustar/transportar el código (a veces casi) en bruto está/parece resuelto.
¿Qué pasa con la visualización/representación del fragmento (y ese </xmp>
codificado)?
El navegador mostrará (o debería mostrar) el fragmento (el contenido dentro del snippet-container
) exactamente como se ve en el bloque de código anterior (con alguna discrepancia entre navegadores sobre si el fragmento empieza o no con una línea en blanco).
Eso incluye el formato/indentación, entidades (como la cadena &
), etiquetas completas, comentarios Y la etiqueta de cierre codificada </xmp>
(tal como estaba codificada en el marcado). Y dependiendo del navegador(versión) uno podría incluso intentar usar la propiedad contenteditable="true"
para editar este fragmento (todo eso sin javascript habilitado). Hacer algo como textarea.value=xmp.innerHTML
también es pan comido.
Así que puedes... si el fragmento no contiene la secuencia de caracteres de cierre del contenedor.
Sin embargo, si un fragmento sin procesar contiene la secuencia de caracteres de cierre </xmp
(porque es un ejemplo del propio xmp o contiene alguna regex, etc), debes aceptar que tienes que codificar/escapar esa secuencia en el fragmento sin procesar Y necesitas un manejador javascript para traducir esa codificación para mostrar/presentar el </xmp>
como </xmp>
dentro de un textarea
(para editar/publicar) o (por ejemplo) un pre
sólo para renderizar correctamente el código del snippet's (o eso parece).
Un ejemplo muy rudimentario [jsfiddle de esto aquí][6]. Nótese que la obtención/incrustación/visualización/recuperación de textarea funcionaba perfectamente incluso en IE6. Pero establecer el xmp
's innerHTML
reveló algún interesante 'posible-inteligente' comportamiento por parte de IE's. Hay una nota más extensa y una solución en el fiddle.
Pero ahora viene lo importante (otra razón por la que sólo te acercas mucho):
Sólo como un ejemplo demasiado simplificado, imagina este agujero de conejo:
Fragmento de código en bruto:
<!-- remember to translate between </xmp> and </xmp> -->
<xmp>
<p>a paragraph</p>
</xmp>
Bien, para cumplir con la regla 1, sólo necesitamos codificar esas secuencias </xmp[> \n\t\f/]
, ¿verdad?
Así que eso nos da el siguiente marcado (utilizando sólo una posible codificación):
<xmp id="container">
<!-- remember to translate between </xmp> and </xmp> -->
<xmp>
<p>a paragraph</p>
</xmp>
</xmp>
Hmm .. ¿Debo obtener mi bola de cristal o lanzar una moneda? No, que el ordenador mire el reloj de su sistema y diga que un número derivado es 'aleatorio'. Sí, eso debería hacerlo ..
Usando una regex como: xmp.innerHTML.replace(/<(?=\/xmp[> \n\r\t\f\/])/gi, '<');
, se traduciría 'de vuelta' a esto:
<!-- remember to translate between </xmp> and </xmp> -->
<xmp>
<p>a paragraph</p>
</xmp>
Hmm .. parece que este generador aleatorio está roto ... ¿Houston?
Si te has perdido el chiste/problema, vuelve a leer empezando por el 'fragmento de código en bruto'.
Espera, ya sé, necesitamos (también) codificar .... a ....
Vale, rebobina hasta el 'fragmento de código en bruto previsto' y vuelve a leer.
De alguna manera todo esto empieza a oler como la famosa hilarante-pero-verdadera rexgex-respuesta en SO, una buena lectura para gente con fluidez en mojibake.
Quizás alguien conozca un algoritmo inteligente o una solución para arreglar este problema, pero asumo que el código crudo incrustado se volverá más y más oscuro hasta el punto en el que sería mejor escapar/codificar adecuadamente sólo tus <
, &
(y >
), como el resto del mundo.
Conclusión: (usando la etiqueta xmp
)
Espero que te sirva de ayuda.
PS:
Aunque agradecería un upvote si encuentras útil esta explicación, creo que la respuesta de Jukka'debería ser la respuesta aceptada (si no aparece ninguna opción/respuesta mejor), ya que fue él quien se acordó de la etiqueta xmp (que yo olvidé con los años y me 'distraje' con los elementos PCDATA comúnmente recomendados como pre
, textarea
, etc.).
Esta respuesta se originó para explicar por qué no puedes hacerlo (con cualquier fragmento sin formato desconocido) y explicar algunas trampas obvias que algunas otras respuestas (ahora eliminadas) pasaron por alto al aconsejar un textarea para incrustar/transportar. He expandido mi explicación existente para también apoyar y explicar mejor la respuesta de Jukka (ya que todo ese asunto de entidades y *CDATA es casi más difícil que las páginas de código).