New Jersey, 1992.
Unix-skaparen Ken Thompson träffade Bell Labs-kollegan Rob Pike på en restaurang och diskuterade problematiken kring teckenkodning, skräptecken, udda specialtecken, internationalisering och diskplats. Innan notan var betald hade idéerna bakom UTF-8 fötts.
25 år senare kablade de svenska medierna ut följande nyhet:
“Skatteverkets utskick av deklarationer stoppades under onsdagskvällen.
Anledningen är ett tekniskt fel som gör att vissa tecken ser konstiga ut.”
I Skatteverkets fall var det å, ä och ö som ställde till det. Den svenska myndigheten är dock långt ifrån ensam. Microsoft hade till exempel problem med skräptecken i Windows XP och såväl användare som skapare av programspråket PHP stoppade mer eller mindre huvudet i sanden och ignorerade problematiken ända fram till dess att version 7 lanserades för ett par år sedan.
Det här väcker en del oroväckande frågeställningar. Lågt räknat har de stora massorna haft möjlighet att skicka blixtsnabba digitala meddelanden kors och tvärs över världen i ett kvarts sekel. Lika länge har vi haft förvånade användare som fått mail innehållandes texter som “Betalningsbekr�ftelse f�r kursen”.
Lyckligtvis finns det en universallösning och det är dessutom inte ens komplicerat: Du måste alltid, alltid, alltid ange teckenkod.
I princip i alla programspråk kan detta dessutom göras väldigt lätt. I exempelvis HTML5 görs det i metataggen:
<meta charset=”UTF-8″>
Om du är utvecklare och har som enda mål att klara dig på 2000-talet utan att drabbas av tidningsartiklar eller spöstraff från nitiska produktägare kan du sluta läsa nu.
Vi övriga vrider tillbaka klockan till åren före 1992 och gräver vidare i vad som var grunden till Pikes och Thompsons diskussioner.
Det var en gång…
På 60-talet var datorspråket engelska, alla tecken som behövdes fanns representerade i ASCII-tabellen och allt var frid och fröjd. Klassisk 7-bitars ASCII hade plats för 128 tecken. Denna plats vigdes åt de “engelska” tecknen och dessa tecken representerades av siffrorna 32-127. Exempelvis var ”blank” 32, 0 var 48, A var 65 och z var 122. Siffrorna 0-31 användas för att representera olika styrtecken som TAB, “radbrytning” och ESC.
1964 hände dock något, IBM släppte sin första 8-bitars dator, IBM System/360, vilket gjorde att det fanns en bit kvar, utöver den traditionella 7-bitars ASCII-tabellen. Denna extra bit gav möjlighet att lagra ytterligare tecken med representationen 128-255. Världen över började det då också poppa upp utökningar för att ge stöd åt det egna språkets speciella bokstäver. Det som vi uppe i norden ansåg vara en utmärkt representation för Å blev i Grekland bokstaven Ἠ. Asiaterna å sin sida byggde ett eget system som kallades DBCS (”Double Byte Character Set”) för att få plats med alla sina tecken. Problematiken med teckenkodning var född.
Efter ett tag kom man i alla fall överens, via ANSI-standarden, att 0-127 skulle vara lika världen över men från 128 och uppåt var det helt olika tecken beroende på var man befann sig. Vad 128-255 representerade kom att kallas OEM-kod. Original IBM PC teckenkodningen blev OEM 437 medan exempelvis våra grannar i Norge och Danmark skapade OEM 865 eftersom de saknade Ø i OEM 437.
Unicode var räddningen, eller?
I början av 80-talet gjordes ett försök till en universell lösning på språkförbistringen med Unicode. Idén med Unicode var att varje tänkbart tecken skulle få sin egen representation. Några år senare grundades “Unicode Consortium” som bland annat ansvarar för vilka tecken som ska ingå och hur de ska representeras. För närvarande är Unicode 9 den aktuella versionen och den innehåller 128 237 olika tecken.
Det är lätt att tro att detta skulle vara det lyckliga slutet på historien men icke. Varje tecken i Unicode representeras nämligen av en ”code point” på formen ”U+” plus ett hexadecimalt nummer. Exempelvis bokstaven A representeras som U+0041 och ni som kan er hexadecimala konvertering ser att hexadecimalt 41 motsvarar decimalt 65. A har alltså samma värde som i den gamla ASCII-tabellen. Detta gäller samtliga bokstäver från den gamla 7-bitars ASCII-tabellen (A-Z, a-z). Om vi bortser från den inledande “detta är unicode”-identifieraren (U+) så kan en vanlig engelsk textsträng som ”My name is Luca” därmed representeras på följande sätt med den ursprungliga Unicode-kodningen (UCS-2):
004D 0079 0020 006E 0061 006D 0065 0020 0069 0073 0020 004C 0075 0063 0061
Fiffiga (engelskspråkiga) programmerare tyckte dock att det där var en massa onödiga nollor, här fanns det diskplats att spara. Nollorna plockades bort och återigen var vi tillbaka i samma problem som tidigare. Så länge texten höll sig till det engelska alfabetet var allt frid och fröjd men så fort specialtecken blev inblandade fungerade det inte längre.
Nu är vi tillbaka där vi började, på en restaurang i New Jersey i september 1992, där Pike och Thompson slog ihop sina kloka huvuden och skapade UTF-8. Huvudpoängen med UTF-8 är att den sparar 0-127 i en byte medan övriga tecken sparas i två eller flera byte. Därmed sparas diskplats samtidigt som det även finns stöd för mer udda tecken. Ytterligare en fördel är att vanliga engelska tecken därmed lagras på precis samma sätt i UTF-8 som i det gamla ASCII-systemet. ”My name is Luca” på UTF-8 blir alltså följande:
4D 79 20 6E 61 6D 65 20 69 73 20 4C 75 63 61
Under åren har det sedan växt fram en rad olika sätt att lagra Unicode där UTF-8 fortfarande är det absolut vanligaste så har du möjlighet att välja så rekommenderas absolut denna teckenkodning. Andra exempel är UTF-16, UCS-4, UTF-1 och UTF-EBCDIC som alla har sina egna små egenskaper. Lägg därtill att det dessutom finns en rad gamla teckenkodningar som ISO-8859-1 som svävar runt därute i cyberrymden. Allt detta innebär att om det inte finns någon teckenkod angiven till en text och det kommer ett tecken som inte ryms inom det ursprungliga 0-127 ASCII-spannet så är det komplett omöjligt att veta vilket tecken som avses. Istället skrivs det i vissa fall någon form av Mojibake (fritt översatt, skräptecken), i andra fall frågetecken eller fyrkanter.
Därför avslutar jag återigen med denna teckenkodningens magiska silverkula:
Du måste alltid, alltid, alltid ange teckenkod.
