UTF-8

UTF-8 (8-bit Unicode Transformation Format) er en binær representasjonsform for tegn i Unicode-tegnsett, med variabel tegnlengde, oppfunnet av Ken Thompson og Rob Pike. Unicode er en nummerert samling av tegn, og UTF-8 representerer disse numrene med mellom en og fire byte, og er konstruert slik at de første 128 tegnene (U+0000 til U+007F), samsvarer nøyaktig med US-ASCII-standarden. UTF-8 er dermed bakoverkompatibelt med systemer som støtter ASCII-tekst.

Beskrivelse

UTF-8 er for tiden standardisert i RFC 3629 og er et av flere tegnkodeformater i ISO/IEC 10646.

Bitene i et Unicode-tegn er delt inn i flere grupper. Tegn nummerert under 128 blir kodet med en enkelt byte som inneholder deres posisjon: Disse samsvarer nøyaktig med de 128 7-biters ASCII-tegnene. Til andre tegn brukes opp til fire byte. Den første biten i disse blir alltid satt til 1, for å skille tegnene fra 7-bits ASCII-tegn. De første 128 tegnene (0-127) av Unicode er de samme som ISO-8859-1, så det er enkelt å konvertere mellom disse tegnsettene. Tegnene med nummer 128 – 255, deriblant Æ, Ø, Å, æ,ø og å, blir 2 bytes i UTF-8.

Område heksadesimal	UTF-8 binær	Merknader
000000 - 00007F	0xxxxxxx	ASCII-ekvivalent; første bit begynner med null
000080 - 0007FF	110xxxxx 10xxxxxx	de 2 første bits begynner med 11, de neste begynner med 10
000800 - 00FFFF	1110xxxx 10xxxxxx 10xxxxxx
010000 - 10FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

For eksempel, den hebraiske bokstaven alef (א), som er Unicode-tegn U+05D0, blir kodet i UTF-8 på denne måten:

Det faller innunder området U+0080 til U+07FF. Tabellen viser at det vil bli kodet med to byte, 110xxxxx 10xxxxxx.
0x05D0 i heksadesimal er det samme som 101-1101-0000 i binære tall.
De elleve bitene blir plassert i posisjonene markert av tegnet "x": 11010111 10010000.
Resultatet blir to byte, som kan uttrykkes som 0xD7 0x90 i heksadesimal. Det er bokstaven alef i UTF-8.

De første 128 tegnene behøver dermed en byte. De neste 1920 tegnene kodes med to byte. Dette inkluderer en rekke europeiske tegn (deriblant de skandinaviske), samt greske, kyrilliske, koptiske, armenske, hebraiske og arabiske tegn. De øvrige tegnene bruker tre eller fire byte. (En tidligere UTF-8-standard tillot at enda høyere posisjoner kunne representeres ved å gjøre bruk av fem eller seks byte, men dette støttes ikke lenger.)

Faktisk kan lengden på UTF-8-sekvenser være opp til seks byte, noe som dekker området U+0000 til U+7FFFFFFF (31 bit). Dette er mer enn det definerte Unicode-området, men UTF-8 ble i november 2003 begrenset av RFC 3629 til å bare representere området dekket av den formelle Unicode-definisjonen, U+0000 til U+10FFFF, som er området UTF-16 kan representere. Før dette var det bare bytene 0xFE og 0xFF som aldri ble brukt i UTF-8-kodet tekst. Etter at denne begrensningen ble innført, økte antallet ubrukte byte i en UTF-8-strøm til 13: 0xC0, 0xC1 0g 0xF5-0xFF.

Begrunnelsen bak UTF-8s konstruksjon

Som en konsekvens av UTF-8s konstruksjon har UTF-8-sekvenser de følgende egenskapene:

Den første biten i et tegn som kun tar opp en byte er alltid 0.
De første bitene i den første byten i en sekvens på flere byte angir lengden på sekvensen. Disse er 110 for to-bytes sekvenser, 1110 for tre-bytes sekvenser, og så videre.
De påfølgende byte i en sekvens på flere byte har 10 som deres to første bit.

UTF-8 ble designet for å inneha disse egenskapene for å garantere at ingen bytesekvens som utgjør et tegn inneholdes i en lengre bytesekvens som representerer et annet tegn. Dette sikrer at strenger kan sammenlignes byte for byte for å søke etter ord eller fraser inni en tekst. Enkelte eldre 8-bits encodinger med variabel lengde (som Shift-JIS) hadde ikke denne egenskapen, noe som gjorde algoritmer for sammenligning av strenger heller kompliserte. Selv om det blir sagt at denne egenskapen resulterer i redundans i UTF-8-kodet tekst, er fordelene større enn ulempene; dessuten er ikke datakompresjon en av Unicodes målsetninger. Dette betyr også at hvis en eller flere byte går tapt på grunn av feil, kan en fortsette på begynnelsen av neste tegn og dermed begrense skadene.

Ugyldige sekvenser og sikkerhetsmessige problemstillinger

Hvordan ugyldig UTF-8-data skal håndteres er mer eller mindre udefinert. Ugyldige sekvenser kan håndteres på flere måter:

