En annan cykel: vi lagrar Unicode-strängar 30-60% mer kompakt än UTF-8

Om du är en utvecklare och står inför uppgiften att välja en kodning, så kommer Unicode nästan alltid att vara rätt lösning. Den specifika representationsmetoden beror på sammanhanget, men oftast finns det ett universellt svar även här - UTF-8. Det som är bra med det är att det låter dig använda alla Unicode-tecken utan att behöva spendera pengar för mycket många byte i de flesta fall. Det är sant, för språk som använder mer än bara det latinska alfabetet, är "inte för mycket" åtminstone två byte per tecken. Kan vi bli bättre utan att återgå till förhistoriska kodningar som begränsar oss till bara 256 tillgängliga tecken?

Nedan föreslår jag att du ska bekanta dig med mitt försök att svara på denna fråga och implementera en relativt enkel algoritm som låter dig lagra rader på de flesta språk i världen utan att lägga till redundansen som finns i UTF-8.

Varning. Jag kommer omedelbart att göra några viktiga reservationer: den beskrivna lösningen erbjuds inte som en universell ersättning för UTF-8, det är bara lämpligt i en smal lista av fall (mer om dem nedan), och i inget fall bör det användas för att interagera med tredje parts API:er (som inte ens vet om det). Oftast är komprimeringsalgoritmer för allmänna ändamål (till exempel deflate) lämpliga för kompakt lagring av stora volymer textdata. Dessutom, redan i processen med att skapa min lösning, hittade jag en befintlig standard i Unicode själv, som löser samma problem - det är något mer komplicerat (och ofta värre), men det är ändå en accepterad standard, och inte bara uttryckt tillsammans på knäet. Jag ska berätta om honom också.

Om Unicode och UTF-8

Till att börja med några ord om vad det är Unicode и UTF-8.

Som ni vet var 8-bitars kodningar populära. Med dem var allt enkelt: 256 tecken kan numreras med siffror från 0 till 255, och nummer från 0 till 255 kan uppenbarligen representeras som en byte. Om vi ​​går tillbaka till början är ASCII-kodningen helt begränsad till 7 bitar, så den mest signifikanta biten i dess byte-representation är noll, och de flesta 8-bitars kodningar är kompatibla med den (de skiljer sig bara i den "övre" del, där den viktigaste biten är en ).

Hur skiljer sig Unicode från dessa kodningar och varför är så många specifika representationer associerade med det - UTF-8, UTF-16 (BE och LE), UTF-32? Låt oss reda ut det i ordning.

Den grundläggande Unicode-standarden beskriver endast överensstämmelsen mellan tecken (och i vissa fall individuella komponenter av tecken) och deras nummer. Och det finns många möjliga siffror i denna standard - från 0x00 до 0x10FFFF (1 114 112 stycken). Om vi ​​ville sätta ett tal i ett sådant intervall i en variabel skulle varken 1 eller 2 byte vara tillräckligt för oss. Och eftersom våra processorer inte är särskilt designade för att arbeta med tre-byte-nummer, skulle vi tvingas använda så många som 4 byte per tecken! Detta är UTF-32, men det är just på grund av denna "slöseri" som detta format inte är populärt.

Lyckligtvis är ordningen på tecken i Unicode inte slumpmässig. Hela deras set är uppdelat i 17"flygplan", som var och en innehåller 65536 (0x10000) «kodpunkter" Konceptet med en "kodpunkt" här är helt enkelt teckennummer, tilldelad till den av Unicode. Men, som nämnts ovan, i Unicode är inte bara enskilda tecken numrerade, utan också deras komponenter och servicemärken (och ibland motsvarar ingenting alls numret - kanske för tillfället, men för oss är detta inte så viktigt), så det är mer korrekt att alltid prata specifikt om antalet siffror i sig, och inte symboler. Men i det följande, för korthetens skull, kommer jag ofta att använda ordet "symbol", vilket antyder termen "kodpunkt".

Unicode-plan. Som du kan se är det mesta (plan 4 till 13) fortfarande oanvänt.

