Tekencodering en UTF-8: waarom ë in je webshop als ë verschijnt

Waarom accenten in producttitels kapotgaan

Een computer bewaart tekst als bytes. Welke byte bij welk teken hoort, staat in een tekencodering. In leveranciersbestanden kom je er twee tegen: UTF-8, de standaard op het web, en Windows-1252, de standaard van oudere Windows-software en van veel exports uit groothandelssystemen. Voor letters zonder accent, cijfers en leestekens zijn ze gelijk. Voor alles daarbuiten niet.

Een leverancier levert deze titel in UTF-8:

Koppelstuk ½" geëloxeerd messing, Ø 22 mm, crème, 3 stuks

Dat zijn 57 tekens, maar 61 bytes, want ½, ë, Ø en è zijn in UTF-8 elk twee bytes. Leest de koppeling het bestand als Windows-1252, dan wordt elke byte een teken:

Koppelstuk ½" geëloxeerd messing, Ø 22 mm, crème, 3 stuks

De titel is nu 61 tekens lang. Behalve dat hij er kapot uitziet, past hij niet meer in een veld van 60 tekens, zoals het veld Description van een artikel in Exact Online. Wie op 60 tekens afkapt, verkoopt "3 stuk". Een titel met tien van zulke letters groeit met tien tekens.

Wat er in de bytes gebeurt

De tabel laat per teken zien welke bytes het heeft in beide coderingen, en wat er op het scherm komt als UTF-8 als Windows-1252 wordt gelezen.

Het patroon is te herkennen: een Ã of Â gevolgd door een tweede teken, of een reeks die met â€ begint. Die tekens komen in Nederlandse productdata bijna nooit voor, en dat maakt ze bruikbaar als controle.

De omgekeerde fout ziet er anders uit. Een Windows-1252-bestand gelezen als UTF-8 bevat bytes die in UTF-8 niet geldig zijn. E9, de é, mag in UTF-8 alleen het begin van een reeks van drie bytes zijn. De lezer vervangt hem door het vervangteken, een vraagteken in een ruit. Daarmee is de é weg: in de tekst staat niet meer welke letter er stond.

Vier fouten die je in de praktijk ziet

Twee keer verkeerd gelezen

Een koppeling leest UTF-8 als Windows-1252 en schrijft het resultaat weer als UTF-8 weg. Het volgende systeem doet hetzelfde. Uit ë wordt eerst ë en daarna ë. Elke ronde maakt het langer: van 1 teken naar 2 en naar 4. Terugdraaien kan nog, maar dan net zo vaak als het fout ging, en alleen als je weet hoe vaak dat was.

Een letter die niet terug te halen is

In Windows-1252 hebben vijf bytes geen teken: 81, 8D, 8F, 90 en 9D. De Á is in UTF-8 C3 81. Leest een programma dat als Windows-1252, dan kan het 81 niet omzetten en vervangt het hem of laat het hem weg. Die tekst is daarna niet meer automatisch te herstellen.

De BOM voor de eerste kolom

Een UTF-8-bestand kan beginnen met drie bytes EF BB BF, de byte order mark of BOM. Een lezer die op een BOM rekent, slaat ze over. Een lezer die Windows-1252 verwacht, plakt ze als  voor de eerste kolomnaam. Een UTF-8-lezer die de BOM niet verwijdert, zet er een onzichtbaar teken voor, met hetzelfde gevolg. De kolom artikelnummer bestaat dan niet, want hij heet artikelnummer. De foutmelding gaat over een ontbrekende kolom en noemt de codering niet.

Het euroteken in ISO-8859-1

ISO-8859-1, ook latin-1 genoemd, lijkt op Windows-1252, maar de bytes 80 tot 9F zijn er stuurcodes in plaats van tekens. In Windows-1252 is 80 het euroteken. Een bestand dat als ISO-8859-1 wordt aangekondigd en eigenlijk Windows-1252 is, verliest daardoor het euroteken en de apostrof uit Word. Dezelfde keuze speelt bij OCI: het inkoopsysteem geeft de tekenset op waarin de webshop het formulier moet sturen, zie wat is een OCI-koppeling.

