UTF-8 (åtta-bitars Unicode transformationsformat) är en längdvarierande teckenkodning som används för att representera text kodad i Unicode, som en sekvens av byte (oktetter). Unicode använder upp till 21 bitar per tecken, vilket inte får plats i en byte, och därför används till exempel i textfiler vanligen en av metoderna UTF-8 eller UTF-16 för att få en serie bytes.

Ordet "Wikipedia" kodat i ASCII / UTF-8 (i det här fallet är kodningen identisk), visat som en följd av binära siffror.

UTF-8 har valts som huvudsaklig teckenkodning i internetprotokoll: nya protokoll måste ge stöd till denna teckenkodning, om det inte av speciella skäl är olämpligt.[1]

Kompatibilitet

redigera

UTF-8 är konstruerat så att tecken som tillhör ASCII-tabellen (som täcker A–Z, a–z, 0–9, vanligt förekommande interpunktion samt ett antal kontrolltecken) kommer att kodas på samma sätt i både ASCII och UTF-8, och inga byte som inte är ASCII-tecken kan misstolkas som ASCII-tecken. Det gör UTF-8 lämpligt för tillämpningar där man eventuellt tolkar vissa följder av ASCII-tecken speciellt (som nyckelord på något sätt), medan resten av texten hanteras som fritext – till exempel för webbsidor eller dataprogram. HTML-koder (till exempel <br />) blir oförändrade jämfört med en traditionell 8-bitskodning, men man kan ändå få stöd för alla världens språk. UTF-8 har blivit den vanligaste kodningen för webbsidor.

Man kan också med UTF-8 ganska lätt införa Unicode i existerande system där mjukvara tolkar filer såsom programspråk (om dess nyckelord är på engelska), genom att byta ut editorn och modifiera in- och utmatningsrutiner. Normalt används i programspråk 7-bit ASCII för allt, utom textsträngar där fulla 8-bits bytes används men där kompilatorn inte gör tolkningar av deras innehåll. Eftersom ASCII-tecken är oförändrade i UTF-8 fungerar kompilatorer och existerande programkodsfiler oftast även om de inte är gjorda för UTF-8.

Program som inte uppdaterats för Unicode, eller av någon anledning tolkar byte-strömmen som något annat än UTF-8, kan visa fel tecken. Ett program som felaktigt tolkar byte-strömmen som om den vore kodad i Latin-1 (ISO/IEC 8859-1), kan om texten "knäckebröd av råg" är kodad i UTF-8, visa den som "knäckebröd av rÃ¥g". Detta har varit ett vanligt problem eftersom det ofta inte går att veta vilken teckenkodning som gäller (till exempel i en textfil eller på IRC). Det har gällt särskilt text från Internet, då kodningen inte angivits eller angivits fel. Problemen har minskat allt eftersom programvara uppdateras och UTF-8 används alltmer. Syftet med Unicode är att det inte ska behöva införas ytterligare standarder och därför borde dessa problem inte dyka upp mer. Inte minst har olika äldre kodningar misstagits för varandra, särskilt utanför Norden och Västeuropa, och syftet med Unicode är att lösa de problemen.

Eftersom UTF-8 kodar på ett visst sätt (första byten för ett tecken utanför ASCII har C0-F7 (hex), övriga har 80-BF), kan en modern texteditor eller webbläsare i många fall se i själva filen att den är kodad i UTF-8 och därmed Unicode, och tolka tecknen rätt. Detta är en stor fördel mot nästan alla äldre kodningar, då det var svårt eller omöjligt att räkna ut kodningen om den inte angavs explicit. Också i text som i huvudsak består av ASCII är det osannolikt att enskilda andra tecken av en slump blir giltig UTF-8.