Det som är mest anmärkningsvärt är att all huvud "massa" ligger i nollplanet, det kallas "Grundläggande flerspråkigt plan". Om en rad innehåller text på ett av de moderna språken (inklusive kinesiska) kommer du inte att gå bortom detta plan. Men du kan inte heller skära av resten av Unicode - till exempel är emoji huvudsakligen placerade i slutet av nästa plan"Kompletterande flerspråkigt plan"(den sträcker sig från 0x10000 до 0x1FFFF). Så UTF-16 gör detta: alla tecken som faller inom Grundläggande flerspråkigt plan, kodas "som de är" med ett motsvarande tvåbytenummer. Vissa av siffrorna i det här intervallet indikerar dock inte specifika tecken alls, men indikerar att efter detta par av byte måste vi överväga en annan - genom att kombinera värdena för dessa fyra byte tillsammans får vi ett tal som täcker hela det giltiga Unicode-intervallet. Denna idé kallas "surrogatpar" - du kanske har hört talas om dem.

Så UTF-16 kräver två eller (i mycket sällsynta fall) fyra byte per "kodpunkt". Detta är bättre än att använda fyra byte hela tiden, men latin (och andra ASCII-tecken) när de kodas på detta sätt slösar bort halva utrymmet på nollor. UTF-8 är utformad för att korrigera detta: ASCII i den upptar, som tidigare, endast en byte; koder från 0x80 до 0x7FF - två byte; från 0x800 до 0xFFFF - tre, och från 0x10000 до 0x10FFFF - fyra. Å ena sidan har det latinska alfabetet blivit bra: kompatibiliteten med ASCII har återvänt, och fördelningen är mer jämnt "spridd ut" från 1 till 4 byte. Men andra alfabet än latin, tyvärr, gynnas inte på något sätt jämfört med UTF-16, och många kräver nu tre byte istället för två - intervallet som täcks av en två-byte-post har minskat med 32 gånger, med 0xFFFF до 0x7FF, och varken kinesiska eller till exempel georgiska ingår i den. Kyrilliska och fem andra alfabet - hurra - tur, 2 byte per tecken.

Varför händer detta? Låt oss se hur UTF-8 representerar teckenkoder:

Direkt för att representera siffror används bitar markerade med symbolen här x. Det kan ses att i en två-byte-post finns det bara 11 sådana bitar (av 16). De ledande bitarna har här endast en hjälpfunktion. I fallet med en fyra-byte-post tilldelas 21 av 32 bitar för kodpunktsnumret - det verkar som att tre byte (som ger totalt 24 bitar) skulle vara tillräckligt, men servicemarkörer äter upp för mycket.

Är det här dåligt? Inte riktigt. Å ena sidan, om vi bryr oss mycket om rymden, har vi komprimeringsalgoritmer som enkelt kan eliminera all extra entropi och redundans. Å andra sidan var målet med Unicode att tillhandahålla en så universell kodning som möjligt. Till exempel kan vi anförtro en rad kodad i UTF-8 till kod som tidigare bara fungerade med ASCII, och inte vara rädda för att den ska se ett tecken från ASCII-intervallet som faktiskt inte finns där (trots allt, i UTF-8 alla byte som börjar med från nollbiten - det är precis vad ASCII är). Och om vi plötsligt vill skära av en liten svans från en stor sträng utan att avkoda den från första början (eller återställa en del av informationen efter en skadad sektion), är det lätt för oss att hitta offset där en karaktär börjar (det räcker för att hoppa över bytes som har ett bitprefix 10).

Varför då uppfinna något nytt?

Samtidigt finns det ibland situationer när komprimeringsalgoritmer som deflate är dåligt tillämpliga, men du vill uppnå kompakt lagring av strängar. Personligen stötte jag på detta problem när jag funderade på att bygga komprimerat prefixträd för en stor ordbok med ord på godtyckliga språk. Å ena sidan är varje ord väldigt kort, så att komprimera det blir ineffektivt. Å andra sidan var trädimplementeringen som jag ansåg utformad så att varje byte av den lagrade strängen genererade en separat trädpunkt, så att minimera deras antal var mycket användbart. I mitt bibliotek Az.js (Som i pymorfi2, på vilken den är baserad) kan ett liknande problem enkelt lösas - strängar packade i DAWG-ordbok, lagrad där i gamla goda CP1251. Men, som är lätt att förstå, fungerar detta bra bara för ett begränsat alfabet - en rad på kinesiska kan inte läggas till i en sådan ordbok.

