Att välja & att använda en teckenkodning

Fråga

Vilken teckenkodning bör jag använda för mitt innehåll, och hur tillämpar jag den på mitt innehåll?

Innehåll består av en sekvens av tecken. Tecken står för bokstäver, interpunktion, etc. Men innehåll lagras på en dator som en sekvens av bytes, vilka är numeriska värden. Ibland kan fler än en byte behövas för att representera ett enskilt tecken. I likhet med koder som används av spioner, så kommer sättet att konvertera en sekvens av bytes till tecken att bero på vilken nyckel som använts för att koda texten. I detta sammanhang kallas en sådan nyckel för en teckenkodning.

Denna artikel ger enkla råd om vilken teckenkodning du bör använda för ditt innehåll, och hur du applicerar den, dvs hur du faktiskt skapar ett dokument i den kodningen.

Om du behöver veta mer om vad tecken och teckenkodningar är, så titta på artikeln Character encodings for beginners.

Snabbt svar

Välj UTF-8 för allt innehåll, och konvertera helst innehåll som representerats i gamla kodningar till UTF-8.

Om du inte har möjlighet att använda en Unicode-kodning, kontrollera att det finns gott webbläsarstöd för den kodning av sidan som du har valt, och att kodningen inte finns i listan över kodningar som bör undvikas enligt färska specifikationer.

Undersök om ditt val kommer att påverkas av HTTP-inställningarna för webbservern.

In addition to declaring the encoding of the document inside the document and/or on the server, you need to save the text in that encoding to apply it to your content.

Utvecklare måste också säkerställa att olika delar av systemet kan kommunicera med varandra.

Detaljer

Att använda en kodning på ditt innehåll

Innehållsförfattare bör deklarera sina webbsidors teckenkodning genom att använda en av de metoder som beskrivs i Declaring character encodings in HTML.

Det är dock viktigt att förstå att deklaration av kodningen inne i ett dokument eller på en server inte medför att dokumentets bytes ändras; du måste spara texten i den kodningen för att få kodningen att ta effekt. (Deklarationen är bara till för att hjälpa webbläsaren att tolka den sekvens av bytes som utgör den lagrade texten.)

Om möjligt bör du ange att UTF-8 är normalkodning för nya dokument i ditt redigeringsverktyg. Bilden nedan visar hur du kan ange detta som del i inställningarna (eng: preferences) för ett redigeringsverktyg som Dreamweaver.

DreamWeavers nya dokumentpreferenser ger möjlighet att ange en normalkodning.

Du kan även behöva kontrollera att din server levererar dokument med korrekta HTTP-deklarationer, eftersom dessa annars kommer att ersätta det som angivits i dokumentet (se nedan).

Utvecklare måste också säkerställa att olika delar av systemet kan kommunicera med varandra. Webbsidor måste kunna kommunicera sömlöst med skripts, databaser etc som finns på servern. Dessa fungerar naturligtvis också bäst med UTF-8. Utvecklare kan hitta en detaljerad beskrivning av vad som behöver göras i artikeln Migrating to Unicode.

Varför använda UTF-8?

En HTML-sida kan bara ha en kodning. Du kan inte koda olika delar av dokumentet i olika kodningar.

En kodning baserad på Unicode, t.ex. UTF-8, kan stödja många språk och kan användas för sidor och formulär i godtycklig blandning av dessa språk. Genom att använda en sådan kodning behöver man inte ha speciell hantering på servern som, för alla levererade sidor eller all formulärinmatning, försöker avgöra vilken teckenkodning detta innehåll har. Detta ger en avsevärd minskning av komplexiteten i att hantera en flerspråkig webbplats eller tillämpning.

Med en Unicode-kodning kan man även ha text i många flera olika språk på samma webbsida än är möjligt med andra val för teckenkodning.

Numera finns det inte mycket som försvårar användning av Unicode. I januari 2012 rapporterade Google att mer än 60% av webben i ett undersökt stort urval (många miljarder sidor) var representerat i UTF-8. Till det bör man lägga den mängd sidor som är kodade i ren ASCII (eftersom ASCII är en delmängd av UTF-8), och då når man upp till närmare 80%.

Det finns tre olika teckenkodningar i Unicode; UTF-8, UTF-16 och UTF-32. Av dessa tre bör endast UTF-8 användas för webbinnehåll. Specifikationen för HTML5 säger att ”Innehållsförfattare uppmanas att använda UTF-8. Konformitetsgranskare kan avråda författare från att använda gamla kodningar. Författarverktyg bör ha UTF-8 som normalvärde för nyskapat innehåll”.

