‘Karaktercodering is nog een ondergeschoven kindje’ (UTF-8)

Het formaat UTF-8. De meeste lezers zullen het niet kennen. Althans, niet bewust. Toch speelt het formaat wel degelijk een rol bij de manier waarop pagina’s worden weergegeven. Anne van Kesteren dook wat dieper in de materie en komt onder meer tot de conclusie dat karaktercodering, want daar gaat het hier om, niet de aandacht krijg die het verdient en best gezien mag worden als een ondergeschiven kindje op het web.

Door Anne van Kesteren

Karaktercodering is op dit moment nogal een ondergeschoven kindje op het web. Naarmate applicaties en websites echter steeds meer internationaal gericht worden en XML ook een prominentere factor gaat spelen wordt een Unicode-formaat belangrijker. Een groot voordeel van het formaat UTF-8 is dat de eerste 127 (27-1) bytes overeenkomen met US-ASCII, waardoor het voor de meeste westerse documenten niet moeilijk is om te switchen. Uiteraard zijn er een aantal karakters die nog wel omgezet moeten worden, zoals ë en ï die niet onder US-ASCII vallen. De karakters binnen UTF-8 variëren van lengte in bytes. Zo zijn de eerste 127 karakters één byte en loopt het daarna op tot vier bytes per karakter en kan dit daarna nog verder uitgebreid worden mochten er meer karakter sets toegevoegd worden.

Mocht je dus je huidige ISO-8859-1 of ISO-8859-15 om willen zetten in UTF-8 dan is het veranderen van de HTTP header (of META element equivalent) waarschijnlijk niet genoeg. Je zult daadwerkelijk het document opnieuw moeten coderen als er karakters in voorkomen die buiten US-ASCII vallen (in Nederland zijn dat ë en ï zoals eerder genoemd, maar ook het € (euroteken) uit ISO-8859-15). Het opnieuw coderen is niet echt heel moeilijk. Als je een editor hebt met UTF-8 ondersteuning kun je meestal gemakkelijk ergens kiezen om het bestand op te slaan als UTF-8. Met Crimson Editor kies je “Document > Encoding Format > UTF-8 Encoding (w/o BOM)” en in UltraEdit-32 zitten er diverse mogelijkheden onder “File > Conversions”. Wil je in UltraEdit de BOM uitschakelen dan zul je dat via “Advanced > Configuration” moeten doen.

Byte Order Mark

O, had ik nog niet uitgelegd wat BOM is? BOM staat voor Byte Order Mark en het betreft drie bytes aan het begin van het document welke aangeven wat de karakter codering van het document is. Aangezien je dat echter kunt aangeven via HTTP is het overbodig om deze er in te laten staan. Mocht je PHP gebruiken dan moet je de BOM zelfs weglaten vanwege een bug in PHP (normaal mag je in PHP niks voor de “PHP-start-tag”, <?php, hebben staan, maar voor de BOM zou daar een uitzondering voor gemaakt moeten worden. Dit is echter niet het geval en daarom moet je de BOM weglaten als je PHP gebruikt).

Er zijn verschillende manieren om aan een browser door te geven welk coderingsformaat je gebruikt. Technisch gezien zou je dit het beste via HTTP kunnen regelen door de charset parameter van de Content-Type header de waarde UTF-8 te geven. Je zou één van de volgende opties aan je .htaccess kunnen toevoegen:

De opties verschillen uiteraard van elkaar. De eerste optie zorgt ervoor dat elke pagina met het coderingsformaat UTF-8 wordt verzonden (dus de charset parameter staat standaard op UTF-8), de tweede opties zorgt hier alleen voor bij .html documenten. Mocht je gebruik van maken van een server side scripttaal, zoals PHP zou je het volgende stukje code kunnen gebruiken: 

header("Content-Type:text/html;charset=utf-8");

Meer informatie over de header functie kun je vinden op php.net. Indien je weinig controle hebt over de server of de serverinstellingen zou je de HTML equivalent van de HTTP header kunnen gebruiken. Dit is verre van ideaal en werkt niet gegarandeerd, maar het is een mogelijke oplossing: 

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

(Dit element hoort uiteraard thuis binnen het HEAD element). Een argument voor het gebruik van een META element is dat als de gebruiker het document opslaat hij het hoogstwaarschijnlijk ook lokaal prima kan bekijken. Dit zou echter niet een zorg van de webmaster moeten zijn, maar van de browser. Daarnaast zorgt het element er wel voor dat bijvoorbeeld Mozilla opnieuw begint met parsen van het document nadat de browser het element is tegengekomen om het gehele document te parsen met die codering. Verre van ideaal dus.

Minder problemen

Naast het voordeel van betere internationalisatie en het kiezen voor een geschikt coderingsformaat voor XML (dus ook voor XHTML) levert UTF-8 minder problemen op met het invoeren van informatie. Zowel door de gebruiker als ook door de eigenaar van de site. Vaak worden deze problemen veroorzaakt omdat er bijvoorbeeld in een CMS een tekst uit Word wordt geplakt welke net iets andere karakters gebruikt. Of iemand die Windows gebruikt en een reactie achterlaat op een weblog. Als de site als coderingsformaat ISO-8859-1 of vergelijkbaar gebruikt wordt er meestal WINDOWS-1252 verzonden. Dit doen zowel Internet Explorer als Firefox en mogelijk Opera ook. Aangezien ISO-8859-1 en WINDOWS-1252 27 vervelende verschillen bevatten kan het zijn dat je pagina er daarna niet meer zo best uitziet. Om terug te komen op dat voordeel van UTF-8, dat coderingsformaat kent het gehele probleem niet.

Zolang elke pagina op de site aangeeft dat het coderingsformaat UTF-8 is door middel van HTTP of iets dergelijks kunnen er geen problemen ontstaan van deze aard. De karakters zullen altijd UTF-8 gecodeerd zijn. Dit is uiteraard alleen zo als elke pagina op deze wijze gecodeerd is. Dus niet alleen de pagina’s waar de bezoeker kan komen, maar ook de pagina’s van het beheersysteem, et cetera.

Mocht je pagina vooral oosterse teksten bevatten dan kan het de moeite waard zijn om te kijken naar UTF-16, welke elk karakter met twee bytes opslaat en geen variabele lengte kent. UTF-8 slaat deze karakters meestal op met 3 bytes. Het verschil is klein en je moet ook meenemen dat met UTF-16 element namen in HTML en XML ook twee bytes zullen zijn waar deze in UTF-8 maar één byte groot zijn.

Dit artikel verscheen in het januari nummer 2005 van OpenMagazine. Behalve enkele wijzigingen aan de markup is er verder niks gewijzigd. Vorige maand schreef dezelfde auteur Structurering: Het draait om semantiek.