Separat skulle jag vilja notera ytterligare en obehaglig nyans som uppstår när man använder UTF-8 i en sådan datastruktur. Bilden ovan visar att när ett tecken skrivs som två byte kommer bitarna som är relaterade till dess nummer inte i en rad, utan separeras av ett par bitar 10 i mitten: 110xxxxx 10xxxxxx. På grund av detta, när de lägre 6 bitarna av den andra byten svämmar över i teckenkoden (dvs en övergång inträffar 10111111 → 10000000), så ändras också den första byten. Det visar sig att bokstaven "p" betecknas med bytes 0xD0 0xBF, och nästa "r" är redan 0xD1 0x80. I ett prefixträd leder detta till att föräldranoden delas i två - en för prefixet 0xD0, och en annan för 0xD1 (även om hela det kyrilliska alfabetet endast kunde kodas av den andra byten).

Vad fick jag

Inför detta problem bestämde jag mig för att öva på att spela spel med bitar, och samtidigt bekanta mig lite bättre med strukturen i Unicode som helhet. Resultatet blev UTF-C-kodningsformatet ("C" för kompakt), som inte spenderar mer än 3 byte per kodpunkt, och mycket ofta låter dig bara spendera en extra byte för hela den kodade raden. Detta leder till det faktum att på många icke-ASCII-alfabet visar sig sådan kodning vara 30-60 % mer kompakt än UTF-8.

Jag har presenterat exempel på implementering av kodnings- och avkodningsalgoritmer i formuläret JavaScript och Go-bibliotek, kan du fritt använda dem i din kod. Men jag kommer fortfarande att betona att det här formatet på ett sätt förblir en "cykel", och jag rekommenderar inte att du använder det utan att inse varför du behöver det. Detta är fortfarande mer ett experiment än en allvarlig "förbättring av UTF-8". Ändå är koden där skriven snyggt, kortfattat, med ett stort antal kommentarer och testtäckning.

Testresultat och jämförelse med UTF-8

Det gjorde jag också demosida, där du kan utvärdera algoritmens prestanda, och sedan kommer jag att berätta mer om dess principer och utvecklingsprocess.

Eliminera redundanta bitar

Jag tog UTF-8 som grund såklart. Det första och mest uppenbara som kan ändras i den är att minska antalet tjänstebitar i varje byte. Till exempel börjar den första byten i UTF-8 alltid med någondera 0, eller med 11 - ett prefix 10 Endast följande byte har det. Låt oss byta ut prefixet 11 på 1, och för nästa byte kommer vi att ta bort prefixen helt. Vad kommer att hända?

0xxxxxxx — 1 byte
10xxxxxx xxxxxxxx - 2 byte
110xxxxx xxxxxxxx xxxxxxxx - 3 byte

Vänta, var är posten på fyra byte? Men det behövs inte längre - när man skriver i tre byte har vi nu 21 bitar tillgängliga och det räcker för alla nummer upp till 0x10FFFF.

Vad har vi offrat här? Det viktigaste är upptäckten av teckengränser från en godtycklig plats i bufferten. Vi kan inte peka på en godtycklig byte och hitta början på nästa tecken från den. Detta är en begränsning av vårt format, men i praktiken är detta sällan nödvändigt. Vi brukar kunna köra igenom bufferten redan från början (särskilt när det gäller korta linjer).

Situationen med att täcka språk med 2 byte har också blivit bättre: nu ger tvåbyteformatet ett intervall på 14 bitar, och det är koder upp till 0x3FFF. Kineserna har otur (deras karaktärer sträcker sig mestadels från 0x4E00 до 0x9FFF), men georgier och många andra folk har roligare - deras språk passar också in i 2 byte per tecken.

Ange kodartillståndet