HTML of platte tekst: welke tags blijven over

De tweede bron van kapotte tekst is opmaak. Een PIM of een webshop bewaart een productomschrijving vaak als HTML. Een ERP of boekhouding bewaart platte tekst, met een vaste lengte. De velden verschillen per systeem; deze zijn op 3 oktober 2026 nagelezen in de documentatie van de leverancier.

Shopify legt beide velden vast in de GraphQL Admin API. De lengtes van Exact Online staan in de veldbeschrijving van Items, die van AFAS in de OpenAPI-specificatie van de UpdateConnector.

Neem deze omschrijving uit een PIM:

<p><strong>Messing</strong> koppelstuk, ge&euml;loxeerd</p>

Dat zijn 59 tekens, waarvan 30 tekst. Gaat hij zonder bewerking naar ExtraDescription in Exact Online, dan staan de tags letterlijk in de omschrijving van het artikel, en ë ook. Gaat hij naar het veld Description van 60 tekens, dan past hij net, maar alleen omdat hij kort is. Een omschrijving met een opsomming van vijf punten past nooit.

Per doelveld beslist de koppeling daarom drie dingen:

• Welke tags blijven. Voor descriptionHtml in Shopify bijvoorbeeld <p>, <strong>, <ul> en <li>; tags als <script>, <style> en inline style-attributen uit een gekopieerd Word-document gaan eruit.
• Wat er van een lijst wordt in platte tekst. Een <li> wordt een regel met een streepje ervoor, een <br> een regeleinde.
• Hoe entiteiten worden omgezet. ë wordt ë, & wordt &,   wordt een gewone spatie. Dat gebeurt voordat de lengte wordt gemeten, zodat 60 tekens ook echt 60 tekens zijn.

De andere richting heeft een eigen fout. Platte tekst met regeleinden die als HTML wordt getoond, verliest de regeleinden: in HTML is een regeleinde een spatie. Vijf regels van de leverancier staan dan als één lange regel op de productpagina.

Hoe een koppeling de codering vaststelt

Een bestand zegt meestal niet in welke codering het staat. Er zijn drie plekken waar het soms wel staat: een XML-bestand mag het in de eerste regel noemen (<?xml version="1.0" encoding="ISO-8859-1"?>), een HTTP-antwoord kan het in de kop Content-Type noemen (text/csv; charset=windows-1252), en een BOM wijst op UTF-8. Een CSV-bestand van een leverancier heeft geen van drie.

De werkwijze die standhoudt:

1. Per bron vastleggen. Bij het inrichten wordt de codering van elke leverancier bepaald en vastgelegd. Daarna wordt niet meer geraden.
2. Streng lezen. Een bestand dat als UTF-8 is vastgelegd, wordt streng als UTF-8 gelezen. Een ongeldige byte stopt de run in plaats van stil een vraagteken in een ruit op te leveren. Dat vangt het moment dat de leverancier van systeem wisselt.
3. Elke run controleren. Na het lezen zoekt de koppeling in de titels naar Ã, Â en â€. Bij 8.000 artikelen kijkt niemand dat met het oog na; een regel die het patroon bevat gaat naar de controlelijst.
4. Intern alleen UTF-8. Wat binnenkomt wordt één keer omgezet. Daarna is alles UTF-8, tot aan het systeem dat iets anders vraagt.

Wat betekent dit voor je koppeling?

Voor elke bron leggen we de codering vast, en voor elk doelveld de lengte en of het HTML accepteert. Bestanden worden streng gelezen, elke run wordt gecontroleerd op de bekende patronen, en een titel die te lang wordt of een ongeldige byte bevat, komt op de controlelijst in plaats van afgekapt in je webshop. In de dry run zie je per artikel de tekst voor en na de omzetting.

Tekencodering is een van de controles in de productdatastroom, naast EAN-codes, afbeeldingen en vertaaltabellen. Het overzicht staat op productdata koppelen. Voor leveranciersbestanden in het algemeen zie CSV- en Excel-bestanden van leveranciers, voor een PIM een PIM koppelen aan je webshop. Stuur een voorbeeldbestand van je leverancier mee, dan zie je wat er in de bytes staat.