Kodning med variabel bredd
En kodning med variabel bredd är en typ av teckenkodningsschema där koder av olika längd används för att koda en teckenuppsättning (en repertoar av symboler) för representation, vanligtvis i en dator . De vanligaste kodningarna med variabel bredd är multibyte-kodningar , som använder olika antal byte ( oktetter ) för att koda olika tecken. (Vissa författare, särskilt i Microsofts dokumentation, använder termen multibyte-teckenuppsättning, vilket är en felaktig benämning , eftersom representationsstorleken är ett attribut för kodningen, inte för teckenuppsättningen.)
Tidiga kodningar med variabel bredd med mindre än en byte per tecken användes ibland för att packa engelsk text till färre byte i äventyrsspel för tidiga mikrodatorer . Men diskar (som till skillnad från band tillät slumpmässig åtkomst så att text kan laddas på begäran), har ökningar i datorminne och allmänna komprimeringsalgoritmer gjort sådana trick i stort sett föråldrade.
Multibyte-kodningar är vanligtvis resultatet av ett behov av att öka antalet tecken som kan kodas utan att bryta bakåtkompatibiliteten med en befintlig begränsning. Till exempel, med en byte (8 bitar) per tecken, kan man koda 256 möjliga tecken; för att koda mer än 256 tecken skulle det självklara valet vara att använda två eller fler byte per kodningsenhet, två byte (16 bitar) skulle tillåta 65 536 möjliga tecken, men en sådan förändring skulle bryta kompatibiliteten med befintliga system och kanske inte vara genomförbart överhuvudtaget.
Allmän struktur
Eftersom syftet med ett multibyte-kodningssystem är att minimera ändringar av befintlig applikationsprogramvara, måste vissa tecken behålla sina redan existerande enenhetskoder, även medan andra tecken har flera enheter i sina koder. Resultatet är att det finns tre sorters enheter i en kodning med variabel bredd: singletons , som består av en enda enhet, lead units , som kommer först i en multiunit-sekvens, och trail-enheter , som kommer efteråt i en multiunit-sekvens. Programvara för inmatning och visning behöver uppenbarligen känna till strukturen för multibyte-kodningsschemat, men annan programvara behöver i allmänhet inte veta om ett par byte representerar två separata tecken eller bara ett tecken.
Till exempel är den fyra teckensträngen " I♥NY " kodad i UTF-8 så här (visas som hexadecimala bytevärden): 49 E2 99 A5 4E 59 . Av de sex enheterna i den sekvensen är 49, 4E och 59 singletons (för I, N och Y ), E2 är en ledande enhet och 99 och A5 är spårenheter. Hjärtsymbolen representeras av kombinationen av huvudenheten och de två spårenheterna.
UTF-8 gör det enkelt för ett program att identifiera de tre typerna av enheter, eftersom de faller in i separata värdeområden. Äldre kodningar med variabel bredd är vanligtvis inte lika väl utformade, eftersom intervallen kan överlappa varandra. En textbehandlingsapplikation som hanterar kodningen med variabel bredd måste sedan skanna texten från början av alla definitiva sekvenser för att identifiera de olika enheterna och tolka texten korrekt. I sådana kodningar riskerar man att stöta på falska positiva resultat när man söker efter en sträng i mitten av texten. Till exempel, om de hexadecimala värdena DE, DF, E0 och E1 alla kan vara antingen ledningsenheter eller spårenheter, kan en sökning efter tvåenhetssekvensen DF E0 ge ett falskt positivt resultat i sekvensen DE DF E0 E1, vilket består av två på varandra följande två-enhetssekvenser. Det finns också risken att en enstaka skadad eller förlorad enhet kan göra hela tolkningen av ett stort antal flerenhetssekvenser felaktig. I en kodning med variabel bredd där alla tre typerna av enheter är åtskilda, fungerar strängsökning alltid utan falska positiva, och (förutsatt att avkodaren är välskriven) förstör korruptionen eller förlusten av en enhet endast ett tecken.
CJK multibyte-kodningar
Den första användningen av multibyte-kodningar var för kodning av kinesiska, japanska och koreanska, som har stora teckenuppsättningar långt över 256 tecken. Först var kodningen begränsad till gränsen på 7 bitar. ISO -2022-JP-, ISO-2022-CN- och ISO-2022-KR-kodningarna använde intervallet 21–7E (hexadecimalt) för både ledningsenheter och spårenheter, och markerade dem av från singletons genom att använda ISO 2022 escape-sekvenser för att växla mellan enkelbyte och multibyte läge. Totalt 8 836 (94×94) tecken kunde kodas först, och ytterligare uppsättningar av 94×94 tecken med växling. ISO 2022-kodningsscheman för CJK används fortfarande på Internet. Den tillståndsfulla karaktären hos dessa kodningar och den stora överlappningen gör dem mycket besvärliga att bearbeta.
På Unix -plattformar ersattes ISO 2022 7-bitars kodningar av en uppsättning 8-bitars kodningsscheman, den utökade Unix-koden: EUC-JP, EUC-CN och EUC-KR. Istället för att skilja mellan multienhetssekvenserna och singletonerna med escape-sekvenser, vilket gjorde kodningarna stateful, markerades multiunit-sekvenser genom att ha den mest signifikanta bituppsättningen, det vill säga vara i intervallet 80–FF (hexadecimal), medan singletonerna var enbart i intervallet 00–7F. Ledenheterna och spårenheterna låg i intervallet A1 till FE (hexadecimal), det vill säga samma räckvidd som deras räckvidd i ISO 2022-kodningarna, men med den höga biten inställd på 1. Dessa kodningar var ganska lätta att arbeta med förutsatt att alla dina avgränsare var ASCII- tecken och du undvek att trunkera strängar till fasta längder, men ett avbrott i mitten av ett multibyte-tecken kan fortfarande orsaka stor skada.
På PC ( DOS och Microsoft Windows- plattformar) etablerades två kodningar för japanska och traditionell kinesiska där alla singlar, ledningsenheter och spårenheter överlappade: Shift-JIS respektive Big5 . I Shift-JIS hade ledningsenheter intervallet 81–9F och E0–FC, spårenheter hade intervallet 40–7E och 80–FC, och singletons hade intervallet 21–7E och A1–DF. I Big5 hade blyenheter intervallet A1–FE, spårenheter hade intervallet 40–7E och A1–FE, och singlar hade intervallet 21–7E (alla värden i hexadecimal). Denna överlappning gjorde återigen bearbetningen svår, även om åtminstone de flesta av symbolerna hade unika bytevärden (även om det omvända snedstrecket konstigt nog inte har det).
Unicode-kodningar med variabel bredd
Unicode - standarden har två kodningar med variabel bredd: UTF-8 och UTF-16 (den har också en kodning med fast bredd, UTF-32 ). Ursprungligen var både Unicode- och ISO 10646- standarderna tänkta att ha fast bredd, med Unicode som 16-bitars och ISO 10646 som 32-bitars. [ Citat behövs ] ISO 10646 gav en kodning med variabel bredd som kallas UTF-1 , där singletons hade intervallet 00–9F, leder enheter intervallet A0–FF och spårenheter intervallen A0–FF och 21–7E. På grund av denna dåliga design, liknande Shift JIS och Big5 i dess överlappning av värden, övergav uppfinnarna av operativsystemet Plan 9 , de första att implementera Unicode genomgående, det och ersatte det med en mycket bättre designad kodning med variabel bredd för Unicode : UTF-8, där singlar har intervallet 00–7F, blyenheter har intervallet C0–FD (nu faktiskt C2–F4, för att undvika för långa sekvenser och för att bibehålla synkronism med kodningskapaciteten för UTF-16; se UTF: n -8 artikel), och spårenheter har intervallet 80–BF. Den ledande enheten berättar också hur många spårenheter som följer: en efter C2–DF, två efter E0–EF och tre efter F0–F4.
UTF-16 utformades för att bryta sig fri från gränsen på 65 536 tecken i den ursprungliga Unicode (1.x) utan att bryta kompatibiliteten med 16-bitars kodning. I UTF-16 har singlar intervallet 0000–D7FF (55 296 kodpunkter) och E000–FFFF (8192 kodpunkter, totalt 63 488), ledande enheter intervallet D800–DBFF (1024 kodpunkter) och spårenheter intervallet DC00– DFFF (1024 kodpunkter, 2048 totalt). Lednings- och spårenheterna, som kallas höga surrogat respektive låga surrogat, i Unicode-terminologi, kartlägger 1024×1024 eller 1 048 576 tilläggstecken, vilket gör 1 112 064 (63 488 BMP-kodpunkter + 1 048 576 kodpunkter som kan ersättas av parade låga kodpunkter) , eller skalära värden i Unicode-språk (surrogat går inte att koda).
Se även
- wchar_t breda tecken
- Lotus Multi-Byte Character Set (LMBCS)
- Triple-Byte Character Set (TBCS)
- Double-Byte Character Set (DBCS)
- Single-byte Character Set (SBCS)