Låt oss nu tänka på egenskaperna hos själva linjerna. Ordboken innehåller oftast ord skrivna med bokstäver av samma alfabet, och det gäller även många andra texter. Det skulle vara bra att ange detta alfabet en gång och sedan endast ange numret på bokstaven i det. Låt oss se om arrangemanget av tecken i Unicode-tabellen kommer att hjälpa oss.

Som nämnts ovan är Unicode indelad i plan 65536 koder vardera. Men detta är inte en mycket användbar uppdelning (som redan sagt, oftast är vi i nollplanet). Mer intressant är uppdelningen efter block. Dessa intervall har inte längre en fast längd och är mer meningsfulla - som regel kombinerar vart och ett av tecken från samma alfabet.

Ett block som innehåller tecken från det bengaliska alfabetet. Tyvärr, av historiska skäl, är detta ett exempel på inte särskilt tät förpackning - 96 tecken är kaotiskt utspridda över 128 blockkodpunkter.

Början av block och deras storlekar är alltid multiplar av 16 - detta görs helt enkelt för bekvämlighet. Dessutom börjar och slutar många block på värden som är multiplar av 128 eller till och med 256 - till exempel tar det grundläggande kyrilliska alfabetet upp 256 byte från 0x0400 до 0x04FF. Detta är ganska bekvämt: om vi sparar prefixet en gång 0x04, då kan vilket kyrilliskt tecken som helst skrivas i en byte. Det är sant att vi på detta sätt förlorar möjligheten att återvända till ASCII (och till alla andra karaktärer i allmänhet). Därför gör vi så här:

1. Två byte 10yyyyyy yxxxxxxx inte bara beteckna en symbol med ett nummer yyyyyy yxxxxxxx, men också förändras nuvarande alfabetet på yyyyyy y0000000 (dvs vi kommer ihåg alla bitar utom de minst signifikanta 7-bit);
2. En byte 0xxxxxxx detta är karaktären för det aktuella alfabetet. Det behöver bara läggas till förskjutningen som vi kom ihåg i steg 1. Även om vi inte ändrade alfabetet är förskjutningen noll, så vi bibehöll kompatibilitet med ASCII.

Likaså för koder som kräver 3 byte:

1. Tre byte 110yyyyy yxxxxxxx xxxxxxxx ange en symbol med ett nummer yyyyyy yxxxxxxx xxxxxxxx, förändra nuvarande alfabetet på yyyyyy y0000000 00000000 (kom ihåg allt utom de yngre 15-bit), och markera rutan som vi nu är i lång läge (när vi ändrar alfabetet tillbaka till ett dubbelbyte, återställer vi denna flagga);
2. Två byte 0xxxxxxx xxxxxxxx i långt läge är det karaktären för det aktuella alfabetet. På samma sätt lägger vi till det med offset från steg 1. Den enda skillnaden är att nu läser vi två byte (eftersom vi bytte till detta läge).

Låter bra: medan vi nu behöver koda tecken från samma 7-bitars Unicode-intervall, spenderar vi 1 extra byte i början och totalt en byte per tecken.

Arbetar från en av de tidigare versionerna. Den slår redan ofta UTF-8, men det finns fortfarande utrymme för förbättringar.

Vad är värre? För det första har vi ett villkor, nämligen aktuell alfabetsoffset och kryssrutan långt läge. Detta begränsar oss ytterligare: nu kan samma tecken kodas olika i olika sammanhang. Att söka efter delsträngar, till exempel, måste göras med hänsyn till detta, och inte bara genom att jämföra bytes. För det andra, så snart vi ändrade alfabetet, blev det dåligt med kodningen av ASCII-tecken (och detta är inte bara det latinska alfabetet, utan också grundläggande interpunktion, inklusive mellanslag) - de kräver att alfabetet ändras igen till 0, det vill säga, återigen en extra byte (och sedan ytterligare en för att komma tillbaka till vår huvudpoäng).

Ett alfabet är bra, två är bättre

Låt oss försöka ändra våra bitprefix lite och klämma in ett till till de tre som beskrivs ovan:

