Come visualizzare codice HTML grezzo in PRE o qualcosa di simile ma senza sfuggirgli

Mi piacerebbe visualizzare HTML non elaborato. Sappiamo tutti che è necessario sfuggire a ogni “” in questo modo

 this is a test &ltDIV&gt 

Tuttavia, non voglio farlo. Mi piacerebbe un modo per mantenere il codice HTML così com’è (dal momento che è più facile da leggere, (all’interno dell’editor) e potrei volerlo copiare e usarlo di nuovo come codice HTML effettivo, e non voglio doverlo cambiala di nuovo o dispone di 2 versioni dello stesso codice di escape e non di escape.

C’è un altro ambiente che è più “crudo” di PRE che potrebbe consentire questo? Quindi non è necessario continuare a modificare HTML e cambiare tutto ogni volta che vogliono mostrare codice HTML grezzo, potrebbe essere in HTML5?

Qualcosa come ...... </

immagine dello schermo

La soluzione javascript non funziona su FF 21, qui è schermata inserisci la descrizione dell'immagine qui

schermata 2

La prima soluzione non funziona ancora su Firefox, qui è la schermata inserisci la descrizione dell'immagine qui

Puoi usare l’elemento xmp , vedi a cosa è stato usato il tag

? . È stato in HTML sin dall&#8217;inizio ed è supportato da tutti i browser. Le specifiche lo disapprovano, ma HTML5 CR lo descrive ancora e richiede ai browser di supportarlo (anche se dice anche agli autori di non usarlo, ma non può davvero impedirti).

Tutto ciò che è contenuto in xmp viene preso come tale, nessun markup (tag o riferimenti di caratteri) viene riconosciuto lì, tranne, per ragioni apparenti, il tag di fine dell’elemento stesso, .

Altrimenti xmp è reso come pre .

Quando si utilizza “XHTML reale”, ovvero XHTML servito con un tipo di supporto XML (che è raro), le regole di parsing speciali non si applicano, quindi xmp viene trattato come pre . Ma in “real XHTML”, puoi usare una sezione CDATA, che implica regole di parsing simili. Non ha una formattazione speciale, quindi probabilmente vorrai avvolgerlo in un pre elemento:

 
 will appear literally. ]]>

Non vedo come si possa combinare la sezione xmp e CDATA per ottenere il cosiddetto markup polyglot

Essenzialmente la domanda originale può essere suddivisa in 2 parti:

  • Obiettivo / sfida principale: incorporare (/ trasportare) un codice snippet formattato in modo raw (qualsiasi tipo di codice) nel markup di una pagina Web (per semplice copia / incolla / modifica a causa della mancata codifica / escaping)
  • visualizzazione / rendering corretto di quello snippet di codice (possibilmente modificarlo) nel browser

La risposta breve (ma) ambigua è: non puoi , ma puoi (avvicinarti molto).
(Lo so, sono 3 risposte contraddittorie, quindi continua a leggere …)

(polyglot) (x) (ht) ml I linguaggi di markup si basano sul wrapping (quasi) di tutto tra inizio / apertura e fine / chiusura tag / carattere (sequenze).
Quindi, per incorporare qualsiasi tipo di codice / snippet all’interno del tuo linguaggio di markup, dovrai sempre fuggire / codificare ogni istanza (all’interno di quel frammento) che assomiglia al carattere (-sequence) che chiuderebbe l’elemento ‘contenitore’ del wrapping in il markup. ( Durante questo post mi riferirò a questo come regola n . 1 ).
Pensa a "some "data" here" o ..close italics with ''-tag , dove è ovvio che uno dovrebbe scappare / codificare (qualcosa in) e " ( oppure cambia il carattere preventivo del contenitore da " a ' ).

Pertanto, a causa della regola n. 1, non è ansible "solo" incorporare "uno snippet di codice non elaborato sconosciuto all'interno del markup.
Perché, se si deve scappare / codificare anche un solo carattere all'interno dello snippet non elaborato, lo snippet non sarà più lo stesso "codice raw originale" originale che chiunque può copiare / incollare / modificare nel markup del documento senza ulteriori riflessioni . Porterebbe a markup malformato / illegale e Mojibake (principalmente) a causa di quadro.
Inoltre, se lo snippet dovesse contenere tali caratteri, avresti comunque bisogno di un javascript per "tradurre" quel carattere (sequenza) da (e per) alla sua rappresentazione in escape / codificata per visualizzare correttamente lo snippet nella "pagina web" (per copia / incolla /modificare).

