HTML-entiteiten decoderen

De voor de hand liggende aanpak is de tekst in een onzichtbaar element zetten en de browser het werk laten doen. Dat is ook de gevaarlijke: op dat moment wordt vreemde markup binnen deze pagina verwerkt, en een `img`-tag met een adres erin veroorzaakt meteen een netwerkverzoek.

Daarom staat er hier een tabel met de namen en een routine voor de numerieke vormen, en wordt er niets gerenderd. Het kost een lijst en het levert een pagina op die geen verzoek uitlokt met tekst die iemand anders heeft geschreven — precies de eigenschap waar de rest van deze sectie ook op leunt.

Een teken kan als naam staan, als decimaal getal of als hexadecimaal getal: `&`, `&` en `&` zijn alle drie de ampersand. Welke vorm je aantreft hangt af van wat het heeft geschreven, en in één document komen ze vaak door elkaar voor.

De numerieke vormen zijn de betrouwbaarste, want ze werken zonder tabel: het getal is het Unicode-codepunt. De namen zijn leesbaarder en er zijn er meer dan tweeduizend, waarvan de meeste nooit iemand tegenkomt. Deze pagina neemt ze alle drie aan, want kiezen is niet aan de lezer.

HTML staat voor een korte, vaste lijst oude namen toe dat de puntkomma ontbreekt: `&amp`, `&lt` en `&copy` worden nog steeds herkend. Voor alle andere namen geldt dat niet, en dan blijft de tekst gewoon staan zoals hij is.

Daar zit een berucht randgeval: `&notit;` wordt gelezen als `¬it;`, want `&not` staat op de oude lijst. Een tekst waarin een ampersand zonder puntkomma voor een woord staat, kan dus onbedoeld iets anders worden — de reden dat een ampersand in gewone tekst altijd als `&` hoort te worden geschreven.

Levert het resultaat nog steeds `<` op, dan was de invoer twee keer ontsnapt: er stond `<`, en de eerste ronde maakte daar `<` van. Dat is geen fout in het decoderen maar de juiste uitkomst van één stap.

Twee keer decoderen tot het leesbaar is, is verleidelijk en verkeerd als het om code gaat. In een keten die maar één keer ontsnapt, sloopt die reparatie de tekst. Het is een aanwijzing om te zoeken waar er twee keer wordt ontsnapt, en dat is bijna altijd een applicatie plus een sjabloon die het allebei doen.

De gebruikelijke bron is een tekstveld waarvan de inhoud al ontsnapt in de database staat en daarna nog eens door de sjabloonmotor gaat. Het tweede geval is een export uit een CMS dat zijn eigen ontsnapping meelevert, en het derde is een RSS-feed waarin HTML in een veld is gestopt dat zelf HTML is.

De feed is het interessantste geval, want daar is het geen fout: de inhoud van een `description` in RSS is per definitie ontsnapte HTML, en de dubbele laag hoort erbij. Wie zo’n veld verwerkt, moet dus precies één keer decoderen en het resultaat als markup behandelen, niet als tekst.

De HTML-standaard kent ruim tweeduizend benoemde tekenverwijzingen, van `&` tot namen voor wiskundige symbolen die vrijwel nooit iemand gebruikt. Die lijst is bevroren: er komen er geen bij, ook niet voor nieuwe Unicode-tekens.

Voor alles wat er niet in staat — en dat is verreweg het meeste van Unicode, emoji inbegrepen — bestaan alleen de numerieke vormen. Dat is geen tekortkoming: een naam voor elk codepunt zou een tabel van honderdduizenden regels betekenen, terwijl het getal het codepunt al is.

Tekens boven `` — emoji, zeldzame schrifttekens, sommige wiskundige symbolen — hebben een codepunt dat niet in zestien bits past. `😀` is de lachende emoji, en JavaScript bewaart die intern als twee halve stukken, een surrogaatpaar.

Dat is waar zelfgebouwde decoders stuklopen: wie het getal naar één teken omzet met een functie die maar zestien bits aankan, krijgt onzin. Hier wordt het codepunt als geheel omgezet, zodat emoji en zeldzame tekens er als één teken uitkomen en niet als twee losse helften.

` ` is geen gewone spatie maar U+00A0, de harde spatie, die in UTF-8 de twee bytes `c2 a0` is. Op het scherm ziet hij eruit als een spatie en voor elke tekstvergelijking is hij een ander teken.

Daar komen de raadselachtige verschillen vandaan bij tekst die uit een tekstverwerker of van een webpagina is gekopieerd. Een zoekopdracht vindt niets, een sleutel komt niet overeen, een validatie faalt op een veld dat er leeg uitziet. Wie deze pagina gebruikt en een spatie ziet waar hij geen ` ` verwachtte, heeft de oorzaak te pakken.

Een naam die niet bestaat, een getal boven het hoogste codepunt of een verwijzing zonder afsluiting blijft hier staan zoals hij is. Dat is met opzet: verwijderen zou tekst weggooien, en gokken zou een teken opleveren dat er nooit stond.

Het is ook de nuttigste uitkomst bij het opsporen van een fout. Een `&` die is blijven staan, is het bewijs dat er een losse ampersand in de bron stond die niet als `&` was geschreven — en dat is een echt probleem in het document en niet in het decoderen ervan.

Wat hier uitkomt is de oorspronkelijke tekst, en die kan alles bevatten wat de schrijver erin heeft gezet, tags inbegrepen. Het decoderen maakt de tekst leesbaar; het maakt hem niet ongevaarlijk om ergens in te zetten.

Belandt de uitkomst weer op een pagina, dan hoort er opnieuw te worden ontsnapt, en moet het als markup worden gebruikt, dan hoort er een sanitizer overheen die tags en attributen tegen een lijst legt. De volgorde is: decoderen om te lezen, en per bestemming opnieuw beslissen wat ermee mag.

XML heeft er maar vijf ingebouwd: `<`, `>`, `&`, `"` en `'`. Alle andere namen, ` ` voorop, bestaan daar niet tenzij ze in een document type definition zijn verklaard — en een XML-parser die er een tegenkomt, stopt met een fout in plaats van hem over te slaan.

Dat is de reden dat een RSS-feed of een SVG-bestand kan struikelen over tekst die in HTML probleemloos werkt. Kom je dat tegen, dan is de oplossing de naam vervangen door zijn numerieke vorm: ` ` in plaats van ` ` werkt in allebei de werelden zonder verklaring vooraf.

De tekst die hier binnenkomt komt vaak uit een databaseveld, uit een supportsysteem of uit een export, en draagt dan namen, adressen en berichten van klanten. Omdat het decoderen op de pagina gebeurt, wordt daar niets van aan ons verstrekt.

Er is nog een tweede reden dat het lokaal blijft, en die is technisch: er wordt niets gerenderd, dus vreemde markup kan hier ook geen verzoek uitlokken dat de inhoud naar een derde stuurt. Dat is geen bijvangst maar de reden dat er met een tabel wordt gewerkt en niet met een parser.