0xxxxxxx — 1 byte i normalt läge, 2 i långt läge
11xxxxxx — 1 byte
100xxxxx xxxxxxxx - 2 byte
101xxxxx xxxxxxxx xxxxxxxx - 3 byte

Nu i en två-byte-post finns det en mindre tillgänglig bit - kodpunkter upp till 0x1FFFOch inte 0x3FFF. Det är dock fortfarande märkbart större än i dubbelbyte UTF-8-koder, de vanligaste språken passar fortfarande in, den mest märkbara förlusten har fallit ut hiragana и katakana, japanerna är ledsna.

Vad är denna nya kod? 11xxxxxx? Det här är ett litet "stash" med 64 tecken i storlek, det kompletterar vårt huvudalfabet, så jag kallade det extra (extra) alfabetet. När vi byter det nuvarande alfabetet blir en del av det gamla alfabetet extra. Till exempel bytte vi från ASCII till kyrilliska - stash innehåller nu 64 tecken som innehåller Latinska alfabetet, siffror, mellanslag och kommatecken (mest frekventa infogningar i icke-ASCII-texter). Byt tillbaka till ASCII - och huvuddelen av det kyrilliska alfabetet kommer att bli hjälpalfabetet.

Tack vare tillgång till två alfabet kan vi hantera ett stort antal texter med minimala kostnader för att byta alfabet (interpunktion leder oftast till en återgång till ASCII, men efter det kommer vi att få många icke-ASCII-tecken från tilläggsalfabetet, utan byter igen).

Bonus: prefixet underalfabetet 11xxxxxx och välja att dess initiala offset ska vara 0xC0, får vi delvis kompatibilitet med CP1252. Med andra ord kommer många (men inte alla) västeuropeiska texter kodade i CP1252 att se likadana ut i UTF-C.

Här uppstår dock en svårighet: hur får man en extra från huvudalfabetet? Du kan lämna samma offset, men - tyvärr - här spelar Unicode-strukturen redan mot oss. Mycket ofta är huvuddelen av alfabetet inte i början av blocket (till exempel den ryska huvudstaden "A" har koden 0x0410, även om det kyrilliska blocket börjar med 0x0400). Efter att ha tagit de första 64 tecknen i arkivet kan vi förlora tillgången till alfabetets bakdel.

För att åtgärda det här problemet gick jag manuellt igenom några block som motsvarar olika språk och specificerade förskjutningen av hjälpalfabetet inom det huvudsakliga alfabetet för dem. Det latinska alfabetet, som ett undantag, omordnades i allmänhet som base64.

Sista handen

Låt oss äntligen fundera på var vi annars kan förbättra något.

Observera att formatet 101xxxxx xxxxxxxx xxxxxxxx låter dig koda nummer upp till 0x1FFFFF, och Unicode slutar tidigare, kl 0x10FFFF. Med andra ord kommer den sista kodpunkten att representeras som 10110000 11111111 11111111. Därför kan vi säga att om den första byten är av formen 1011xxxx (Var xxxx större än 0), betyder det något annat. Till exempel kan du lägga till ytterligare 15 tecken där som ständigt är tillgängliga för kodning i en byte, men jag bestämde mig för att göra det annorlunda.

Låt oss titta på de Unicode-block som kräver tre byte nu. I grund och botten, som redan nämnts, är dessa kinesiska tecken - men det är svårt att göra något med dem, det finns 21 tusen av dem. Men även hiragana och katakana flög dit – och det finns inte så många av dem längre, mindre än tvåhundra. Och eftersom vi kom ihåg japanerna, finns det också emojis (i själva verket är de utspridda på många ställen i Unicode, men huvudblocken finns i sortimentet 0x1F300 - 0x1FBFF). Om du tänker på det faktum att det nu finns emojis som är sammansatta från flera kodpunkter samtidigt (till exempel emojin ‍‍‍ består av så många som 7 koder!), då blir det synd att lägga tre byte på varje (7×3 = 21 byte för en ikons skull, en mardröm).

