UTF-16

Från Wikipedia
Hoppa till: navigering, sök

UTF-16 (16 bitars unicode transformationsformat) är inom datatekniken en längdvarierande teckenkodning som används för att representera Unicodetext som sekvenser av dubbel-oktetter (16-bitstal). Den är en utvidgning av UCS-2.

UTF-16 är standardiserad inom Unicode och ISO/IEC 10646. Den är såtillvida kompatibel med UCS-2, att all UCS-2-data också är UTF-16-data. Vissa kodvärden har reserverats för att, i par, kunna referera till tecken vars kodpunkter är större än 65535 (U+FFFF), så kallade supplementära tecken. Ursprungligen planerades Unicode klara sig med 16 bitar och UCS-2 var Unicode utan transformation. Det finns dock så många kinesiska tecken om alla ovanliga räknas med, att fler bitar behövdes.[källa behövs]

Användning internt i program[redigera | redigera wikitext]

Som intern kodning i program är kodningen direkt baserad på 16-bitarstal. Kodningen refereras då till som en CEF, Character Encoding Format. Huruvida dessa tal är representerade som "big-endian" eller "little-endian" är då en helt intern sak på låg nivå. I programmen behandlar man dem som 16-bitarstal. Eftersom tecken över 0xFFFF är sällan använda (till exempel utdöda språk och ovanliga kinesiska tecken), tar många programvaruföretag sig friheten att bara stödja tecken upp till 0xFFFF (UCS-2). Egentligen ska man använda UTF-16-algoritmen för högre teckenkoder om man lagrar 16-bits-koder.

Användning i filer och datakommunikation[redigera | redigera wikitext]

Då kodningen UTF-16 används i filer, datakommunikation eller andra sammanhang där mer än ett program kan vara inblandat måste man i allmänhet serialisera 16-bitars-talen till en följd av 8-bitars-tal, då all datakommunikation idag är baserad på oktetter (8-bitars bytes). Kodningen kallas då en CES, Character Encoding Scheme. Eventuell ytterligare serialisering, till till exempel fyra bitar eller en bit i taget, plus extra bitar för felkorrigering, med mera sker på lägre nivå.

Serialisering till oktetter kan vara antingen big-endian (mest signifikanta oktetten först), även kallad "network byte order", eller little-endian (minst signifikanta oktetten först).

Som extern kodning, och registrerade av IANA, finns det därför tre kodningar: UTF-16BE (big-endian), UTF-16LE (little-endian). Big-endian är att föredra, då detta är den konventionella "network byte order", och formellt sett den oktettordning som ISO/IEC 10646 föreskriver. Little-endian är vanligare, eftersom Windows körs på processorer med little-endian. Unicode tillåter dock även formellt båda serialiseringarna. Också UTF-16 (utan BE eller LE) är registrerad som en charset av IANA. Det är då big-endian, utom om filen eller dataströmmen börjar med en byte-ordningsindikation (BOM, byte order mark, U+FEFF), som anger motsatsen. BOM ingår då inte i text-innehållet i filen, och skall tas bort vid deserialisering.

UTF-16(BE|LE) kan användas för webbsidor och andra filer, både lokalt och publikt. För e-post används UTF-8 istället (tillsammans med ESMTP/8BITMIME, quoted printable eller motsvarande). UTF-16 innehåller förbjudna oktetter som ändå måste kodas om, medan UTF-8 ofta kan överföras som sådan. Man ville hålla nere antalet olika kodningar ett e-postprogram måste klara för att hantera enkel text.

I det mest använda programmet för rena textfiler, Windows Notepad,[källa behövs] kan man välja kodning i "spara som"-menyn. En av dem kallas "Unicode" och är UTF-16LE. Det finns möjlighet att välja UTF-16BE, UTF-8 eller ANSI (8-bitars, default i västeuropeiska windowsversioner, egentligen används i detta fall Windows-1252) istället. Windows Notepad sparar en BOM (byte order mark) först om det är Unicode, och om filen innehåller till exempel en HTML-sida antas den av vissa webbläsare vara UTF-16, oberoende av vad som står i HTTP-huvudet (som borde vara utslagsgivande), HTML-huvudet eller webbläsarens inställningar.

Unix-liknande operativsystem (såsom GNU/Linux) brukar använda UTF-8 för Unicode och brukar inte spara en BOM först, då tecknet inte tillåts i vissa filer (de första tecknen, eller tecken på visst ställe räknat från början, kan avgöra hur filen skall behandlas). UTF-16 i filer i Linux är ovanligt och finns främst i filer skapade i eller för Windows-program (till exempel MS Office-filer).

Beskrivning av kodningen[redigera | redigera wikitext]

För unicodetecken inom intervallet U+0000–U+FFFF kodar man 16 bitar oförändrat. Intervallet U+D800–U+DFFF är dock inte tillåtna att använda ensamma för skrivbara tecken. De är reserverade för att hantera tecken i intervallet U+10000–U+10FFFF enligt UTF-16:s algoritm (se nedan). De kallas också surrogatkodpunkter. Också vissa andra intervall är reserverade för annat än tecken.

För unicodetecken inom intervallet U+10000–U+10FFFF får man två 16-bitstal på följande sätt: Man subtraherar först 10000 (hex). Sedan tar man de bitar som är ovanför de 10 lägsta bitarna och adderar D800 (hex) vilket blir det första 16-bitstalet. Efter det tar man de 10 lägsta bitarna och adderar DC00 (hex) vilket blir det andra 16-bitstalet.

Till exempel: Det första tecknet på det gamla gotiska alfabetet (som finns i få typsnitt: 𐌰) har i Unicode [1] kodpunkten U+10330 vilket blir D800 DF30 (D800+000 DC00+330) i UTF-16. Ett annat exempel är från Unicodes notskrift-koder (musik) där G-klaven har koden U+1D11E vilket blir D834 DD1E (D800+034 DC00+11E) i UTF-16. Windows stödde 2006 inga tecken över U+10000.

Genom att de lägre kodpunkterna lagras som sådana kommer tecken i intervallet U+0000–U+00FF att inledas (eller avslutas, vid UTF-16LE) med en NULL-oktett, som har speciell betydelse i många sammanhang. Endera oktetten kan också ha andra värden som motsvarar kontrollkoder eller specialtecken i ASCII. Därför är kodningen inte lämplig i sammanhang där filen eller dataströmmen kan komma att tolkas som ASCII (som tidigare varit helt dominerande) eller UTF-8. Data kodat som ASCII eller UTF-8 kan också misstas för UTF-16 (de i UTF-16 förbjudna oktettparen är inte vanliga i t.ex. engelsk text med dessa kodningar).