I Windows brukar Unicode-textfiler ha ett specialtecken först (U+FEFF, som inte visas), och med UTF-8 då blir de tre första bytena EF BB BF. Denna markering visar direkt att det rör sig om UTF-8. I Unix brukar man inte ha någon sådan markering, då de första tecknen i filen används på andra sätt (automatiskt tolkade textfiler är vanliga, medan Windows i högre grad använder binärfiler). Det går i allmänhet ändå bra att identifiera att en text är kodad i UTF-8. Windows använder UTF-16LE för sina interna filer, medan Mac och Linux använder UTF-8.

UTF-8 är en standardiserad del av ISO/IEC 10646, Unicode, och även standardiserad av RFC 3629 (UTF-8, a transformation format of ISO/IEC 10646). Nedan ges en sammanfattning.

Beskrivning

redigera

Tecken (kodpunkter) lagrade med UTF-8 varierar i längd, 1–4 byte (oktetter). Om den mest signifikanta biten i den första byten är noll, är det ett ASCII-tecken (kodat i en enda byte). Annars ger antalet mest signifikanta bitar som är ett (före första noll-biten) i första byten sekvensens längd, vilket kan vara två till fyra. Om sekvensen spänner över flera bytes, startar efterföljande bytes (oktetter) alltid med bitmönstret 10. Representationer som använder fler bytes än nödvändigt är felaktiga. Kodsekvenser som skulle representera surrogatkodpunkter (inom U+D800–U+DFFF, avsedda för UTF-16) är även de felaktiga, liksom U+FFFE–U+FFFF och vissa andra tecken. De kodpunkter (teckennummer) som kan representeras är begränsat till U+0000–U+10FFFF (det är UTF-16 som sätter övre gränsen, UTF-8 möjliggör egentligen U+1FFFFF)

Eftersom UTF-32, UTF-16 och UTF-8 sträcker sig över samma kodpunkter, kan konvertering ske mellan dessa tre kodscheman utan förlust.

Jämförelse mellan de olika kodningarna UTF-16 och UTF-8.
Kodintervall hexadecimalt UTF-16 UTF-8 binärt Anmärkning
U+0000 – U+007F: 00000000 0xxxxxxx 0xxxxxxx UTF-8-kodningen är här samma som ASCII; bitsekvensen startar med värdet noll, liksom alla ASCII-koder
U+0080 – U+07FF: 00000xxx xxxxxxxx 110xxxxx 10xxxxxx Bitsekvensen i första byten startar med lika många "1" som antalet bytes (2–4), följt av "0". Följande bytes startar med bitsekvensen "10"
U+0800 – U+FFFF: xxxxxxxx xxxxxxxx 1110xxxx 10xxxxxx 10xxxxxx
U+10000 – U+10FFFF: 110110xx xxxxxxxx 110111xx xxxxxxxx* 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx UTF-16 använder 32 bitar, två dubbelbytes, i intervallet U+D800–U+DFFF för att lagra sådana tecken.

Till exempel, tecknet alef ( ), som har Unicode-kodpunkten U+05D0, kodas i UTF-8 på följande sätt:

  • Tecknet finns inom intervallet 0x0080–0x07FF, vilket gör att det måste representeras av två bytes: 110x xxxx 10xx xxxx.
  • Hexadecimala 0x05D0 är binärt 101 1101 0000.
  • De elva bitarna stoppas i positionerna markerade med x ovan (man lägger till ledande 0-bitar när så behövs, men inte fler än nödvändigt): 1101 0111 1001 0000.
  • Slutresultatet är två bytes, i hexadecimal form 0xD7 0x90.
  • Eller i oktal form:
    • 0200–3777 oktalt ska kodas som två bytes. xxyy ska kodas som 3xx 2yy. Exempelvis, 0x05D0 är 02720 oktalt, vilket blir 327 220 oktalt eller D7 90 hex.
    • 4000–177777 oktalt ska kodas som tre bytes. xxyyzz ska kodas som (340+xx) 2yy 2zz. Exempelvis, 0x2248 () är 021110 oktalt, vilket blir 342 211 210 oktalt eller E2 89 88 hex.
    • 200000-4177777 oktalt ska kodas som fyra bytes. wxxyyzz ska kodas som 36w 2xx 2yy 2zz.

