UTF-16

Från Wikipedia

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

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.

För många nyare programspråk, såsom Java och C#, gäller att textsträngar lagras under körningen som UTF-16. Om man vill använda UTF-8 eller andra kodningar, finns det stöd för konvertering. För många äldre programspråk såsom C, är utökad ASCII (8-bitskodning) standard, och Unicode-stöd är tillagt senare i språken. För dessa språk gäller att UTF-8 fungerar bättre, eftersom UTF-8 fungerar som en utökad ASCII.

Användning i filer och datakommunikation

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. Om de två första oktetterna är 0xFE,0xFF har vi big-endian, och om de är 0xFF,0xFE little-endian, med tanke på att tecknet U+FEFF är BOM och U+FFEF är ett förbjudet tecken.

UTF-16 (BE eller LE) kan användas för webbsidor och andra filer, både lokalt och publikt, om också UTF-8 föredras för webbsidor. För e-post används UTF-8 istället (tillsammans med ESMTP/8BIT, quoted printable eller motsvarande). Man ville hålla nere antalet olika kodningar ett e-postprogram måste klara för att hantera enkel text; UTF-16 innehåller förbjudna oktetter som ändå måste kodas om, medan UTF-8 ofta kan överföras som sådan. UTF-8 är också mer bakåtkompatibelt, så att UTF8-kodad engelskspråkig text (och i någon mån t.o.m. t.ex. svenskspråkig) ofta fungerar i äldre epostläsare som bara stödjer ASCII, vilket inte gäller för UTF16-kodad text.

I det mest spridda programmet för rena textfiler, Windows Notepad, 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). På grund av problemen med UTF-16 och tack vare bakåtkompatibiliteten från UTF-8 till ASCII, så har UTF-8 blivit det ledande systemet för Unicode i filer på nätet, i alla fall i dokumentspråk som HTML och XML, medan UTF-16 är mindre använt.

Beskrivning av kodningen

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

Källor