Betalningsbekr�ftelse f�r kursen

Häromdagen fick jag ett mail från dotterns dansskola med ämnesraden, ”Betalningsbekr�ftelse f�r kursen: L�r 10:15”.
Bevisligen finns det alltså fortfarande utvecklare som rycker på axlarna varje gång någon nämner teckenkodning. De går runt i sin lilla bubbla och tror att det finns något som heter ”vanlig text” och så länge de håller sig till sin ”vanliga text” så är det lugnt. Det må vara sant, om den ”vanliga texten” bara ska användas på deras egen dator och läsas på deras eget språk. Världen ser dock som bekant inte ut så längre.
Håller du just på att tröttna på denna bloggpost så håll ut lite till för här kommer språkförbistringens ”silverkula”, du måste alltid ange teckenkod. I html görs det med charset-parametern i meta-taggen:

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

I Java kan du exempelvis sätta teckenkod när du startar JVM:n med parametern

-Dfile.encoding=utf-8

eller när du läser från en fil

Reader reader = new InputStreamReader(is, "UTF-8");

För er som vill ha lite bakgrund till hur detta med teckenkodning hänger ihop kommer här en liten historielektion.
I begynnelsen var datorspråket engelska, alla tecken som behövdes fanns representerade i ASCII-tabellen och allt var frid och fröjd. Om det nu mot förmodan finns någon gammal IBM-räv som läser detta så antar jag att det höjs röster mot att det minsann fanns saker som BCD, BCDIC och EBCDIC innan ASCII tog över. Det är förvisso sant men för oss vanliga så var det före begynnelsen.

Hur som helst, klassisk 7-bitars ASCII hade plats för alla engelska tecken 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, ESC och liknande.

Den dominerande IBM-datorn på denna tid använde sig dock av 8 bitar vilket gjorde att det fanns en bit kvar, utöver den traditionella ASCII-tabellen. Denna extra bit gav möjlighet att lagra ytterligare tecken med representationen 128-255. Runt om i världen började det 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 kalldes DBCS (”Double Byte Character Set”) för att få plats med alla sina tecken. Språkproblematiken var född.

Efter ett tag kom man i alla fall överens, via ANSI-standarden, att 0-127 skulle vara lika över hela världen 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.

Ett försök att lösa språkförbistringen gjordes med Unicode. Idén med Unicode var att varje tänkbart tecken skulle få sin egen representation, något som bestäms av ”Unicode Consortium”. För närvarande är Unicode 6.0 den aktuella versionen och den innehåller 862 624 olika tecken. Det är lätt att tro att detta skulle vara det lyckliga slutet på historien men icke. Varje tecken 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. Detsamma gäller övriga bokstäver från den gamla 7-bitars ASCII-tabellen (A-Z, a-z). En vanlig engelsk textsträng som ”My name is Luca” 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. Därför skapades UTF-8 som sparar tecken 0-127 i en byte medan övriga tecken
sparas i två eller flera byte. Det gav dessutom fördelen att vanliga engelska tecken 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 är det vanligaste men det finns även exempelvis UTF-16 (som är närbesläktad till det ursprungliga UCS-2 kodningen), UCS-4, UTF-1 och UTF-EBCDIC som alla har sina egna små egenskaper. Lägg därtill att det fortfarande 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” (skräptecken), i andra fall frågetecken eller fyrkanter.