UTF -16 - UTF-16

UTF-16

De første 2 16 Unicode -kodepunkter. Striben med fast grå nær bunden er surrogathalvdelene, der bruges af UTF-16 (det hvide område under striben er det private brugsområde )
Sprog)	International
Standard	Unicode Standard
Klassifikation	Unicode Transformation Format , kodning med variabel bredde
Strækker sig	UCS-2
Transformerer / koder	ISO 10646 ( Unicode )
v t e

UTF-16 ( 16-bit Unicode Transformation Format) er en karakter, der koder stand til at kode alle 1,112,064 gyldige karakter kodepunkter af Unicode (i virkeligheden denne række kodepunkter er dikteret af udformningen af UTF-16). Kodningen er variabel længde , da kodepunkter er kodet med en eller to 16-bit kodenheder . UTF-16 opstod fra en tidligere forældet 16-bit kodning med fast bredde, nu kendt som UCS-2 (for 2-byte Universal Character Set), når det blev klart, at der var brug for mere end 2 ¹⁶ (65.536) kodepunkter.

UTF-16 bruges internt af systemer som Microsoft Windows , programmeringssproget Java og JavaScript /ECMAScript. Det bruges også ofte til almindelig tekst og til tekstbehandlingsdatafiler på Microsoft Windows. Det bruges sjældent til filer på Unix-lignende systemer. Fra maj 2019 vendte Microsoft sit forløb ud med kun at understrege UTF-16 for Unicode; til Windows-applikationer anbefaler og understøtter Microsoft UTF-8 (f.eks. til Universal Windows Platform (UWP) apps.).

UTF-16 er den eneste webkodning, der er inkompatibel med ASCII , og vinder aldrig popularitet på nettet, hvor den bruges af under 0,002% (lidt over 1 tusindedel af 1 procent) af websider. UTF-8 bruges til sammenligning af 97% af alle websider. Den Web Hypertext Application Technology Working Group (WHATWG) betragter UTF-8 "den obligatoriske kodning for alle [tekst]", og at af sikkerhedsmæssige årsager browser applikationer bør ikke bruge UTF-16.

Historie

I slutningen af ​​1980'erne begyndte arbejdet med at udvikle en ensartet kodning for et "Universal Character Set" ( UCS ), der ville erstatte tidligere sprogspecifikke kodninger med ét koordineret system. Målet var at inkludere alle nødvendige tegn fra de fleste af verdens sprog samt symboler fra tekniske områder som videnskab, matematik og musik. Den oprindelige idé var at erstatte de typiske 256-tegnskodninger, som krævede 1 byte pr. Tegn, med en kodning ved hjælp af 65.536 (2 ¹⁶ ) værdier, hvilket ville kræve 2 bytes (16 bit) pr. Tegn.

To grupper arbejdede parallelt med dette, ISO/IEC JTC 1/SC 2 og Unicode Consortium , sidstnævnte repræsenterede hovedsageligt producenter af computerudstyr. De to grupper forsøgte at synkronisere deres karaktertildelinger, så de udviklende kodninger ville være indbyrdes kompatible. Den tidlige 2-byte-kodning blev oprindeligt kaldt "Unicode", men kaldes nu "UCS-2".

Da det blev mere og mere klart, at 2 ¹⁶ tegn ikke ville være tilstrækkeligt, introducerede IEEE et større 31-bit mellemrum og en kodning ( UCS-4 ), der ville kræve 4 bytes pr. Tegn. Dette blev modstået af Unicode-konsortiet , både fordi 4 bytes pr. Karakter spildte meget hukommelse og diskplads, og fordi nogle producenter allerede var stærkt investeret i 2-byte pr. Karakter-teknologi. UTF-16-kodningsskemaet blev udviklet som et kompromis og introduceret med version 2.0 af Unicode-standarden i juli 1996. Det er fuldstændigt specificeret i RFC 2781, udgivet i 2000 af IETF .

