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*.

[[Bit]]ene 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.



For eksempel, den hebraiske bokstaven *alef* (&#1488;), 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, *110*xxxxx *10*xxxxxx.
* 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": *110*10111 *10*010000.
* 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 [[Gresk alfabet|greske]], [[Kyrillisk alfabet|kyrilliske]], [[koptisk alfabet|koptiske]], [[armensk alfabet|armenske]], [[hebraisk alfabet|hebraiske]] og [[arabisk alfabet|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 [https://web.archive.org/web/20050317090404/http://www.ietf.org/rfc/rfc3629.txt RFC&nbsp;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 <code>0</code>.
* De første bitene i den første byten i en sekvens på flere byte angir lengden på sekvensen. Disse er <code>110</code> for to-bytes sekvenser, <code>1110</code> for tre-bytes sekvenser, og så videre.
* De påfølgende byte i en sekvens på flere byte har <code>10</code> 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 [[komprimering|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 '?', '&#65533;')
# 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å [[dekoder|dekodes]], men eldre standarder krevde bare en advarsel, og mange enklere [[dekoder]]e tolker dem som gyldige data. Sekvenser av denne typen er blitt brukt til å omgå sikkerhetsrutiner i profilerte produkter, for eksempel Microsofts [[IIS]]-web[[server]].

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 
* W3C UTF-8-validerer og en uoffisiell variant.
* UTF-8 and Debian og Linux UTF-8 How-To.