Als je een voornaam of achternaam hebt waarin een accent in je naam zit, dan ben je het vast wel eens tegen gekomen, je vult op een site een formulier in, maar de bevestigingsmail toont je naam niet goed. Als als je René heet staat er Rene, zonder het accent. Of er staat een vierkant blokje. Of er staan 2 andere vreemde tekens. Welkom in de wereld van "encoding-problemen".
Deze problemen kom je niet alleen online op websites of in e-mails tegen, maar ook op andere plekken in het dagelijks leven. Zo heb ik de film "nobody" bij Pathe gezien. Of eigenlijk Pathé. Het papieren ticket wat ik krijg en via de kassa uitgeprint wordt heeft bovenin de tekst W E L K O M B I J P A T H E, dus zonder het accent op de e. Dan heb je de gegevens en helemaal onderaan staat Path_ wenst u een fijne voorstelling! Waarschijnlijk stond daar wel Pathé, maar kan de ticketprinter die karakterset niet afdrukken en krijg je een underscore.
Online kun je zaken op meerdere manieren tonen. Natuurlijk kun je de é gebruiken, maar de HTML-code é werkt ook. Als je dat echter 1-op-1 gaat exporteren naar een tekstbestand, dan heb je daar ook die é in staan terwijl je natuurlijk liever de é zelf hebt. Alle letters, cijfers en andere tekens hebben een code in de ASCII-tabel, zo heeft de é code 233, dus je kunt deze ook nog als é in je HTML plaatsen. Maar bij exporteren daarvan heb je hetzelfde probleem als de é Op Windows kun je die code vinden door de applicatie charmap te starten.
Ik ben nog even door mijn screenshots gebladerd. Zo kwam ik een betaling via iDeal (Rabobank) tegen waarbij ik een container-sticker kocht bij Afûk. Maar daar staat dus Begunstigde: ING Bank inzake Stichting Af?k.
Om iets van duidelijkheid te geven, even hoe ik hiermee in aanraking gekomen ben. We werkten "nog" met classic ASP. Dat zijn HTML-bestanden met daarin server-side VB-code (en dus extensie .asp). De standaard die gebruikt werd was ISO-8859-1. Dit is het Latijnse alfabet en bevat een beperkt aantal karakters (zie ook wikipedia: link). Inmiddels zijn bijna alle sites overgegaan op UTF-8 (zie ook wikipedia: link).
Één van de acties was om in de HTML de
<meta charset="UTF-8">
mee te geven. Op zich een goede zaak, omdat de browser dan niet hoeft te raden welke encoding gebruikt moet worden. Maar in IIS werd de HTML nog aangeleverd als ISO-8859-1, dat was dus de eerste reden dat café in je browser getoond werd als caf_. Door in de server-side code het volgende op te nemen dwongen we ook daar af dat de juiste encoding en codepage gebruikt werd. Met de encoding zeg je welke encoding gebruikt wordt (ISO-8859-1, UTF-8 of een ander type), vergelijk dat met dat je Nederlands, Duits of Engels gaat spreken. De codepage is het woordenboek dat je erbij gebruikt. Als je afspreekt om Duits te spreken, moet je ook het Duitse woordenboek gebruiken, je hebt dan niets aan een Frans woordenboek. Dat deden we met onderstaande statements:
response.charset = "UTF-8" response.codepage = 65001
Daarmee hadden we de meeste zaken al afgevangen. Maar toch kwamen we zo nu en dan vreemde tekens tegen in onze browser. Hoe dan?
Nou, pagina's werden niet altijd opnieuw opgebouwd, maar opgeslagen als cachebestand. Dat cachebestand werd ingelezen en doorgestuurd naar de browser.
Met een Scripting.FileSystemObject kon de functie .OpenTextFile aangeroepen worden, data weggeschreven worden en het tekstbestand opgeslagen worden. Alleen... het tekstbestand was dan een ANSI bestand (wat overeen komt met ISO-8859-1) en geen UTF-8 bestand...
Dat is het nadeel van "oude techniek", je kunt niet die functie aanroepen met een UTF-8 parameter of iets dergelijks. Je moet een beetje op een "vieze manier" werken, met een
Server.CreateObject("ADODB.Stream")
kun je wel de data wegschrijven, deze heeft namelijk de eigenschap .CharSet en die kun je op UTF-8 zetten.
Dus als je zelf tegen deze problemen aanloopt, zorg dan dat:
- cachebestanden met de juiste encoding opgeslagen worden
- dat de serverside-output van je data in de juiste encoding gedaan wordt
- dat je in je output zorgt dat de encoding meegegeven wordt (dus de meta charset="UTF-8" en in XML standaard de <?xml version='1.0' encoding='UTF-8'?>).
Gaat er dan nog iets fout, controleer dan je bestand(en). Soms worden er extra bytes aan het begin opgeslagen, de zogenaamde "BOM". Microsoft gebruikt dat wel eens om op die manier aan te geven dat een bestand UTF-8 is. Maar die tekens kunnen er soms voor zorgen dat je output alsnog foutief is, dus zorg dat je een "cleane" UTF-8 encoding gebruikt.
En gaat het dan nog steeds fout, kijk ook naar je database. Hoe sla je jouw data op? Is dat format wel juist?
Uiteindelijk is encoding niet moeilijk en is het eigenlijk een blamage dat het nog op veel plaatsen niet goed gaat, aan de andere kant, als je met legacy-systemen werkt en er onderling afhankelijkheden zijn (zoals we ook bepaalde interne HTTP-requests hadden die dan ook weer door de encoding geraakt werden) is het vaak een kwestie van consequent je aanpassingen doorvoeren en veel testen. Dus als je weer eens met een website bezig bent en formulieren en artikelen moet controleren, gebruik dan geen lorum ipsum, maar lörûm ipßúm om meteen je encoding te controleren ;)
Op deze pagina ga ik mijn encoding-zaken die ik tegenkom (en nog even uit mijn archief moet opzoeken) delen: link.