Därför väljer vi några utvalda intervall som motsvarar emoji, hiragana och katakana, numrerar om dem till en kontinuerlig lista och kodar dem som två byte istället för tre:

1011xxxx xxxxxxxx

Bra: den ovannämnda emojin, som består av 7 kodpunkter, tar 8 byte i UTF-25, och vi passar in den 14 (exakt två byte för varje kodpunkt). Habr vägrade förresten att smälta det (både i den gamla och i den nya editorn), så jag var tvungen att lägga in den med en bild.

Låt oss försöka lösa ett problem till. Som vi minns är det grundläggande alfabetet i huvudsak hög 6 bitar, som vi har i åtanke och limmar till koden för varje nästa avkodade symbol. När det gäller kinesiska tecken som finns i blocket 0x4E00 - 0x9FFF, detta är antingen bit 0 eller 1. Detta är inte särskilt bekvämt: vi kommer att behöva ständigt byta alfabetet mellan dessa två värden (dvs spendera tre byte). Men observera att i det långa läget, från själva koden kan vi subtrahera antalet tecken som vi kodar med det korta läget (efter alla knep som beskrivs ovan är detta 10240) - då kommer hieroglyfernas intervall att skifta till 0x2600 - 0x77FF, och i det här fallet, genom hela detta intervall, kommer de mest signifikanta 6 bitarna (av 21) att vara lika med 0. Således kommer sekvenser av hieroglyfer att använda två byte per hieroglyf (vilket är optimalt för ett så stort intervall), utan orsakar alfabetsväxlar.

Alternativa lösningar: SCSU, BOCU-1

Unicode-experter, efter att precis ha läst artikelns titel, kommer sannolikt att skynda sig att påminna dig om att direkt bland Unicode-standarderna finns Standardkompressionsschema för Unicode (SCSU), som beskriver en kodningsmetod mycket lik den som beskrivs i artikeln.

Jag erkänner ärligt: ​​jag fick veta om dess existens först efter att jag var djupt fördjupad i att skriva mitt beslut. Hade jag vetat om det från början så hade jag nog försökt skriva en implementering istället för att komma på ett eget tillvägagångssätt.

Vad som är intressant är att SCSU använder idéer som liknar de jag kom på själv (istället för begreppet "alfabet" använder de "fönster", och det finns fler tillgängliga än jag har). Samtidigt har detta format också nackdelar: det är lite närmare komprimeringsalgoritmer än kodningsalgoritmer. I synnerhet ger standarden många representationsmetoder, men säger inte hur man väljer den optimala - för detta måste kodaren använda någon form av heuristik. Således kommer en SCSU-kodare som producerar bra förpackningar att vara mer komplex och krångligare än min algoritm.

Som jämförelse överförde jag en relativt enkel implementering av SCSU till JavaScript - vad gäller kodvolym visade den sig vara jämförbar med min UTF-C, men i vissa fall blev resultatet tiotals procent sämre (ibland kan det överskrida det, men inte mycket). Till exempel kodades texter på hebreiska och grekiska av UTF-C 60 % bättre än SCSU (förmodligen på grund av deras kompakta alfabet).

Separat tillägger jag att det förutom SCSU också finns ett annat sätt att kompakt representera Unicode - BOCU-1, men det syftar till MIME-kompatibilitet (vilket jag inte behövde) och tar ett lite annorlunda tillvägagångssätt för kodning. Jag har inte bedömt dess effektivitet, men det förefaller mig som om det är osannolikt att det är högre än SCSU.

Möjliga förbättringar

Algoritmen jag presenterade är inte universell till sin design (det är förmodligen där mina mål avviker mest från Unicode-konsortiets mål). Jag har redan nämnt att den utvecklades främst för en uppgift (lagring av en flerspråkig ordbok i ett prefixträd), och vissa av dess funktioner kanske inte är väl lämpade för andra uppgifter. Men det faktum att det inte är en standard kan vara ett plus - du kan enkelt modifiera den för att passa dina behov.