I UTF-16-kodningen er kodepunkter mindre end 2 ¹⁶ kodet med en enkelt 16-bit kodeenhed svarende til den numeriske værdi af kodepunktet, som i den ældre UCS-2. De nyere kodepunkter større end eller lig med 2 ¹⁶ kodes af en sammensat værdi ved hjælp af to 16-bit kodenheder. Disse to 16-bit kodenheder er valgt fra UTF-16 surrogatområdet 0xD800–0xDFFF, som ikke tidligere var blevet tildelt tegn. Værdier i dette område bruges ikke som tegn, og UTF-16 giver ingen lovlig måde at kode dem som individuelle kodepunkter. En UTF-16-strøm består derfor af enkelte 16-bit kodepunkter uden for surrogatområdet for kodepunkter i Basic Multilingual Plane (BMP) og par af 16-bit værdier inden for surrogatområdet for kodepunkter over BMP.

UTF-16 er specificeret i de nyeste versioner af både den internationale standard ISO/IEC 10646 og Unicode-standarden. "UCS-2 skal nu betragtes som forældet. Det refererer ikke længere til en kodningsform i hverken 10646 eller Unicode-standarden." Der er ingen planer fra 2021 om at forlænge UTF-16 til at understøtte et større antal kodepunkter eller kodepunkterne erstattet af surrogater, da dette ville krænke Unicode-stabilitetspolitikken med hensyn til generelle kategoripunkter eller surrogatkodepunkter. (Enhver ordning, der forbliver en selvsynkroniserende kode, ville kræve tildeling af mindst et BMP-kodepunkt for at starte en sekvens. Ændring af formålet med et kodepunkt er ikke tilladt.)

Beskrivelse

Hvert Unicode-kodepunkt er kodet enten som en eller to 16-bit kodeenheder . Hvordan disse 16-bit koder gemmes som bytes, afhænger derefter af tekstfilens eller kommunikationsprotokollens ' endelighed '.

Et "tegn" kan have brug for fra så få som to bytes til fjorten eller endda flere bytes for at blive registreret. For eksempel tager et emoji -flagtegn 8 bytes, da det er "konstrueret ud fra et par Unicode -skalarværdier" (og disse værdier er uden for BMP og kræver 4 bytes hver).

U+0000 til U+D7FF og U+E000 til U+FFFF

Både UTF-16 og UCS-2 koder kodepunkter i dette område som enkelte 16-bit kodenheder, der numerisk er lig med de tilsvarende kodepunkter. Disse kodepunkter i Basic Multilingual Plane (BMP) er de eneste kodepunkter, der kan repræsenteres i UCS-2. Fra Unicode 9.0 falder nogle moderne ikke-latinske asiatiske, mellemøstlige og afrikanske scripts uden for dette område, ligesom de fleste emoji- karakterer.

Kodepunkter fra U+010000 til U+10FFFF

Kodepunkter fra de andre fly (kaldet Supplementary Planes ) er kodet som to 16-bit kodeenheder kaldet et surrogatpar efter følgende skema:

