UTF-16 – Wikipedia

Den här artikeln behöver fler eller bättre källhänvisningar för att kunna verifieras. (2015-05) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

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]}

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 (på nätet har sådana tecken blivit vanligare efter 2015 eftersom emojis lagras så).

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. Man behöver inte ändra så mycket för att införa UTF-8 i ett äldre program som inte stödjer Unicode. För att införa UTF-16 i ett befintligt program utan Unicode måste all kod som hanterar text skrivas om. Om man vill slippa skriva om de delar som klarar sig med ASCII, behöver många funktionsanrop dubbleras, vilket gjordes med Windows när Unicode infördes där på 1990-talet.

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, förval i västeuropeiska Windows-versioner, 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.

Emojis som blivit populära i sociala medier efter 2015 lagras bland annat i intervallet U+1F000-1F9FF. Man kan ibland se att när ett långt inlägg förkortas för att inte ta så mycket plats syns en felindikering eftersom det 16-bitstalet förkortats bort. När man ber att få läsa hela syns en emoji.

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: Emojin 🌴 (palmträd) har i Unicode [1] kodpunkten U+1F334 vilket blir D83C DF34 (D800+03C DC00+334) i UTF-16.

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

• Vad är Unicode?, senast läst 2014-11-02