Hur fungerar det här med teckenkodning egentligen?
Publicerat 29 januari 2010 av Christian
Något som jag själv och väldigt många andra har svårt att förstå fullt ut är hur teckenkodning fungerar. Du vet det här med ASCII, UTF-8, ISO 8859-1 och så vidare… Vad är det egentligen? Och när man ser en text med ö istället för våra svenska tecken – vad är det som har hänt?
Våra kära datorer känner ju bara till ettor och nollor, inte bokstäver (eller tecken, som jag ska kalla dem i den här artikeln). Alltså måste vi ha en konvention, eller teckenkodning, för hur ettor och nollor ska kunna representera tecken. Tyvärr har vi flera!
Om en text är sparad enligt en teckenkodning och du försöker tolka den enligt en annan, finns det en risk att du inte kan läsa allt som det var tänkt. Ibland ser texter ut så här:
Gud hjälpe qvickt Zorns mö få aw byxor.
Denna text är sparad med UTF-8 och tolkad som ISO 8859-1. Eftersom tecknen a-z, mellanslag och punkt lagras precis likadant i de båda standarderna kan du läsa dem, men våra svenska tecken å-ö lagras på olika sätt.
Vad är då skillnaden mellan ISO 8859-1 (även kallad Latin-1) och UTF-8?
Latin-1 är en utökning av den gamla ASCII-standarden och består av 255 tecken. Den är tänkt att användas för västeuropeiska språk och saknar tecken från exempelvis de grekiska, arabiska och kyrilliska alfabeten.
UTF-8 består av samtliga tecken i Unicode-standarden, som i dagsläget är över 100 000 tecken! Unicode är tänkt att omfatta alla tecken och skriftspråk som någonsin har funnits. Du ska alltså kunna skriva på vilket språk som helst och aldrig behöva byta teckenkodning!
Tecken som lagras med Latin-1 tar alltid upp exakt en byte. (En byte är ju 8 bitar, som ger 256 kombinationer – alltså 255 tecken och null.)
Men tecken som lagras med UTF-8 varierar mellan 1-4 bytes! Tecken som återfinns i ASCII-standarden lagras precis som där, men för andra tecken används fler bytes. (Exempelvis lagras å-ö med 2 bytes, vilket är orsaken till att de visas som två tecken med Latin-1 ovan.) Det ger en praktisk bakåtkompatibilitet i många fall, men förvirring i andra.
Ju mer vi gräver ned oss i detta, desto knepigare blir det. Jag tror inte att jag ska gå djupare här, så om du vill lära dig mer, börja med Joel Spolskys artikel The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
Mitt tips är att du använder UTF-8. Det är den absolut vanligaste teckenkodningen på webben enligt en undersökning av Google. (De näst vanligaste teckenkodningarna är ASCII och Latin-1/Windows-1252.)
Läs Unicode for the working PHP programmer om du vill lära dig mer om hur du använder UTF-8 med PHP via Multibyte String Functions.




Ett återkommande problem detta. Bra artikel och förklarat.
När det gäller filer brukar det vara ganska enkelt att lösa. Det är när det att kopplingar till andra datakällor det kan börja bli problem, till exempel databaser eller ännu värre, olika APIer.
Men som du säger i artikeln, använd alltid UTF-8. Brukar kunna undvika många problem.
Det är fyra saker som jag tycker du missat:
1. Det finns program (bl.a. iconv i Linux) som man kan använda för att konvertera mellan olika teckenkodningar.
2. I regel se ALLTID(!!!) till att välja ut EN teckenkodning till dina programmeringsprojekt och dylikt. Det är ett helvete att arbeta i projekt där man är osäker på vilken kodning man ska ha i vilken fil, och slutar alltid upp med att man har minst två olika kodningar i en och samma fil – vilket leder till att program som iconv inte kan konvertera/korrigera kodningar automatiskt utan att man måste göra det manuellt. Det är ett riktigt skitgöra. Jag talar från erfarenhet.
3. Om man är flera personer som arbetar i samma filer tillsammans så är det ytterst viktigt att man alla är överens om vilken kodning man ska ha. MAC/Linux/Windows, och inte minst olika utvecklingsverktyg, kan resultera i spaghetti.
4. Trots att iconv finns så är det ett mähä att konvertera mellan olika textkodningar. Det räcker oftast med att ett enda tecken inte är rätt i en 50 MB stor teckenfil (t.ex. en MySQL-dump) så funkar inte många konverteringsverktyg. Det är som att leta i en höstack. Även här talar jag från erfarenhet. Välj därför noggrant vilken kodning du vill ha FRÅN FÖRSTA BÖRJAN. UTF-8 är precis som Christian skriver rekommenderat.
Det var mina erfarenheter och tankar.
Tack Jens, du understryker hur besvärligt det kan vara med teckenkodningar om man inte är noggrann.