OmniDocWanneer & op de vertaalde webpagina verschijnt, wordt deze dan nog een keer gedecodeerd?
Wanneer een string van `&` op de pagina wordt weergegeven, is de eerste reactie vaak het opnieuw decoderen ervan. Maar het probleem kan ook het tegenovergestelde zijn: hetzelfde stukje inhoud is al ontsnapt en wordt opnieuw ontsnapt door de sjabloon. Zoek eerst uit of wat u krijgt originele HTML-, DOM-tekst of een gewone tekenreeks is die in de pagina moet worden ingevoegd, en beslis vervolgens of u deze wilt converteren.
Ontwikkelaars die webpagina's of documenten vertalen, stuiten vaak op een intuïtief probleem: er verschijnt een reeks & op de vertaalde pagina, zodat ze onbewust denken: "Is het een decodering minder?" Maar het tegenovergestelde kan ook waar zijn: hetzelfde stukje inhoud dat al is ontsnapt, wordt opnieuw door de sjabloon ontsnapt.
Dit artikel helpt u eerst te bepalen wat u in handen heeft: onbewerkte HTML, DOM-tekst of een gewone tekenreeks die klaar is om in de pagina te worden ingevoegd. Begrijp dit voordat u besluit of u wilt overstappen, en verifieer de hele verwerkingsketen met een klein monster.
& verschijnt op de pagina. Wil je het opnieuw decoderen? Conclusie in één zin
Bevestig eerst in welke staat de huidige gegevens zich bevinden en beslis vervolgens of u deze wilt converteren; raad niet of je nog een laag moet oplossen op basis van het uiterlijk van de string.
| jouw situatie | Aanbevolen praktijken | reden |
|---|---|---|
| Wat je krijgt is de originele HTML en je moet de tekst vertalen | Gebruik de parser om tekstknooppunten te lokaliseren en deze vervolgens te verwerken | Het rechtstreeks vervangen van tekenreeksen in de broncode kan tags en attributen gemakkelijk per ongeluk beschadigen. |
| Wat je krijgt is DOM-tekst | Meestal niet meer onvoorwaardelijk decoderen | De tekst bevat al semantische inhoud en voor verdere decodering is mogelijk nog een laag van begrip nodig. |
| Wat u krijgt is de platte tekst van de vertaling, die op de pagina moet worden weergegeven. | Laat het aan de sjabloon over om als tekst te ontsnappen | Laat de uitvoerpositie de serialisatiemethode bepalen |
Letterlijke waarden zoals <div> worden op de pagina weergegeven | Bevestig eerst het invoerprotocol en beslis vervolgens of u een laag wilt oplossen | Dergelijke inhoud kan opzettelijk gereserveerde letterlijke waarden zijn |
| Moet wat rijke tekst behouden | Gebruik een duidelijke schoonmaakstrategie | Toegestane fragmenten zijn onderworpen aan gecontroleerde regels |
Ontsnappen is een kwestie van uitvoergrenzen
html.escape converteert tekens met HTML-betekenis in gewone tekst naar entiteiten, terwijl html.unescape entiteiten ontleedt. De twee zijn geen ‘reinigingsstappen’ die door elkaar kunnen worden genoemd. De vertaler heeft meestal semantische tekst nodig, en de sjabloon heeft een geserialiseerd resultaat nodig dat voldoet aan de huidige positieregels.
De productnaam R&D heeft bijvoorbeeld geen probleem wanneer deze als tekst wordt weergegeven, maar wordt gewoonlijk uitgedrukt als R&D wanneer deze in HTML-broncode wordt geschreven. Als er opnieuw aan wordt ontsnapt, wordt het R&amp;D en geeft de browser de entiteit letterlijk in het midden weer. Omgekeerd, als de niet-vertrouwde inhoud wordt gedecodeerd en rechtstreeks als HTML wordt ingevoegd, kunnen de tags daarin opnieuw worden geactiveerd.
Doe een klein experiment met drie toestanden
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')Dit is een voorbeeld van een synthetische transformatie uit de standaardbibliotheek die geen HTML of scripts uitvoert. De laatste twee regels demonstreren "uitvoer als tekst"-verwerking, wat geen veilige oplossing voor het opschonen van HTML is, en hieruit volgt ook niet dat het veilig is om willekeurige resultaten in JavaScript, CSS of URL's te plaatsen. Verschillende contexten vereisen verschillende regels.
Geef de gegevensstatus eerst een naam
U kunt source_html, plain_text, translated_text en rendered_html gebruiken om elke fase te onderscheiden om te voorkomen dat u verschillende typen content aanroept. Als het project dit toelaat, kunt u het ook inpakken met een lichtgewicht gegevensklasse om duidelijk te maken welke functie alleen platte tekst accepteert.
Het benoemen is geen vervanging voor testen, maar kan wel helpen bij het opsporen van bedradingsfouten, zoals het "terugsturen van de uiteindelijke HTML naar de vertaler" tijdens de beoordeling.
| Huidige ingang | waar je op moet hopen | Moet eerst bevestigd worden |
|---|---|---|
| Ruwe HTML | Vertaalbare tekst | Zoek tekstknooppunten met behulp van parser |
| DOM-tekst | Tekst in de doeltaal | Meestal moet je niet onvoorwaardelijk decoderen |
| De vertaling is pure tekst | Tekst is zichtbaar op de pagina | Laat sjablonen ontsnappen aan tekstdefinities |
| Staat rich text toe | Beveiligingsbeeldclip | Gebruik een duidelijke schoonmaakstrategie |
Herhaal het decoderen niet tot "geen veranderingen meer"
Deze aanpak lijkt meerdere lagen te verwerken, maar in werkelijkheid verstoort het de code die gebruikers oorspronkelijk wilden tonen. De <div> in de tutorial kunnen opzettelijk gereserveerde letterlijke getallen zijn, niet tags die zijn weggelaten.
Of een andere laag gedecoderd moet worden, moet worden bepaald door het invoerprotocol en kan niet worden afgeleid uit het uiterlijk van de string. Links, attribuutwaarden en codeblokken in het lichaam kunnen ook verschillende vertaalstrategieën hebben. Het bewaren van een set regressievoorbeelden met hoekhaakjes, aanhalingstekens en en-en entiteitsliteralen om de geparseerde tekst en het uiteindelijke browserdisplay te controleren, is nuttiger dan alleen de bronbestandsstrings te vergelijken.
De grenzen van vertaling bewaken met kleine voorbeelden
Bij het evalueren van documentvertalingsportalen zoals OmniDoc (Productinvoer) kun je bovenstaande voorbeeld in een HTML-testbestand zetten om te zien of de tagvoorbeelden en productnamen in de vertaling nog steeds worden weergegeven zoals verwacht.
"Vertaald in het Engels" zou niet het enige criterium voor voltooiing moeten zijn. Inhoudsbetekenis, escape-lagen en codebescherming maken allemaal deel uit van de levering.
Dit artikel demonstreert de verwerkingsmethode met behulp van synthetische monsters. De code heeft voorbeeldcontroles doorstaan in een geïsoleerde omgeving; Dit is geen garantie voor alle authentieke documenten of productprestaties. Bewaar voordat u belangrijke documenten behandelt de originelen en bekijk deze volgens de grenzen en acceptatiepunten in het document.
Bronnen: Python HTML-module.
📊 Kernvergelijking
| Methode | Toepasselijke scenario's | Grote risico's |
|---|---|---|
| Decodeer het in een lus totdat de snaar niet meer verandert | Wanneer er geen expliciete invoerovereenkomst is | Het zal letterlijke codes breken die getoond moeten worden |
| Of laag 1 gedecoderd moet worden, hangt af van het invoerprotocol | De huidige status van de gegevens is bekend | Je moet eerst verduidelijken in welke fase de data zich bevindt |
| Na de vertaling wordt de platte tekst aan het sjabloon gegeven om te parafraseren volgens de tekst | Alleen platte tekst wordt weergegeven | Als tekst al is ontsnapt en verouderd, wordt deze opnieuw geëscaped, wat resulteert in&amp; |
🎯 Welke methode past bij jou?
Als je de originele HTML krijgt
Gebruik eerst een parser om tekstknopen te lokaliseren, waarbij alleen de tekstinhoud wordt vertaald zonder stringvervanging voor de gehele broncode.
Als je een DOM-sms krijgt,
Meestal is er geen verdere decodering nodig; je kunt het gewoon als platte tekst verwerken.
Als je de vertaling in de pagina wilt invoegen
Laat het aan het sjabloon over om via tekst te ontsnappen; decodeer het niet eerst en voeg het dan in als HTML.
Als de pagina code moet tonen zoals <div>,
Bevestig eerst het invoerprotocol; het kan opzettelijk letterlijk worden gereserveerd en mag niet als een gemist-label worden behandeld.
❓ Veelgestelde Vragen (FAQ)
1. Toont de pagina &—betekent dat dat het meerdere keren is gedecodeerd?
Niet per se. Het kan ook zijn dat dezelfde inhoud al is ontsnapt en vervolgens opnieuw ontsnapt door de template, bijvoorbeeld R&D wordt R&D en vervolgens R&amp;D.
2. Kan het in een lus worden gedecodeerd totdat de string stopt met veranderen?
Niet aan te raden. Deze aanpak breekt code die letterlijk weergegeven moet worden, en of een laag gedecoderd moet worden, moet door het invoerprotocol worden bepaald.
3. Kan vertaalde tekst direct als HTML worden ingevoegd?
Kan niet direct worden ingevoegd. Gedecodeerde inhoud kan zijn tags opnieuw activeren, dus je moet eerst onderscheid maken tussen platte tekst en toegestane rich text.
4. Waarom kun je de strings in het bronbestand niet gewoon vergelijken?
Bronbestandsstrings kunnen de geparsde tekst en het uiteindelijke browserscherm niet weergeven. Beide moeten afzonderlijk worden gecontroleerd om te bevestigen of het aantal escape-lagen correct is.
📝 Samenvatting
Wanneer je & tegenkomt, verduidelijk dan eerst of je originele HTML, DOM-tekst of een gewone string krijgt, en beslis daarna of je deze wilt converteren. Alleen door een set regressiemonsters te gebruiken om de ontsnappingsgrens te bewaken, kunnen de vertaalresultaten echt betrouwbaar zijn.
Ervaar nu: upload je document om te beginnen met vertalen, waarbij je de originele opmaak behoudt
