Att deklarera teckenkodning i CSS

Fråga

Hur deklarerar jag teckenkodningen av en formatmall i CSS?

Om du har någon text i din CSS-fil som inte är kodad i ASCII, till exempel icke-ASCII-tecken i fontnamn, i värden för egenskapen ”content”, i selektorvärden, etc., så måste du försäkra dig om att CSS-parsern vet hur den ska korrekt transformera dessa bytes till tecken, så att den förstår din CSS-kod. Denna artikel beskriver hur du kan göra detta.

Snabbt svar

Du bör alltid använda UTF-8 som teckenkodning för dina formatmallar och dina HTML-sidor, och ange denna kodning i din HTML. Om du gör det, så finns det inget behov av att deklarera kodningen i din formatmall.

Andra ansatser behövs endast om dina formatmallar innehåller tecken som inte finns i ASCII, och du av något skäl inte kan lita på att teckenkodningen av HTML-koden stämmer överens med teckenkodningen av den använda formatmallen. I ett sådant fall bör du använda @charset eller HTTP-huvuden för att ange teckenkodningen. (Om dina HTML- och CSS-filer använder samma kodning så kommer de senaste versionerna av vanliga webbläsare att använda samma teckenkodning för CSS-formatmallen som den använde för HTML-filen.)

Detaljer

Att använda @charset

Som nämnts ovan bör du endast använda denna när din formatmall och den HTML-fil som använder formatmallen har olika teckenkodningar.

Det är viktigt att förstå ett fastän deklarationen @charset ser ut som en CSS-regel, så används den inte för att upptäcka teckenkodningen. Det är endast en exakt bytesekvens, som utgör de absolut första bytes i formatmallen, som tar effekt. Variationer, även de som skulle vara giltiga för normala at-regler, kommer att helt ignoreras.

Om du vill ange teckenkodning inne i en formatmall, använd då följande sekvens av bytes, bortsett från delen charset-name, precis i början av filen, en byte per tecken.

@charset "charset-name";

Notera att charset-name inte är känsligt för stora/små tecken, men bör alltid vara utf-8 för nya formatmallar. Om du av olika skäl inte kan koda dina formatmallar i UTF-8, läs då avsnittet Att arbeta med andra kodningar än UTF-8, nedan.

Endast en bytesekvens @charset kan finnas i en extern formatmall, och den måste vara placerad alldeles i början av dokumentet. Det får inte finnas några andra tecken före, inte ens kommentarer.

Observera! Det räcker inte med att bara placera @charset "utf-8"; i början av formatmallen – du måste även spara din formatmall i teckenkodningen UTF-8. (Se mer om detta i Using an encoding with your content.)

Viktigt: Eftersom HTTP-huvuden har högre prioritet än en deklaration av @charset i dokumentet, så bör du även ta reda på om teckenkodning redan definieras i HTTP-huvudet. Om det finns ett sådant HTTP-huvud, så måste @charset ange samma teckenkodning, och den i dokumentet angivna kodningen kommer bara att ha en praktisk effekt när formatmallen läses i ett sammanhang där kodning inte anges i HTTP-huvud (t.ex. när filer läses direkt från lagringsmedia).

I listan över tekniker att använda finns en uppsättning länkar till dokument som hjälper dig att upptäcka om en deklaration skickas med i HTTP-huvudet.

Hur är det med ”byte-order mark”?

Syntaxspecifikationen för CSS3 säger att om du i din fil har ett byte-ordnings-märke (byte-order mark) vilken anger UTF-8, så borde detta medföra att webbläsaren läser in formatmallen som UTF-8, oberoende av vad andra deklarationer säger om teckenkodning. Oturligt nog så stöds för närvarande inte detta på ett interoperabelt sätt – Internet Explorer 10 och 11 ger fortfarande högre prioritet till HTTP-huvuden och till @charset-deklarationer.

Så tillsvidare bör du ange @charset-deklarationer eller deklarationer i HTTP-huvuden. Det förra har en ytterligare fördel, i att den hjälper de personer som tittar på källkoden att fastställa teckenkodningen av formatmallen. Byte-ordnings-märket är osynligt.

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

Att använda HTTP

Webbservern kanske redan skickar information om normalvärde för teckenkodning, i ett HTTP-huvud med Content-Type, när en webbläsare hämtar en formatmall; eller också gör den inte det. Följande rad i ett levererat HTTP-svar indikerar att filen är kodad i UTF-8.

Content-Type: text/css; charset=utf-8

Det kan vara så att webbservern, för en formatmall, levererar en deklaration av teckenkodning som du inte vill ha, vilket kan bero på serverns standardinställningar eller på specifika parametersättningar. Eller så levererar den ingen information om teckenkodning, när du i själva verket vill att den skall göra det. Du kan modifiera webbserverns generella beteende, eller dess beteende för en viss uppsättning filer, genom att modifiera inställningarna för servern (globalt eller lokalt), eller genom att generera innehåll med skriptspråk som PHP.

Deklarationen i HTTP-huvudet kommer alltid att ha högre prioritet än deklarationer i dokumentet (om det finns en skillnad mellan dessa), förutom för de webbläsare där byte-ordnings-märket har ännu högre prioritet.

Vi rekommenderar dock ändå att om du behöver använda en HTTP-deklaration för att få till rätt teckenkodning, så bör du ändå ha med en @charset-deklaration inne i formatmallen. Detta kommer att säkerställa att man kan få tillgång till kodningsinformation även om formatmallen används lokalt eller får annan lagringsplats, t.ex. vid testning eller redigering.

Ytterligare information

De flesta personer behöver inte känna till informationen i detta avsnitt. Avsikten är bara att ge fullständig information, ifall detta skulle behövas i speciella situationer.

Att arbeta med andra kodningar än UTF-8

Detta avsnitt ska bara läsas om du är förhindrad från att spara dina formatmallar i UTF-8.

Fram till helt nyligen var IANA-registret den plats där man kan hitta namn på teckenkodningar. I IANA-registret finns ofta flera namn för en och samma kodning. I sådana fall bör du välja det namn som angetts som ”preferred”.

Den nya specifikationen Encoding listar teckenkodningar som provats i existerande webbläsarimplementationer. Du hittar listan i tabellen som finns i den sektion vilken benämns Encodings. Det är säkrast att använda de namn som anges i den vänstra kolumnen i den tabellen.

Observera dock att bara för att ett namn förekommer i någon av dessa källor, så behöver det inte betyda att det är fritt fram att använda den teckenkodningen. Ett flertal av dessa kodningar har brister. Om du trots allt inte kan använda UTF-8 så bör du noggrant studera vad som sägs i artikeln Choosing & applying a character encoding.