OmniDocQuando & appare sulla pagina web tradotta, viene decodificata ancora una volta?
Quando sulla pagina viene visualizzata la stringa `&`, la prima reazione è spesso quella di decodificarla nuovamente. Ma il problema può anche essere il contrario: lo stesso contenuto è già stato sottoposto a escape e viene nuovamente sottoposto a escape dal template. Per prima cosa capisci se quello che stai ottenendo è HTML originale, testo DOM o una normale stringa da inserire nella pagina, e poi decidi se convertirlo.
Gli sviluppatori che traducono pagine web o documenti spesso incontrano un problema intuitivo: sulla pagina tradotta appare una stringa &, quindi inconsciamente pensano "È una decodifica in meno?" Ma può anche essere vero il contrario: lo stesso contenuto di cui è già stato eseguito l'escape viene nuovamente eseguito l'escape del template.
Questo articolo ti aiuta innanzitutto a determinare cosa hai in mano: HTML grezzo, testo DOM o una normale stringa pronta per essere inserita nella pagina. Comprenderlo prima di decidere se cambiare e poter verificare con un piccolo campione tutta la filiera di lavorazione.
& appare sulla pagina. Vuoi decodificarlo di nuovo? Conclusione di una frase
Per prima cosa conferma in quale stato si trovano i dati correnti, quindi decidi se convertirli; non indovinare se risolvere un altro livello in base all'aspetto della stringa.
| la tua situazione | Pratiche consigliate | motivo |
|---|---|---|
| Ciò che ottieni è l'HTML originale e devi tradurre il testo | Utilizzare il parser per individuare i nodi di testo e quindi elaborarli | La sostituzione diretta delle stringhe nel codice sorgente può facilmente danneggiare per errore tag e attributi. |
| Ciò che ottieni è il testo DOM | Di solito non decodificano più incondizionatamente | Il testo è già contenuto semantico e un'ulteriore decodificazione potrebbe richiedere un ulteriore livello di comprensione. |
| Ciò che ottieni è il testo semplice della traduzione, che deve essere visualizzato sulla pagina. | Lascia che sia il modello a scappare come testo | Lascia che sia la posizione di output a determinare il metodo di serializzazione |
I valori letterali come <div> vengono visualizzati nella pagina | Confermare prima il protocollo di input, quindi decidere se risolvere un livello | Tali contenuti possono essere letterali intenzionalmente riservati |
| È necessario conservare del testo ricco | Utilizzare una strategia di pulizia chiara | I frammenti consentiti sono soggetti a regole controllate |
La fuga è una questione di confini di output
html.escape converte i caratteri con significato HTML nel testo ordinario in entità, mentre html.unescape analizza le entità. I due non sono "fasi di pulizia" che possono essere chiamati in modo intercambiabile. Il traduttore di solito ha bisogno di testo semantico e il modello ha bisogno di un risultato serializzato che sia conforme alle regole di posizione attuali.
Ad esempio, il nome del prodotto R&D non presenta problemi se visualizzato come testo, ma viene solitamente espresso come R&D se scritto nel codice sorgente HTML. Se viene eseguito nuovamente l'escape, diventerà R&amp;D e il browser visualizzerà l'entità letterale al centro. Al contrario, se il contenuto non attendibile viene decodificato e inserito direttamente come HTML, i tag in esso contenuti potrebbero essere riattivati.
Fai un piccolo esperimento utilizzando tre stati
import html
plain = 'R&D <Guide> "2026"'
encoded = html.escape(plain, quote=True)
double_encoded = html.escape(encoded, quote=True)
assert encoded == 'R&D <Guide> "2026"'
assert html.unescape(encoded) == plain
assert html.unescape(double_encoded) == encoded
assert html.unescape(double_encoded) != plain
untrusted = '<img src=x onerror=alert(1)>'
decoded = html.unescape(untrusted)
safe_as_text = html.escape(decoded, quote=True)
assert decoded.startswith('<img')
assert safe_as_text.startswith('<img')Questo è un esempio di trasformazione sintetica dalla libreria standard che non esegue HTML o script. Le ultime due righe dimostrano l'elaborazione dell'"output come testo", che non è una soluzione sicura per la pulizia dell'HTML, né ne consegue che sia sicuro inserire risultati arbitrari in JavaScript, CSS o URL. Contesti diversi richiedono regole diverse.
Per prima cosa dai un nome allo stato dei dati
È possibile utilizzare source_html, plain_text, translated_text e rendered_html per distinguere ciascuna fase ed evitare di chiamare diversi tipi content. Se il progetto lo consente, puoi anche racchiuderlo con una classe di dati leggera per chiarire quale funzione accetta solo testo semplice.
La denominazione non sostituisce il test, ma può aiutare a trovare errori di cablaggio come "restituire l'HTML finale al traduttore" durante la revisione.
| Ingresso corrente | cosa sperare | Dovrebbe essere confermato prima |
|---|---|---|
| HTML grezzo | Testo traducibile | Individua i nodi di testo utilizzando il parser |
| Testo DOM | testo nella lingua di destinazione | Di solito non decodificano più incondizionatamente |
| Traduzione di testo semplice | Testo visibile sulla pagina | Fai in modo che i modelli escano testualmente |
| Rich text consentito | Clip di visualizzazione sicura | Utilizzare una strategia di pulizia chiara |
Non ripetere la decodifica fino a quando "non ci saranno più modifiche"
Questo modo di scrivere sembra essere in grado di gestire entità multistrato, ma in realtà distruggerà il codice che l'utente voleva originariamente visualizzare. <div> nell'esercitazione potrebbe essere un valore letterale riservato intenzionalmente, anziché un'etichetta che è stata persa.
Se un ulteriore livello debba essere decodificato dovrebbe essere determinato dal protocollo di input e non può essere indovinato dall'aspetto della stringa. Anche i collegamenti, i valori degli attributi e i blocchi di codice nel corpo possono avere strategie di traduzione diverse. Mantenere una serie di campioni di regressione contenenti parentesi angolari, virgolette, e commerciali e valori letterali di entità ed esaminare separatamente il testo analizzato e la visualizzazione finale del browser è più utile del semplice confronto delle stringhe del file di origine.
Utilizza piccoli campioni per proteggere i confini della traduzione
Quando si valuta un portale di traduzione di documenti come OmniDoc (portale del prodotto), è possibile inserire l'esempio riportato sopra in un file di test HTML e osservare se gli esempi di tag e i nomi dei prodotti nella traduzione appaiono ancora come previsto.
La "traduzione in inglese" non dovrebbe essere l'unico criterio di completamento. Il significato del contenuto, i livelli di escape e la protezione del codice fanno tutti parte della consegna.
Questo articolo utilizza campioni sintetici per dimostrare il metodo di elaborazione. Il codice è stato verificato con esempi in un ambiente isolato; ciò non rappresenta una garanzia di tutti i file reali o delle prestazioni del prodotto. Prima di elaborare documenti importanti, conservare gli originali e rivederli rispettando i limiti e gli elementi di accettazione nel testo.
Riferimenti: Modulo html Python.
📊 Confronto fondamentale
| pratica | Scenari applicabili | Principali rischi |
|---|---|---|
| Decodifica in loop diretto finché la stringa non cambia più | Quando il protocollo non è inserito esplicitamente | Distruggerà il codice letterale che dovrebbe essere visualizzato |
| Se risolvere un livello è determinato dal protocollo di input | Conoscere lo stato attuale dei dati | Devi prima capire in quale fase si trovano i dati |
| Dopo la traduzione, il testo normale viene consegnato al modello per l'escape del testo. | Mostra solo testo normale | Se è stato utilizzato l'escape del testo, verrà eseguito l'escape due volte e verrà visualizzato&amp;. |
🎯Quale metodo è adatto a te?
Se ottieni l'HTML grezzo
Per prima cosa utilizza il parser per individuare il nodo di testo, traduci solo il contenuto del testo e non esegui la sostituzione delle stringhe sull'intero codice sorgente.
Se ricevi il testo DOM
Di solito non è necessario decodificarlo e può essere elaborato direttamente come testo normale.
Se vuoi inserire la traduzione nella pagina
Lascia che sia il modello a scappare come testo, non decodificarlo prima e poi inserirlo come HTML.
Se la pagina deve visualizzare codici come <div>
Per prima cosa conferma il protocollo di input, potrebbe essere un valore letterale riservato intenzionalmente e non dovrebbe essere trattato come un tag non elaborato.
❓ Domande frequenti (FAQ)
1. Quando & appare sulla pagina, deve essere stato decodificato ancora una volta?
incerto. Può anche darsi che lo stesso paragrafo di contenuto sia stato sottoposto a escape e nuovamente a escape dal modello, ovvero R&D diventa R&D e poi diventa R&amp;D.
2. È possibile ripetere la decodifica finché la stringa non cambia più?
Non raccomandato. Questo approccio interromperà il codice che dovrebbe essere visualizzato letteralmente e se risolvere un livello dovrebbe essere determinato dal protocollo di input.
3. Il testo tradotto può essere inserito direttamente in formato HTML?
Non è possibile inserirlo direttamente. Il contenuto decodificato può riattivare i tag al suo interno e il testo semplice deve essere distinto dal testo ricco consentito.
4. Perché non possiamo semplicemente confrontare le stringhe dei file sorgente?
La stringa del file di origine non riflette il testo analizzato e la visualizzazione finale del browser. Entrambi dovrebbero essere controllati separatamente per confermare se il numero di strati di fuga è corretto.
📝 Riepilogo
Quando incontri &, scopri prima se l'HTML originale, il testo DOM o la stringa ordinaria che stai ricevendo è l'HTML originale, il testo DOM o la stringa ordinaria, quindi decidi se convertirlo. Solo utilizzando una serie di campioni di regressione per proteggere i confini in fuga i risultati della traduzione possono essere veramente affidabili.
Provalo subito: carica il documento per iniziare la traduzione, mantenendo il layout originale