Kom ihåg att alla ASCII-tecken i UTF-8 använder exakt samma numeriska värden (bytes) som traditionell ASCII-kodning, ett faktum som ofta underlättar interoperabilitet och bakåtkompatibilitet.

Att ta hänsyn till HTTP-huvuden

Om en teckenkodning deklareras i HTTP-huvudet, så kommer detta värde att gälla, oavsett vad som anges i webbsidan. Om HTTP-huvudet deklarerar en kodning som inte är likvärdig med den du valt för ditt innehåll, så kommer detta att skapa problem, såvida du inte ser till att ändra inställningarna för servern.

Du kanske inte har möjlighet att själv påverka deklarationerna som finns i HTTP-huvudet, och då måste du begära hjälp av de som ansvarar för servern. Men det kan finnas sätt att få saker och ting att fungera bra, om du åtminstone har viss tillgång till serverns inställningsfiler, eller om du genererar sidor med hjälp av något skriptspråk. Se t.ex. i Setting the HTTP charset parameter, där det finns mer information om hur man kan ändra information om kodning, antingen lokalt för en viss uppsättning filer på servern, eller för innehåll genererat med skriptspråk.

Men innan du gör det så ska du undersöka om HTTP-huvudet faktiskt deklarerar teckenkodningen. Du kan använda W3C Internationalization Checker för att få information om någon teckenkodning angivits i HTTP-huvudet, och i så fall vilken teckenkodning. Du kan även titta i artikeln Checking HTTP Headers, som pekar ut andra verktyg vilka kan användas för att undersöka vilken information servern levererar om kodning.

Ytterligare information

Informationen i denna sektion handlar om sådant du vanligtvis inte behöver behöver ha kännedom om, men som inkluderas här för fullständighetens skull.

Men om jag inte kan använda UTF-8?

Om du av något skäl inte kan använda UTF-8 som teckenkodning, så måste du välja något i en begränsad lista över kodningsnamn, för att säkerställa maximal interoperabilitet, att ditt innehåll kommer att vara läsbart i framtiden, och att minska säkerhetsrisker.

Fram till relativt nyligen var IANA-registret det ställe där man skulle finna kodningsnamn. I IANA-registret finns många förekomster av multipla namn för en och samma kodning. När en kodning har flera namn, så bör du välja det namn som markerats som ”preferred”.

Den nya specifikationen Encoding ger nu en lista av kodningsnamn som testats i existerande webbläsare. Den listan finns i tabellen i sektionen benämnd Encodings. Det är säkrast att använda namn som finns i den vänstra kolumnen i den tabellen.

Notera dock att bara för att ett namn förekommer i dessa två källor så medför inte detta automatiskt att det är fritt fram att använda den kodningen. Nästa sektion tar upp kodningar du bör undvika.

Undvik dessa kodningar

HTML5-specifikationen anger ett antal kodningar som du inte bör använda.

Dokument ska inte använda JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), kodningar byggda på ISO-2022, eller kodningar byggda på EBCDIC. Anledningen är att alla dessa tillåter att numeriska värden som förekommer i ASCII-kodningen här fås att representera tecken som inte finns i ASCII, och detta medför säkerhetsrisker.

Dokument skall inte använda kodningar enligt CESU-8, UTF-7, BOCU-1, eller SCSU, eftersom dessa aldrig varit avsedda för webbinnehåll, och HTML5-specifikationen förbjuder webbläsare att hantera dem.

Specifikationen avråder kraftigt från användning av UTF-16, och användning av UTF-32 ”avråds bestämt”.

Man bör även undvika vissa andra av de teckenkodningar som listas i specifikationen Encoding , Bland dessa finns t.ex. kodningarna Big5 och EUC-JP, vilka har interoperabilitetsproblem. ISO-8859-8 (en kodning för hebreiska avsedd för visuellt ordnad text) bör också undvikas, och använd istället en kodning som fungerar med logiskt ordnad text (dvs UTF-8, eller, som andrahandsval, ISO-8859-8-i).

Den s.k. replacement-kodningen, vilken nämns i Encoding-specifikationen, är egentligen inte en kodning; det är en reserv som avbildar varje oktett till Unicode-kodpunkten U+FFFD REPLACEMENT CHARACTER. Av uppenbara skäl är det inte meningsfullt att överföra data i denna kodning.

Kodningen x-user-defined är en en-bytes-kodning, vars nedre halva är ASCII, och vars övre halva avbildas in i Unicode Private Use Area (PUA). På samma sätt som för PUA i allmänhet, så bör man undvika denna kodning på det öppna Internet, eftersom den försvårar interoperabilitet och långsiktig användning.