Använd accesskey 'n' för att hoppa till de interna navigationslänkarna i dokumentet. Hoppa till början av innehållet.

Detta dokument är en översättning av ett engelskt orginal. Om det finns tveksamheter eller fel i detta dokument, så är senaste version av det engelska orginalet den auktoritativa versionen. Copyright tillhör W3C, enligt nedan.

Översättare: Olle Olsson, SICS/W3CSweden

s_gotoW3cHome Internationalization
 

Att välja & använda en teckenkodning

Avsedd läsarkrets: XHTML/HTML-kodare (använder redigeringsverktyg eller skripts), skriptutvecklare (PHP, JSP, etc.), CSS-kodare, projektledare för webbprojekt, och alla som är nybörjare vad gäller teckenkodning och behöver en inledning till hur man väljer och tillämpar teckenkodningar.

Obs: Det engelska originaldokumentet har ändrats sedan det översattes. Se ändringsloggen.

Frågor

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

Bakgrundsinformation

Innehåll består av en sekvens av tecken. Tecken står för alfabetiska bokstäver, interpunktion, etc. Men innehåll lagras på en dator som en sekvens av bytes, som ä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 knyckel för en teckenkodning.

Det finns många teckenkodningar att välja mellan. Denna artikel ger enkla råd om vilken teckenkodning du ska använda för ditt innehåll och hur du tillämpar den, dvs hur du faktiskt skapar ett dokument i den kodningen.

Om du behöver lite mer information om vad tecken och teckenkodningar är, läs då artikeln Character encodings for beginners.

Svar

Använd UTF-8, om så är möjligt

En HTML-sida kan bara ha en kodning. Du kan inte koda olika delar av ett dokument med olika kodningar.

En Unicode-kodning som UTF-8 kan stödja många språk, och kan hantera sidor och formulär som består av en blandning av sådata språk. Om man använder denna kodning så slipper man ha logik på servern som skall bestämma teckenkodning för alla enskilda sidor som skall levereras eller för varje mottaget ifyllt formulär. Detta reducerar markant komplexiteten i att hantera en flerspråkig webbplats eller tillämpning.

Med en Unicode-kodning kan man även blanda flera språk på en enskild sida än man kan för nästan alla andra val av kodning.

Tröskeln för att använda Unicode är numera låg. I själva verket rapporterade Google i augusti 2010 att mer än 50% av webbsidorna i deras urval av flera miljarder sidor numera använder UTF-8. Om man till detta lägger andelen webbsidor i ren ASCII (eftersom ASCII är en delmängd av UTF-8) så stiger siffran till nästan 70%.

Det finns tre olika teckenkodningar i Unicode: UTF-8, UTF-16 och UTF-32 (se Character sets, coded character sets, and encodings). Av dessa tre rekommenderas att UTF-8 används för webbinnehåll. I själva verket anger det nuvarande utkastetet till specifikation för HTML5 "Författare uppmuntras att använda UTF-8. Granskare av hur innehåll följer standard kan avråda författare från att använda gamla kodningar. Författarverktyg bör normalt använda UTF-8 för nyskapade dokument."

Man bör uppmärksamma att att alla ASCII-tecken i UTF-8 använder exakt samma bytes som en ASCII-kodning, vilket ofta underlättar för interoperabilitet och bakåtkompatibilitet.

Att en webbläsare stöder en viss kodning, särskilt sådana som Unicode, betyder inte nödvändigtvis att webbläsaren kommer att presentera texten på ett korrekt sätt. Ett flertal skriftsystem, såsom arabiska och indiska, kräver ytterligare regler för att teckensekvensen i minnet ska kunna transformeras till en lämplig sekvens av glyfer (symboler) att presentera.

Om du inte använder Unicode. Välj en kodning som maximerar möjligheten att direkt representera tecken, och minimerar behovet att representera tecken genom att använda undantagstecken (escape-tecken).

Då det finns alternativa kodningar för ett givet språk, skript eller grupp av språk, välj då den kodning som har bäst stöd, och kontrollera att webbläsare på ett acceptabelt sätt stöder den valda kodningen.

Om möjligt, gör ett val som minimerar komplexitet då du behöver hantera flera språk och skriftsystem.