De första 128 kodpunkterna behöver bara en byte (oktett). Med två bytes kan UTF-8 representera 1920 olika kodtecken, med tre bytes ryms 63488 teckenkoder (kodpunkter upp till 65536 / U+FFFF, 2048 surrogatkoder undantagna), och med fyra bytes kan alla övriga kodpunkter (utom surrogatkodpunkter) representeras. I vissa fall behövs fler än en kodpunkt för att representera ett tecken, till exempel då ett tecken är en ligatur som består av flera bokstäver, såsom ofta i indiska språk, då tecknet består av en grundbokstav med diakritiska tecken (till exempel i vietnamesiska) eller då en viss variant av ett tecken behövs (då samma tecken skrivs olika i olika CJK-språk). I många fall – men inte alla – finns alternativa kodpunkter, såsom U+00E9 (”é”) för ”´”+”e”.

Exempel på skriftsystem som kräver två bytes per tecken i UTF-8 är (de flesta ur) de latinska, grekiska, kyrilliska, armeniska, hebreiska och arabiska alfabetena. Däremot behöver japanska, kinesiska, koreanska, thailändska med flera språk tre bytes per kodpunkt och ibland två kodpunkter för ett tecken.

UTF-8 ger mindre filer än UTF-16 för alla språk som kräver max två bytes per tecken, eftersom det alltid finns blanktecken, komma med mera som kräver 1 byte. Text med latinskt alfabet ger mycket mindre filer än UTF-16 och obetydligt mer än 8-bitskodningar, eftersom de flesta bokstäver representeras med en byte. Däremot kräver många öst- och sydasiatiska språk mer utrymme för UTF-8 än andra kodningar. Särskilt i Indien har det varit kritik mot det då de hittills använt en egen 8-bitskodning som bara varit gjord för hindi och engelska. UTF-8 tar tre gånger så mycket minnesutrymme för hindibokstäver som äldre kodning. Unicode ger den betydande fördelen i Indien att alla mer än 10 skriftspråk stöds utan problem, också då den förekommer i samma dokument. Det måste nämnas att för webbsidor som har mycket html-koder (som lagras med en byte per tecken i UTF-8 och två i UTF-16) så tar UTF-8 mindre utrymme än UTF-16 även för östasiatiska språk.

Betydelsen för värden på enskilda bytes
Kodintervall hexadecimalt Tecken Betydelse
00–1F ASCII styrtecken
20–3F !"#$%&'()*+,-./0123456789:;<=>? ASCII skiljetecken och siffror
40–5F @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ ASCII mestadels stora bokstäver
60–7F `abcdefghijklmnopqrstuvwxyz{|}~ ASCII mestadels små bokstäver
80–BF 2:a–4:e byte i en kodpunkt (tecken)
C0–C1 Ej tillåtna bytes
C2–DF 1:a byte i en kodpunkt U+0080 – U+07FF
E0–EF 1:a byte i en kodpunkt U+0800 – U+FFFF
F0–F4 1:a byte i en kodpunkt U+10000 – U+10FFFF
F5–FF Ej tillåtna bytes

Historik

redigera

UTF-8 uppfanns av Ken Thompson och Rob Pike, båda jobbade då vid Bell Labs, den 2 september 1992, under ett restaurangbesök i New Jersey. Man hade då nyligen kommit fram till att man behövde ett filformat för Unicode som var bakåtkompatibelt med ASCII. UTF-8 presenterades i januari 1993.

Se även

redigera
  • UTF-16, ett sätt att koda Unicode-texter i 16-bitarssekvenser (eller 2-byte).
  • UTF-32, Unicode-kodning med 32-bitar per kodpunkt

Källor

redigera
  1. ^ RFC 2277: IETF Policy on Character Sets and Languages (status: best current practice)
  NODES
Done 1
punk 19