Questo ci porta a (alcuni dei) tipi di dati che i linguaggi di markup specificano. Questi tipi di dati definiscono essenzialmente quelli che sono considerati "caratteri validi" e il loro significato (per tag, proprietà, ecc.):

  • PCDATA (Parsed Character DATA): espande le entity framework e si deve sfuggire a < , & (e > seconda del linguaggio / versione del markup).
    La maggior parte dei tag come body , div , pre , ecc., Ma anche textarea (fino a HTML5) rientrano in questo tipo.
    Quindi non solo hai bisogno di codificare tutte le sequenze di caratteri del contenitore all'interno dello snippet, devi anche codificare tutti i caratteri < , & (, > ) (almeno).
    Inutile dire che codificare / sfuggire questo numero di caratteri non rientra nell'ambito di questo objective di incorporare uno snippet non elaborato nel markup.
    '... Ma una textarea sembra funzionare ...', sì, a causa del motore di errore dei browser che cerca di ricavarne qualcosa o perché HTML5:

  • RCDATA (DATI caratteri sostituibili): non tratterà i tag all'interno del testo come markup (ma sono ancora governati dalla regola 1), quindi non è necessario codificare < ( > ). MA le quadro sono ancora espanse, quindi loro e 'ambigui e commerciali' ( & ) hanno bisogno di cure particolari.
    L' attuale specifica HTML5 dice che textarea è ora un campo RCDATA e (citazione):

    Il testo in raw text RCDATA e RCDATA elementi RCDATA non devono contenere occorrenze della stringa " (U + 003C SEGNALE INFERIORE, U + 002F SOLIDO) seguito da caratteri che non corrispondono in modo insensibile al nome dell'etichetta dell'elemento seguito da uno di U + 0009 TABULAZIONE CARATTERI (scheda), U + 000A LINE FEED (LF), U + 000C FORM FEED (FF), U + 000D RITORNO CARRELLO (CR), U + 0020 SPAZIO, U + 003E MAGGIORE-QUANDO IL SEGNO (>) o U + 002F SOLIDUS (/).

    Quindi non importa cosa, textarea ha bisogno di un potente gestore di traduzioni di quadro o finirà con il Mojibake sulle entity framework!

  • CDATA (Character Data) non tratterà i tag all'interno del testo come markup e non espanderà le entity framework .
    Quindi, finché il codice snippet non viola la regola 1 (che non è ansible che i contenitori chiudano il carattere (sequenza) all'interno dello snippet), ciò non richiede altra escaping / codifica.

Chiaramente questo si riduce a: come possiamo minimizzare il numero di caratteri / sequenze di caratteri che devono ancora essere codificati nella sorgente grezza del frammento e il numero di volte in cui il carattere (sequenza) potrebbe apparire in uno snippet medio; qualcosa che è anche importante per il javascript che gestisce la traduzione di questi personaggi (se si verificano).

Quindi quali "contenitori" hanno questo contesto CDATA ?

La maggior parte delle proprietà di valore dei tag sono CDATA, quindi è ansible (ab) utilizzare la proprietà value di un input nascosto ( proof of concept jsfiddle qui ).
Tuttavia (regola 1 conforms) crea un problema di codifica / fuga con le virgolette nidificate ( " e ' ) nello snippet non elaborato e uno richiede un javascript per ottenere / tradurre e impostare lo snippet in un altro elemento (visibile) (o semplicemente impostandolo come un valore dell'area di testo) In qualche modo questo mi ha dato problemi con le quadro in FF (proprio come in una textarea), ma non importa, dal momento che il "prezzo" di dover evadere / codificare le virgolette nidificate è più alto di un ( HTML5) textarea (le virgolette sono abbastanza comuni nel codice sorgente ..).

Che ne dici di provare a (ab) usare bla & bla]]> ?
Come sottolinea Jukka nella sua risposta estesa, ciò funzionerebbe solo in (raro) "vero xhtml".
Ho pensato di utilizzare un tag script (con o senza un wrapper CDATA all'interno del tag script) insieme a un commento su più righe /* */ che avvolge lo snippet non elaborato (i tag script possono avere un id e puoi accedere loro per numero). Ma poiché questo ovviamente introduce un problema di escape con */ , ]]> e nello snippet non elaborato, anche questa non sembra una soluzione .

Si prega di inviare altri 'contenitori' validi nei commenti a questa risposta.

A proposito, codificare o contare il numero di - caratteri e bilanciarli all'interno di un tag di commento è semplicemente folle per questo scopo (a parte la regola 1).


Questo ci lascia con l'eccellente risposta di Jukka K. Korpela : il tag

sembra l'opzione migliore!

Il 'dimenticato'

contiene CDATA , è inteso per questo scopo E è ancora ancora nell'attuale specifica HTML 5 (ed è stato almeno dal momento che HTML3.2); esattamente ciò di cui abbiamo bisogno! È anche ampiamente supportato, anche in IE6 (cioè ... finché non subisce la stessa regressione del corpo del tavolo a scorrimento).
Nota: come ha sottolineato Jukka, questo non funzionerà nel vero xhtml o poliglotta (che lo tratterà come un pre ) e il tag xmp deve ancora rispettare la regola n. 1. Ma questa è la regola "unica".

Considera il seguente markup:

  My Title  

hello world !!

</xmp>
This line is also part of the snippet

Il precedente codeblok illustra un pezzo grezzo di markup in cui

contiene uno snippet di codice (quasi grezzo) (contenente div>div>xmp>html-document ).
Si noti il ​​tag di chiusura codificato in questo markup? Per rispettare la regola n. 1, questo è stato codificato / fugato).