Undvik dessa kodningar

Specifikationen för HTML5 lyfter fram ett antal kodningar som du bör undvika.

Dokument bör inte använda JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), kodningar baserade på ISO-2022, eller kodningar baserade på EBCDIC. Orsaken är att de låter vissa numeriska kodvärden i ASCII stå för tecken som inte ryms inom ASCII, och detta skapar säkerhetsproblem .

Dokument får inte använda kodningarna CESU-8, UTF-7, BOCU-1, eller SCSU, eftersom de aldrig avsågs användas för webbinnehåll.

Specifikationen avråder även från att använda UTF-32.

Att tillämpa en kodning på ditt innehåll

Då du skapar innehåll måste du kontrollera att ditt redigeringsverktyg eller skripts genererar text i den kodning du valt.

Utvecklare måste även försäkra sig om att de olika delarna av ett system kan kommunicera med varandra, förstå vilka teckenkodningar som används, och stödja alla använda kodningar och tecken.

Det är viktigt att inse att genom att bara deklarera kodningen inne i ett dokument eller på en server (enligt någon av metoderna nedan) kommer vanligtvis inte någon ändring av dokumentets bytes att ske; du måste spara texten i den valda kodningen för att dokumentet skall få just den kodningen. (Deklarationen är bara till för att hjälpa webbläsaren att tolka den sekvens av bytes som utgör den lagrade texten.)

Artikeln Setting encoding in web authoring applications ger råd om hur man anger kodningen av en sida när man sparar den, för ett antal redigeringsverktyg.

Om du har möjlighet, så bör du i ditt redigeringsverktyg sätta standardkodning för nya dokument till en kodning som UTF-8. Följande bild visar hur du kan göra det via användarinställningar i ett verktyg som Dreamweaver.

DreamWeavers nya användarinställningar ger dig möjlighet att specificera en standardkodning.

Du kan också behöva kontrollera att din server levererar dokument med rätt HTTP-deklaration, eftersom annars en sådan deklaration går före kodningsinformation i ditt dokument (se nästa sektion).

Varför kan webbläsaren ändå inte känna igen kodningen?

Antag att du sparat din data som UTF-8. Fastän du sparat din data i rätt kodning, och även om du deklarerat i sidan att den har kodats i UTF-8, så kanske din server ändå levererar sidan med ett HTTP-huvud som säger något annat.

Om det finns en kodningsdeklaration i ett HTTP-huvud så ignoreras kodningsinformation angiven inne i sidan, och det skapar problem för ditt innehåll.

Du kanske inte har rätt att påverka de deklarationer som sänds i HTTP-huvuden, och i så fall måste du kontakta webbserveradministratörerna för att få hjälp. Å andra sidan kan det finnas sätt för dig att ändra vissa aspekter på serverns sätt att arbeta, om du har viss tillgång till serverfiler med inställningar, eller om du genererar sidor med skripts. Se till exempel i Att sätta charset-parametern i HTTP, där det finns mer information om hur man kan ändra kodningsinformation, antingen lokalt för en uppsättning filer, eller för innehåll som genereras med hjälp av skripts.

I allmänhet måst du, innan du gör några sådana ändringar, kontrollera att detta verkligen är orsaken till problemet. Du kan till exempel använda W3C Internationalization Checker för att få reda på vilken teckenkodning (om någon) har angivits i HTTP-huvud. Alternativt ger artikeln Att granska HTTP-headers några pekare till andra verktyg som kan hjälpa dig att granska den kodningsinformation som servern levererar.

Tala om för oss vad du tycker (på engelska).

Prenumerera på en RSS-kanal.

Nya resurser

Nyheter på hemsidan

Twitter (Nyheter på hemsidan)

‎@webi18n

Mer att läsa

Av: Richard Ishida, W3C. Översättare: Olle Olsson, SICS/W3CSweden.

Valid XHTML 1.0!
Valid CSS!
Kodad i UTF-8!

Översatt från engelskt innehåll skapat/ändrat 2010-08-12. Översättningen senast ändrad 2011-07-25 19:11 GMT

Information om ändringar i orginaldokumentet kan fås genom att söka efter qa-choosing-encodings i i18n-bloggen.