Till exempel, på det uppenbara sättet kan du bli av med närvaron av tillstånd, göra tillståndslös kodning - bara uppdatera inte variabler offs, auxOffs и is21Bit i kodaren och avkodaren. I det här fallet kommer det inte att vara möjligt att effektivt packa sekvenser av tecken i samma alfabet, men det kommer att finnas en garanti för att samma tecken alltid är kodat med samma byte, oavsett sammanhang.

Dessutom kan du skräddarsy kodaren till ett specifikt språk genom att ändra standardtillståndet - till exempel fokusera på ryska texter, ställ in kodaren och avkodaren i början offs = 0x0400 и auxOffs = 0. Detta är särskilt vettigt i fallet med statslöst läge. I allmänhet kommer detta att likna att använda den gamla åttabitarskodningen, men utan att ta bort möjligheten att infoga tecken från all Unicode efter behov.

En annan nackdel som nämnts tidigare är att det i stor text kodad i UTF-C inte finns något snabbt sätt att hitta teckengränsen närmast en godtycklig byte. Om du skär av de sista, säg, 100 byten från den kodade bufferten, riskerar du att få skräp som du inte kan göra något med. Kodningen är inte designad för att lagra loggar på flera gigabyte, men i allmänhet kan detta korrigeras. Byte 0xBF får aldrig visas som den första byten (men kan vara den andra eller tredje). Därför kan du infoga sekvensen när du kodar 0xBF 0xBF 0xBF var, säg, 10 KB - då, om du behöver hitta en gräns, räcker det med att skanna den valda biten tills en liknande markör hittas. Efter det sista 0xBF är garanterat början på en karaktär. (Vid avkodning kommer denna sekvens på tre byte naturligtvis att behöva ignoreras.)

Sammanfattningsvis

Om du har läst så här långt, grattis! Jag hoppas att du, precis som jag, har lärt dig något nytt (eller fräschat upp ditt minne) om Unicodes struktur.

Demosida. Exemplet med hebreiska visar fördelarna jämfört med både UTF-8 och SCSU.

Den ovan beskrivna forskningen ska inte betraktas som ett intrång i standarder. Jag är dock generellt sett nöjd med resultatet av mitt arbete, så jag är nöjd med dem del: till exempel väger ett minifierat JS-bibliotek bara 1710 byte (och har naturligtvis inga beroenden). Som jag nämnde ovan finns hennes arbete på demosida (det finns också en uppsättning texter där den kan jämföras med UTF-8 och SCSU).

Slutligen ska jag återigen uppmärksamma fall där UTF-C används inte värt det:

• Om dina rader är tillräckligt långa (från 100-200 tecken). I det här fallet bör du tänka på att använda komprimeringsalgoritmer som deflate.
• Om du behöver ASCII-transparens, det vill säga det är viktigt för dig att de kodade sekvenserna inte innehåller ASCII-koder som inte fanns i den ursprungliga strängen. Behovet av detta kan undvikas om du, när du interagerar med tredje parts API:er (till exempel arbetar med en databas), skickar kodningsresultatet som en abstrakt uppsättning byte, och inte som strängar. Annars riskerar du att få oväntade sårbarheter.
• Om du snabbt vill kunna hitta teckengränser vid en godtycklig offset (till exempel när en del av en linje är skadad). Detta kan göras, men bara genom att skanna linjen från början (eller tillämpa ändringen som beskrivs i föregående avsnitt).
• Om du snabbt behöver utföra operationer på innehållet i strängar (sortera dem, sök efter delsträngar i dem, sammanfoga). Detta kräver att strängar avkodas först, så UTF-C kommer att vara långsammare än UTF-8 i dessa fall (men snabbare än komprimeringsalgoritmer). Eftersom samma sträng alltid är kodad på samma sätt, krävs ingen exakt jämförelse av avkodning och kan göras byte-för-byte.

Uppdatering: Användaren Tyomitch i kommentarerna nedan publicerade en graf som belyser tillämplighetsgränserna för UTF-C. Det visar att UTF-C är effektivare än en allmän komprimeringsalgoritm (en variant av LZW) så länge den packade strängen är kortare ~140 tecken (Jag noterar dock att jämförelsen utfördes på en text; för andra språk kan resultatet skilja sig).


Källa: will.com