Quindi l'incorporamento / trasporto del codice grezzo (a volte quasi) è / sembra risolto.

Per quanto riguarda la visualizzazione / rendering dello snippet (e quello codificato </xmp> )?

Il browser renderà (o dovrebbe) rendere lo snippet (il contenuto all'interno del snippet-container ) esattamente nel modo in cui lo vedi nel codeblock sopra (con qualche discrepanza tra i browser, indipendentemente dal fatto che lo snippet inizi con una riga vuota).
Ciò include la formattazione / indentazione, quadro (come la stringa & ), tag completi, commenti AND il tag di chiusura codificato </xmp> (proprio come è stato codificato nel markup) . E a seconda del browser (versione) si potrebbe anche provare a utilizzare la proprietà contenteditable="true" per modificare questo snippet (tutto ciò senza javascript abilitato). Fare qualcosa come textarea.value=xmp.innerHTML è anche un gioco da ragazzi.

Quindi puoi ... se lo snippet non contiene i contenitori che chiudono la sequenza di caratteri.

Tuttavia , se uno snippet non elaborato contiene la sequenza di caratteri di chiusura (perché è un esempio di xmp stesso o contiene alcune espressioni regolari, ecc.), Devi accettare che devi codificare / evadere quella sequenza nello snippet raw E bisogno di un gestore javascript per tradurre quella codifica per visualizzare / rendere la codifica </xmp> come all'interno di una textarea (per la modifica / pubblicazione) o (per esempio) un pre solo per rendere correttamente il codice dello snippet (o così sembra).

Un esempio jsfiddle molto rudimentale di questo qui . Nota che ottenere / embedding / displaying / retrieving-to-textarea ha funzionato perfettamente anche in IE6. Ma l'impostazione xmp di xmp rivelato un interessante comportamento 'sarebbe-essere-intelligente' da parte di IE. C'è una nota più ampia e una soluzione a questo proposito nel violino.

Ma ora arriva l' importante kicker (un'altra ragione per cui vieni solo molto vicino ): proprio come un esempio troppo semplificato, immagina questa tana del rabbitmq :

Snippet di codice non elaborato previsto:

   <p>a paragraph</p>  

Bene, per rispettare la regola 1, abbiamo 'solo' bisogno di codificare quelle sequenze \n\r\t\f\/] , giusto?

Quindi questo ci dà il seguente markup (usando solo una ansible codifica):

  <!-- remember to translate between &lt;/xmp> and &lt;/xmp> -->  <p>a paragraph</p> &lt;/xmp>  

Hmm .. potrò prendere la mia sfera di cristallo o lanciare una moneta? No, lascia che il computer guardi il suo orologio di sistema e dichiari che un numero derivato è "casuale". Sì, dovrebbe farlo ..

Utilizzando una xmp.innerHTML.replace(/<(?=\/xmp[> \n\r\t\f\/])/gi, '<'); come : xmp.innerHTML.replace(/<(?=\/xmp[> \n\r\t\f\/])/gi, '<'); , tradurrebbe 'indietro' a questo:

   <p>a paragraph</p>  

