Att deklarera teckenkodning i HTML

Fråga

Hur bör jag deklarera kodningen av min HTML-fil?

Du bör alltid ange vilken kodning som använts för en HTML- eller XML-sida. Om du inte gör detta, så finns risken att tecken i ditt innehåll tolkas på ett oriktigt sätt. Det handlar inte bara om läsbarhet för människor, eftersom även maskiner i allt större utsträckning hanterar dina data. En deklaration av teckenkodning behövs också för hantering av icke-ASCII-tecken som matas in av användare i formulär; i URL:er genererade av skript; osv. Denna artikel beskriver hur man gör detta för innehåll som är HTML-filer.

Om du behöver få bättre insikt i vad tecken och teckenkodningar är, så titta då på artikeln Character encodings for beginners. För information om hur man deklarerar teckenkodningar av formatmallar i CSS, titta då på CSS character encoding declarations.

Snabbt svar

Ange alltid vilken kodning ditt dokument har, genom att använda elementet meta med attributet charset, eller genom att använda attributen http-equiv och content (även kallad pragma-direktiv). Deklarationen skall i sin helhet rymmas inom de första 1024 bytes räknat från början av filen, så det är bäst att ange den direkt efter starttaggen head.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
...
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" 
      content="text/html; charset=utf-8">
...

Det har ingen betydelse vilken av dessa ansatser du väljer, men det är enklare att skriva enligt det första alternativet. Det har heller ingen betydelse om du skriver UTF-8 eller utf-8.

Du bör alltid använda UTF-8 som teckenkodning. (Kom ihåg att du även måste försäkra dig om att spara ditt innehåll i UTF-8-format.) Titta på vad som står i denna artikel om vad du bör tänka på om du av något skäl inte kan använda kodningen UTF-8.

Om du har möjlighet att påverka inställningarna av din webbserver, så bör du även fundera på om det är vettigt att använda HTTP-huvuden. Tänk dock på att, eftersom HTTP-huvuden har högre prioritet än meta-deklarationer i dokumentet, så bör innehållsförfattare alltid ta reda på om teckenkodning redan anges i HTTP-huvudet. Om det är på det sättet, så måste meta-elementet ange samma teckenkodning.

Du kan ta reda på om information om teckenkodning sändes i HTTP-huvudet, genom att använda internationaliseringsgranskaren.

Detaljer

Hur är det med byte-ordnings-märket?

Om du har ett UTF-8 byte-ordnings-märke (BOM) i början av din fil, så kommer aktuella versioner av webbläsare (utom Internet Explorer 10 eller 11) att använda detta för att hantera din sida som en UTF-8-fil. Detta har högre prioritet än alla andra deklarationer, alltså även högre än vad som anges i HTTP-huvudet.

Du behöver inte ange kodning med en meta-deklaration om du har en BOM, men vi rekommenderar ändå att du anger en sådan, eftersom det kan hjälpa de som inspekterar källkod för att avgöra vilken kodning som använts för sidan.

Läs mer om byte-ordnings-märket.

Bör jag deklarera kodning i HTTP-huvudet?

Använd deklaration av teckenkodning i HTTP-huvuden om det känns vettigt och om du får ange sådan, för alla typer av innehåll, men tillsammans med en deklaration i dokumentet självt.

Innehållsförfattare bör alltid säkerställa att HTTP-deklarationer är konsistenta med deklarationer i dokumentet självt.

För- och nackdelar med att använda HTTP-huvuden

En fördel av att använda HTTP-huvuden är att webbläsaren kan hitta information om teckenkodning tidigare när den sänds i HTTP-huvudet.

Å andra sidan, så finns ett antal potentiella nackdelar:

  • Det kan vara svårt för innehållsförfattare att ändra kodning för statiska filer på en server – speciellt när man utnyttjar en ISP. Författare behöver ha kunskap om och tillgång till inställningarna för servern.

  • Serverns inställningar kan bli inkonsistenta med dokumentet av olika orsaker. Detta kan t.ex. ske när man förlitar sig på att servern har vissa normalinställningar, och att dessa inställningar faktiskt ändras. I så fall kan det vara kritiskt, eftersom information i HTTP-huvudet har högre prioritet än deklarationer i dokumentet, och detta kan göra att dokumentet blir oläsbart.

  • Det finns potentiella problem med såväl statiska som dynamiska dokument, om de inte hämtas från en server, t.ex. om de har sparats på en CD eller på en hårddisk. I sådana fall finns ingen HTTP-server som kan leverera information om kodning.

    Och om teckenkodningen bara anges i HTTP-huvudet, så finns inte denna information tillgänglig när filerna redigeras, eller när de bearbetas av sådant som XSLT eller skripts, eller när de sänds iväg för översättning, etc.