Erstattes med et gyldig tegn (for eksempel '?', '�')
Hoppes over
Tolkes som et tegn fra et annet tegnsett (ofte Latin-1)
Tolkes som en lignende, gyldig UTF-8-sekvens
Rapporteres med en feilmelding

Ugyldige sekvenser kan selvfølgelig håndteres på forskjellige måter avhengig av hvilken type de er.

Alle mulighetene har fordeler og ulemper, men forholdsregler må tas for å unngå sikkerhetsproblemer som kan oppstå hvis data valideres før de blir konvertert til UTF-8.

Sekvenser der et Unicode-tegn blir kodet som flere byte enn det som er nødvendig, såkalte overlange sekvenser (overlong forms), er en av de mest problematiske formene for data. Den nåværende standarden angir at de ikke må dekodes, men eldre standarder krevde bare en advarsel, og mange enklere dekodere tolker dem som gyldige data. Sekvenser av denne typen er blitt brukt til å omgå sikkerhetsrutiner i profilerte produkter, for eksempel Microsofts IIS-webserver.

For å opprettholde sikkerheten når en håndterer ugyldige data, kan en enten dekode dataene før en gjør noen sikkerhetssjekk av dem, eller benytte en dekoder som avviser ugyldige data med en feilmelding eller erstatter dem med harmløs tekst.

I UTF-8 er det lett å oppdage feil i inndata. I UTF-16 er det ikke så lett, da tolkes data helt enkelt feil. Se for eksempel Bush hid the facts-buggen.

Fordeler

Den mest merkbare fordelen ved Unicode Transformation Format er den store mengden tegn de kan representere.
ASCII-tegnene tar ikke mer enn en byte i UTF-8, selv om andre kan ta opp til fire. Så UTF-8 vil generelt sett ta mindre plass enn UTF-16 eller UTF-32 i tekst der 7-biters ASCII-tegn er vanlige, f.eks. HTML.
En byte-sekvens for ett tegn inngår aldri som del av en lengre sekvens for et annet tegn slik det gjorde i eldre encodinger som Shift-JIS.
Den første byten i en sekvens på flere byte er alt som behøves for å bestemme lengden på sekvensen. Dette gjør det enkelt å plukke ut substrenger fra en større tekststreng.
Det meste av eksisterende software (inkludert operativsystemer) ble ikke skrevet med Unicode i tankene, og å bruke Unicode med disse kunne tenkes å skape kompatibilitetsproblemer. UTF-8 er derimot designet for å være bakoverkompatibelt med ASCII. Man kan bruke UTF-8 i programspråk og kompilatorer som ikke er designet for Unicode.
Sortering av UTF-8-strenger etter byteverdi vil gi samme resultat som sortering basert på Unicode-posisjoner, uten at dette nødvendigvis er en ideell sorteringdmetode.
UTF-8 er en av standardene som inngår i HTML-dokumenter og XML-dokumenter.

Ulemper

UTF-8 har variabel tegnlengde, det vil si at forskjellige tegn representeres av sekvenser av forskjellig lengde. Dette fører til nedsatt hastighet i systemer som behandler UTF-8-tekst.
En dårlig skrevet UTF-8-tolker vil kunne akseptere en mengde ugyldige UTF-8-sekvenser og tolke som gyldig Unicode-data. Dette kan brukes til å snike data forbi valideringsrutiner som er designet for å håndtere 8-bits data.
Kinesiske tegn bruker tre bytes i UTF-8, men bare to i UTF-16 og i eldre kinesisk og japansk metode. Så kinesisk, japansk og koreansk tekst tar opp mer plass i UTF-8 enn i UTF-16. Hindi (Indisk) bruker tre bytes i UTF-8, og en byte i eldre indisk metode, og deres naboer i Pakistan trenger kun to bytes i UTF-8.
Norsk tekst tar mer plass enn i iso-8859-1 og iso-8859-15, siden nordiske tegn tar 2 byte i UTF-8. Økningen er typisk mellom 1 og 2 % i tekster med få fremmedord.
ISO-8859-1 er veletablert i Vest- og Nord-Europa. Konvertering til UTF-8 fører til problemer med programvare som ikke støtter det.

Historie

UTF-8 ble oppfunnet av Ken Thompson den 2. september 1992 på en bord-matte under en middag med Rob Pike i New Jersey. Dagen etter implementerte Pike og Thompson UTF-8, og oppdaterte sitt operativsystem Plan 9 slik at det brukte UTF-8 tvers igjennom.

UTF-8 ble først offisielt presentert under USENIX-konferansen i San Diego 25. januar-29. januar 1993.

Eksterne lenker

Rob Pike forteller historien om UTF-8s tilblivelse
Den originale rapporten om UTF-8
RFC 3629, UTF-8-standarden
RFC 2277, IETFs policy om tegnsett og språk
UTF-8 and Unicode FAQ
UTF-8
Nok en UTF-8-testside Arkivert 30. november 2017 hos Wayback Machine.
W3C UTF-8-validerer og en uoffisiell variant.
UTF-8 and Debian og Linux UTF-8 How-To.

Autoritetsdata