Hmm .. sembra che questo generatore casuale sia rotto ... Houston ..?
Se hai perso lo scherzo / problema, leggi di nuovo a partire dal 'codice non elaborato - snippet'.

Aspetta, lo so, abbiamo (anche) bisogno di codificare .... per ....
Ok, riavvolgi lo "snippet di codice non elaborato" e rileggi.
In qualche modo tutto questo comincia a puzzare come la famosa esilarante-ma-vera rexgex-risposta su SO , una buona lettura per le persone fluenti nel mojibake.

Forse qualcuno conosce un algoritmo o una soluzione intelligente per risolvere questo problema, ma presumo che il codice raw incorporato diventerà sempre più oscuro al punto in cui si sarebbe meglio di escaping / encoding correttamente solo i tuoi < , & (e > ) , proprio come il resto del mondo.

Conclusione: (usando il tag xmp )

  • può essere fatto con snippet noti che non contengono la sequenza di caratteri di chiusura del contenitore,
  • possiamo avvicinarci molto all'objective originale con frammenti noti che usano solo la "fuga / codifica di base di primo livello" in modo che non cadiamo nella rabbithole,
  • ma alla fine sembra che non si possa fare questo in modo affidabile in un "ambiente di produzione" in cui le persone possono / dovrebbero copiare / incollare / modificare 'frammenti grezzi sconosciuti' senza conoscere / comprendere le implicazioni / regole / rabbithole (a seconda del proprio implementazione di manipolazione / traduzione per la regola 1 e la tana del rabbitmq).

Spero che questo ti aiuti!

PS: Anche se apprezzerei un upvote se ritieni che questa spiegazione sia utile, penso che la risposta di Jukka dovrebbe essere la risposta accettata (non dovrebbe esserci alcuna opzione / risposta migliore), dal momento che è stato lui a ricordare il tag xmp (che io dimenticato nel corso degli anni e 'distratto' dagli elementi PCDATA comunemente sostenuti come pre , textarea , ecc.
Questa risposta ha avuto origine nello spiegare perché non è ansible farlo (con qualsiasi frammento grezzo sconosciuto) e spiegare alcune ovvie insidie ​​che altre risposte (ora cancellate) hanno trascurato quando si consigliava un'area di testo per l'incorporamento / trasporto. Ho ampliato la mia spiegazione esistente per supportare e spiegare ulteriormente la risposta di Jukka (dato che tutta questa quadro e * materiale CDATA è quasi più difficile delle pagine di codice).

Risposta economica e allegra:

  

La textarea gestirà tabulazioni, spazi multipli, newline, line wrapping tutti alla lettera. Copia e incolla piacevolmente e il suo codice HTML valido fino in fondo. Permette anche all’utente di ridimensionare la casella del codice. Non hai bisogno di CSS, JS, escaping, encoding.

Puoi anche modificare l’aspetto e il comportamento. Ecco un font monospace, modifica disabilitata, font più piccolo, no border:

  

Questa soluzione probabilmente non è semanticamente corretta. Quindi, se ne hai bisogno, potrebbe essere meglio scegliere una risposta più sofisticata.

 echo '
' . htmlspecialchars("
raw HTML
") . '

';

Penso che sia quello che stai cercando?

In altre parole, usa htmlspecialchars () in PHP

@GitaarLAB e @Jukka hanno elaborato che il tag

è obsoleto, ma è comunque il migliore. Quando lo uso in questo modo

  <div>Lorem ipsum</div> <p>Hello</p>  

quindi il primo EOL è inserito nel codice e sembra orribile .

Può essere risolto rimuovendo quel EOL

 <div>Lorem ipsum</div> <p>Hello</p>  

ma poi sembra male alla fonte. Ho usato per risolverlo con il wrapping

, ma recentemente ho scoperto una bella regola CSS3, spero che aiuti anche qualcuno:

 xmp { margin: 5px 0; padding: 0 5px 5px 5px; background: #CCC; } xmp:before { content: ""; display: block; height: 1em; margin: 0 -5px -2em -5px; } 

Questo sembra migliore .

xmp è la strada da percorrere, cioè:

  # your code...  

Se hai abilitato jQuery, puoi utilizzare una funzione escapeXml e non doversi preoccupare delle frecce di escape o dei caratteri speciali.

 
 ${fn:escapeXml('  ')};