• 0x10000 trækkes fra kodepunktet (U) og efterlader et 20-bit tal (U ') i hex-nummerområdet 0x00000–0xFFFFF. Bemærk til disse formål, U er defineret til ikke at være større end 0x10FFFF.
• De ti høje bits (i området 0x000–0x3FF) tilføjes til 0xD800 for at give den første 16-bit kodeenhed eller høj surrogat (W1) , som vil være i området 0xD800–0xDBFF .
• De lave ti bits (også i området 0x000–0x3FF) tilføjes til 0xDC00 for at give den anden 16-bit kodeenhed eller lavt surrogat (W2) , som vil være i området 0xDC00–0xDFFF .

Visuelt illustreret ser fordelingen af U ' mellem W1 og W2 sådan ud:

U' = yyyyyyyyyyxxxxxxxxxx  // U - 0x10000
W1 = 110110yyyyyyyyyy      // 0xD800 + yyyyyyyyyy
W2 = 110111xxxxxxxxxx      // 0xDC00 + xxxxxxxxxx

Den høje surrogat og den lave surrogat er også kendt som henholdsvis "førende" og "efterfølgende" surrogater, analoge med de førende og efterfølgende bytes i UTF-8.

Da intervallerne for de høje surrogater ( 0xD800–0xDBFF ), lave surrogater ( 0xDC00–0xDFFF ) og gyldige BMP -tegn (0x0000–0xD7FF, 0xE000–0xFFFF) er uensartede , er det ikke muligt for en surrogat at matche et BMP -tegn, eller at to tilstødende kodeenheder ligner et lovligt surrogatpar . Dette forenkler søgninger meget. Det betyder også, at UTF-16 synkroniserer sig selv med 16-bit ord: om en kodeenhed starter et tegn, kan bestemmes uden at undersøge tidligere kodeenheder (dvs. typen af kodeenhed kan bestemmes af de værdiområder, hvori det falder). UTF-8 deler disse fordele, men mange tidligere multi-byte-kodningsordninger (såsom Shift JIS og andre asiatiske multi-byte-kodninger) tillod ikke entydig søgning og kunne kun synkroniseres ved genanalyse fra strengens start (UTF -16 synkroniserer ikke selv, hvis en byte går tabt, eller hvis traversal starter med en tilfældig byte).

Fordi de mest almindeligt anvendte tegn alle er i BMP, bliver håndtering af surrogatpar ofte ikke testet grundigt. Dette fører til vedvarende fejl og potentielle sikkerhedshuller, selv i populær og gennemgået applikationssoftware (f.eks. CVE - 2008-2938 , CVE- 2012-2135 ).

De supplerende Planes indeholde emoji , historiske scripts, mindre anvendte symboler, mindre anvendte kinesiske ideografer osv Da kodningen af supplerende Planes indeholder 20 betydende bits (10 af 16 bits i hver af de høje og lave surrogater ), 2 ²⁰ kodepunkter kan kodes, opdelt i 16 fly med 2 ¹⁶ kodepunkter hver. Inklusiv det separat håndterede Basic Flersprogede fly er der i alt 17 fly.

U+D800 til U+DFFF

Unicode-standarden forbeholder disse kodepunktværdier permanent til UTF-16-kodning af høje og lave surrogater, og de vil aldrig blive tildelt et tegn, så der bør ikke være nogen grund til at kode dem. Den officielle Unicode-standard siger, at ingen UTF-formularer, inklusive UTF-16, kan kode disse kodepunkter.

UCS-2, UTF-8 og UTF-32 kan imidlertid kode disse kodepunkter på trivielle og indlysende måder, og en stor mængde software gør det, selvom standarden angiver, at sådanne arrangementer skal behandles som kodningsfejl.

Det er muligt utvetydigt at kode et uparret surrogat (et højt surrogatkodepunkt, der ikke efterfølges af et lavt eller et lavt, der ikke er forudgået af et højt) i formatet UTF-16 ved at bruge en kodeenhed svarende til kodepunktet . Resultatet er ikke gyldigt UTF-16, men størstedelen af ​​UTF-16 encoder- og dekoderimplementeringer gør dette derefter, når der oversættes mellem kodninger. Windows tillader uparrede surrogater i filnavne og andre steder, hvilket generelt betyder, at de skal understøttes af software på trods af deres udelukkelse fra Unicode -standarden.

Eksempler

For at kode U+10437 (𐐷) til UTF-16:

• Træk 0x10000 fra kodepunktet og lad 0x0437 stå.
• For den høje surrogat skal du skifte til højre med 10 (divider med 0x400), derefter tilføje 0xD800, hvilket resulterer i 0x0001 + 0xD800 = 0xD801.
• For den lave surrogat, tag de lave 10 bits (resten af ​​dividere med 0x400), tilføj derefter 0xDC00, hvilket resulterer i 0x0037 + 0xDC00 = 0xDC37.

For at afkode U+10437 (𐐷) fra UTF-16:

• Tag den høje surrogat (0xD801) og træk 0xD800, multiplicér derefter med 0x400, hvilket resulterer i 0x0001 × 0x400 = 0x0400.
• Tag det lave surrogat (0xDC37) og træk 0xDC00, hvilket resulterer i 0x37.
• Tilføj disse to resultater sammen (0x0437), og tilføj til sidst 0x10000 for at få det endelige afkodede UTF-32-kodepunkt, 0x10437.

Følgende tabel opsummerer denne konvertering såvel som andre. Farverne angiver, hvordan bits fra kodepunktet fordeles mellem UTF-16 bytes. Yderligere bits tilføjet af UTF-16-kodningsprocessen er vist i sort.

Byte-ordre kodningsordninger

UTF-16 og UCS-2 producerer en sekvens af 16-bit kodenheder. Da de fleste kommunikations- og lagringsprotokoller er defineret for bytes, og hver enhed dermed tager to 8-bit bytes, kan rækkefølgen af ​​bytes afhænge af computerarkitekturens endianness (byte-rækkefølge).

For at hjælpe med at genkende bytenes rækkefølge for kodeenheder tillader UTF-16 et Byte Order Mark (BOM), et kodepunkt med værdien U+FEFF, at gå forud for den første faktiske kodede værdi. (U+FEFF er det usynlige nulbredde ikke-brydende rum /ZWNBSP-tegn.) Hvis dekoderens endiske arkitektur matcher encoderens, registrerer dekoderen 0xFEFF-værdien, men en modstående endian dekoder tolker styklisten som ikke-tegnværdi U+FFFE forbeholdt dette formål. Dette forkerte resultat giver et tip om at udføre byte-swapping for de resterende værdier.

Hvis styklisten mangler, anbefaler RFC 2781, at big-endian-kodning antages. I praksis på grund af at Windows ved hjælp af lille-endian-ordre som standard antager mange applikationer lidt-endisk kodning. Det er også pålideligt at opdage endianness ved at kigge efter nullbytes, under forudsætning af at tegn mindre end U+0100 er meget almindelige. Hvis flere lige bytes (startende ved 0) er nul, så er det big-endian.

Standarden gør det også muligt at angive byteordren eksplicit ved at angive UTF-16BE eller UTF-16LE som kodningstype. Når byteordren udtrykkeligt er angivet på denne måde, skal en stykliste specifikt ikke forberedes til teksten, og en U+FEFF i begyndelsen skal håndteres som et ZWNBSP -tegn. De fleste applikationer ignorerer en stykliste i alle tilfælde på trods af denne regel.

For internetprotokoller har IANA godkendt "UTF-16", "UTF-16BE" og "UTF-16LE" som navnene på disse kodninger (navnene er store og små ufølsomme). Den aliaser UTF_16 eller UTF-16 kan være meningsfuldt i nogle programmeringssprog eller softwareprogrammer, men de er ikke standard navne i internetprotokoller.

Lignende betegnelser, UCS-2BE og UCS-2LE , bruges til at vise versioner af UCS-2 .

Anvendelse

UTF-16 bruges til tekst i OS API'en for alle i øjeblikket understøttede versioner af Microsoft Windows (og inkluderer mindst alle siden Windows CE / 2000 / XP / 2003 / Vista / 7 ) inklusive Windows 10 . I Windows XP er der ikke noget kodepunkt over U+FFFF i enhver skrifttype, der leveres med Windows til europæiske sprog. Ældre Windows NT- systemer (før Windows 2000) understøtter kun UCS-2. Filer og netværksdata har en tendens til at være en blanding af UTF-16, UTF-8 og ældre byte-kodninger.

Selvom der har været noget UTF-8-understøttelse til selv Windows XP, blev det forbedret (især muligheden for at navngive en fil ved hjælp af UTF-8) i Windows 10 insider build 17035 og opdateringen fra april 2018, og fra maj 2019 anbefaler Microsoft software brug den i stedet for UTF-16.

Den IBM i operativsystemet betegner CCSID ( kode side ) 13.488 til UCS-2 kodning og CCSID 1200 for UTF-16-kodning, selvom systemet behandler dem begge som UTF-16.

UTF-16 bruges af Qualcomm BREW- operativsystemerne; de .NET miljøer; og Qt cross-platform grafisk widget-værktøjskasse .

Symbian OS, der bruges i Nokia S60-håndsæt og Sony Ericsson UIQ- håndsæt, bruger UCS-2. iPhone- håndsæt bruger UTF-16 til Short Message Service i stedet for UCS-2 beskrevet i 3GPP TS 23.038 ( GSM ) og IS-637 ( CDMA ) standarder.

Det Joliet-filsystemet , der anvendes i CD-ROM medier, koder filnavne hjælp UCS-2BE (op til tres-fire Unicode-tegn pr filnavn).

Den Python sprog miljø officielt kun bruger UCS-2 internt siden version 2.0, men den UTF-8-dekoder til "Unicode" producerer korrekt UTF-16. Siden Python 2.2 understøttes "brede" builds af Unicode, der i stedet bruger UTF-32; disse bruges primært på Linux. Python 3.3 bruger aldrig mere UTF-16, i stedet vælges en kodning, der giver den mest kompakte repræsentation for den givne streng fra ASCII/Latin-1, UCS-2 og UTF-32.

Java brugte oprindeligt UCS-2 og tilføjede UTF-16 supplerende tegnstøtte i J2SE 5.0 .

JavaScript kan bruge UCS-2 eller UTF-16. Fra og med ES2015 er der tilføjet strengmetoder og regulære udtryksflag til sproget, der tillader håndtering af strenge fra et kodningsagnostisk perspektiv.

På mange sprog har citerede strenge brug for en ny syntaks for at citere ikke-BMP-tegn, da "\uXXXX"syntaksen i C-stil eksplicit begrænser sig til 4 hex-cifre. De følgende eksempler illustrerer syntaksen for ikke-BMP-tegnet "𝄞" (U+1D11E, MUSICAL SYMBOL G CLEF). Det mest almindelige (brugt af C ++ , C# , D og flere andre sprog) er at bruge et stort U med 8 hex-cifre som f.eks "\U0001D11E". I Java 7 regulære udtryk, ICU og Perl skal syntaksen "\x{1D11E}"bruges; På samme måde er Escape -formatet i ECMAScript 2015 (JavaScript) "\u{1D11E}". I mange andre tilfælde (f.eks. Java uden for regulære udtryk) er den eneste måde at få ikke-BMP-tegn at indtaste surrogathalvdelene individuelt, for eksempel: "\uD834\uDD1E"for U+1D11E.

Strengimplementeringer baseret på UTF-16 definerer typisk strengens længder og tillader indeksering i form af disse 16-bit kodenheder , ikke hvad angår kodepunkter. Hverken kodepunkter eller kodeenheder svarer til noget, en slutbruger måske genkender som et "tegn"; de ting, brugerne identificerer som tegn, kan generelt bestå af et basiskodepunkt og en sekvens af kombinationstegn (eller kan være en sekvens af kodepunkter af anden art, f.eks. Hangul -sammenhængende jamos) - Unicode refererer til denne konstruktion som et grafeme klynge  - og som sådan skal applikationer, der beskæftiger sig med Unicode -strenge, uanset kodning, klare det faktum, at dette begrænser deres evne til vilkårligt at opdele og kombinere strenge.

UCS-2 understøttes også af PHP- sproget og MySQL.

Swift , version 5, Apples foretrukne applikationssprog, skiftede fra UTF-16 til UTF-8 som den foretrukne kodning.

Se også

• Sammenligning af Unicode -kodninger
• Fly (Unicode)
• UTF-8
• UTF-32

Noter

Referencer

eksterne links

• En meget kort algoritme til bestemmelse af surrogatparret for ethvert kodepunkt
• Unicode teknisk note #12: UTF-16 til behandling
• Unicode FAQ: Hvad er forskellen mellem UCS-2 og UTF-16?
• Unicode -karakternavnindeks
• RFC  2781 : UTF-16, en kodning af ISO 10646
• java.lang.Strengdokumentation, der diskuterer surrogathåndtering