Bör jag alltså använda denna metod?

Om filer levereras via HTTP från en server, så finns det inga problem med att sända information om dokumentets teckenkodning i HTTP-huvud, så länge som denna information är korrekt.

Å andra sidan, på grund av de nackdelar som nämnts ovan, rekommenderar vi att du alltid även deklarerar information om kodningen i dokumentet självt. En deklaration i dokumentet underlättar för utvecklare, testare och översättare som vill vill visuellt kontrollera kodningen av ett dokument.

(Vissa argumenterar för att det sällan är rimligt att deklarera kodningen i HTTP-huvudet om du i alla fall ska repetera denna information i dokumentets innehåll. Här rekommenderar de att HTTP-huvudet inte säger något om kodningen av dokumentet. Notera att detta vanligen innebär att man bör konfigurera servern så att den inte levererar någon information om kodning.

Att arbeta med polyglott format och XML-format

XHTML5: Ett dokument i XHTML5 levereras som XML och har XML-syntax. XML-parsers hanterar inte kodningsdeklarationer i meta-element. De agerar bara på XML-deklarationen. Här är ett exempel:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html ....

En sådan XML-deklaration krävs endast då sidan inte levereras som UTF-8 (eller UTF-16), men det kan ändå vara bra att ange en sådan, så att utvecklare, testare och översättare visuellt kan få information om kodning av dokumentet genom att titta på källkoden.

Polyglott uppmärkning: en sida som använder polyglott uppmärkning är uttryckt i en delmängd av HTML, och använder XML-syntax som kan hanteras antingen av en HTML-parser eller en XML-parser. Detta beskrivs i Polyglot Markup: A robust profile of the HTML5 vocabulary.

Eftersom ett polyglott dokument måste vara kodad i UTF-8, så behöver man inte, och faktiskt får inte, använda en XML-deklaration. Å andra sidan, om filen ska läsas som HTML så måste man ange kodningen med ett meta-element, med ett byte-ordnings-märke eller med ett HTTP-huvud.

Eftersom en deklaration i ett meta-element bara kommer att påverka hur en HTML-parser arbetar, så måste, om man använder content-attributet, dess värde börja med text/html;.

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

Om du använder meta-elementet med attributet charset så behöver du inte tänka på detta.

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.

Att arbeta med andra kodningar än UTF-8

Om man använder UTF-8 så förenklas skapandet av sidor, men dessutom undviker man oväntade effekter vid insändning av data i ett formulär och URL-kodning, som normalt använder dokumentets teckenkodning. Om du trots allt måste använda tecken som inte kodas i UTF-8, så måste du välja från en liten uppsättning kodningsnamn, för att uppnå maximal interoperabilitet och långsiktig läsbarhet för ditt innehåll.

Fram till relativt nyligen var IANA-registret den plats där man kunde hitta namn på kodningar. I IANA-registret förekommer ofta flera olika namn på samma kodning. I sådana fall bör man använda det namn som angetts som ”preferred”.

Den nya specifikationen Encoding ger nu en förteckning av kodningsnamn som testats i riktiga implementationer av webbläsare. Du hittar den förteckningen i sektionen som heter Encodings. Det är bäst att använda namn som anges i den vänstra kolumnen i den tabellen.

Lägg dock märke till att bara för att ett namn förekommer i någon av dessa källor, så är det inte alltid rekommendabelt att använda den kodningen. Flera av kodningarna medför problem. Om du verkligen inte kan använda UTF-8, så bör du noggrant överväga de råd som ges i artikeln Choosing & applying a character encoding.

Uppfinn inte egna namn på kodningar genom att inleda dem med x-. Sådant är inte bra, eftersom det begränsar interoperabilitet.

Att arbeta med gamla HTML-format

HTML 4.01 specificerar inte användning av attributet charset för elementet meta, men alla vanliga webbläsare kommer ändå att leta efter det och använda det, även om sidan anges vara i HTML4 och inte i HTML5. Denna sektion är bara relevant om du använder äldre HTML-format av andra skäl än att leverera till en webbläsare. Här beskrivs skillnaderna gentemot vad som sagts i sektionen Detaljer ovan.

För sidor som levereras som XML, läs då Att arbeta med polyglott format och XML-format.

HTML4: Som nämnts ovan så behöver du används pragma-direktivet för att följa standarden HTML 4.01, och inte attributet charset.

XHTML 1.x levererad som text/html: Här behövs också pragma-direktivet för att följa standarden HTML 4.01, och inte attributet charset. Du behöver inte ange XML-deklaration, eftersom filen levereras som HTML.

XHTML 1.x levererad som XML: Använd encoding-deklarationen i XML-deklarationen på första raden av sidan. Försäkra dig om att XML-deklarationen inte föregås av annan text i sidan, inte ens blanka tecken (men ett byte-ordnings-märke får finnas där).

Attributet charset på en länk

HTML5 har nedgraderat användningen av attributet charseta-element och link-element, och du bör alltså inte använda attributet i samband med dessa. Denna användning har sitt ursprung i specifikationen HTML 4.01, och användes där tillsammans med elementen a, link och script , och tanken var att på detta sätt indikera kodningen av det dokument du länkar till.

Det förutsågs användas på inbäddade länkar på följande sätt:

 Dålig kod. Kopiera inte!
Se vår <a href="/mysite/mydoc.html" charset="iso-8859-15">förteckning över publikationer</a>.

Tanken var att webbläsare skulle kunna tillämpa korrekt kodning på det dokument det hämtar, om det dokumentets kodning inte angavs på något annat sätt.

Det har alltid funnits problem med sådan av användning av detta attribut. För det första så är det inte brett stött av större webbläsare. En anledning att inte stödja detta attribut är att om webbläsare tar hänsyn till denna information om kodning, och det inte finna andra regler som styr hämtning av inlänkat innehåll, så kan detta användas för säkerhetsattacker. För det andra är det svårt att säkerställa att kodningsinformationen är korrekt. Den som ansvarar för det inlänkade dokumentet kan ändra dess kodning utan att du vet om det. Om skaparen av det inlänkade dokumentet inte har angett vilken kodning som används, så kommer webbläsaren att tillämpa fel kodning på det hämtade dokumentet. Och för det tredje så bör det inte vara nödvändigt att ange kodning på detta sätt, om skapare av sidor följer de råd som ges i denna artikel och ger relevant uppmärkning i sina dokument. Det är en mycket bättre ansats.

Detta sätt att ange kodning av dokument har den lägsta prioriteten (dvs om kodning har angivits på något annat sätt, så kommer kodningsinformationen angiven i länkelementet att ignoreras). Det betyder att du inte heller kan använda denna form för att korrigera inkorrekta deklarationer av kodningar.

Att arbeta med UTF-16

En undersökning som Google gjort av flera miljarder sidor visar att färre än 0,01% av sidorna på webben kodats i UTF-16. Mer än 80% av alla webbsidor är i UTF-8, om man i detta inräknar även delmängden ASCII, och mer än 60% om man inte gör det. Vi avråder å det starkaste användning av UTF-16 som kodning av dina sidor.

Om du av något skäl ändå måste använda UTF-16, så ger vi här några regler för hur man då deklarerar kodning. De skiljer sig från råden för andra kodningar.

HTML5-specifikationen förbjuder användning av elementet meta för att deklarera användning av UTF-16, eftersom värdet måste vara ASCII-kompatibelt. Istället bör du försäkra dig om att du alltid har ett byte-ordnings-märke alldeles i början av en fil kodad i UTF-16. I praktiken fungerar detta som en deklaration i dokumentet självt.

Om din sida kodas som UTF-16, deklarera inte kodningen för din fil som "UTF-16BE" eller "UTF-16LE", använd endast "UTF-16". Byte-ordnings-märket i början av din fil indikerar om kodningsschemat är little-endian eller big-endian. (Detta fungerar eftersom innehåll explicit kodat som t.ex. UTF-16BE inte bör använda byte-ordnings-märke, men HTML5 kräver ett byte-ordnings-märke för sidor kodade i UTF-16.)