En anere Vëlo: mir späicheren Unicode Saiten 30-60% méi kompakt wéi UTF-8

Wann Dir en Entwéckler sidd an Dir sidd mat der Aufgab konfrontéiert fir eng Kodéierung ze wielen, da wäert Unicode bal ëmmer déi richteg Léisung sinn. Déi spezifesch Representatiounsmethod hänkt vum Kontext of, awer meeschtens gëtt et och hei eng universell Äntwert - UTF-8. Déi gutt Saach doriwwer ass datt et Iech erlaabt all Unicode Charaktere ze benotzen ouni Ausgaben ze vill vill Bytes am meeschte Fäll. Richteg, fir Sproochen déi méi wéi just dat laténgescht Alphabet benotzen, ass "net zevill" op d'mannst zwee Bytes pro Charakter. Kënne mir et besser maachen ouni op prehistoresch Kodéierungen zréckzekommen, déi eis op just 256 verfügbare Charaktere limitéieren?

Drënner proposéieren ech Iech mat mengem Versuch vertraut ze maachen dës Fro ze beäntweren an e relativ einfachen Algorithmus ëmzesetzen deen Iech erlaabt Linnen an de meeschte Sprooche vun der Welt ze späicheren ouni d'Redundanz ze addéieren déi am UTF-8 ass.

Verzichterklärung. Ech wäert direkt e puer wichteg Reservatioune maachen: Déi beschriwwe Léisung gëtt net als universell Ersatz fir UTF-8 ugebueden, et ass nëmme gëeegent an enger schmueler Lëscht vu Fäll (méi iwwer hinnen hei ënnen), an op kee Fall sollt et benotzt ginn fir mat Drëtt Partei APIen ze interagéieren (déi net emol doriwwer wëssen). Meeschtens sinn allgemeng Zwecker Kompressiounsalgorithmen (zum Beispill deflatéieren) gëeegent fir kompakt Späichere vu grousse Volumen vun Textdaten. Zousätzlech, schonn am Prozess vu menger Léisung ze kreéieren, hunn ech en existente Standard an Unicode selwer fonnt, deen dee selwechte Problem léist - et ass e bësse méi komplizéiert (an dacks méi schlëmm), awer et ass ëmmer nach en akzeptéierte Standard, an net nëmmen gesat. zesummen um Knéi. Ech soen Iech och iwwer hien.

Iwwer Unicode an UTF-8

Fir unzefänken, e puer Wierder iwwer wat et ass Unicode и UTF-8.

Wéi Dir wësst, waren 8-Bit Kodéierunge fréier populär. Mat hinnen war alles einfach: 256 Zeeche kënne mat Zuelen vun 0 bis 255 nummeréiert ginn, an Zuele vun 0 bis 255 kënnen selbstverständlech als ee Byte duergestallt ginn. Wa mir zréck an den Ufank zréckgoen, ass d'ASCII Kodéierung komplett op 7 Bits limitéiert, sou datt de bedeitendste Bit a senger Byte Representatioun null ass, an déi meescht 8-Bit Kodéierunge si kompatibel mat et (se ënnerscheeden nëmmen am "Uewer" Deel, wou de bedeitendsten bëssen een ass).

Wéi ënnerscheet sech Unicode vun dëse Kodéierungen a firwat si sou vill spezifesch Representatioune mat him verbonnen - UTF-8, UTF-16 (BE an LE), UTF-32? Loosst eis et an Uerdnung sortéieren.

De Basis Unicode Standard beschreift nëmmen d'Korrespondenz tëscht Charakteren (an a verschiddene Fäll eenzel Komponente vun Zeechen) an hiren Zuelen. An et gi vill vun méiglech Zuelen an dësem Standard - vun 0x00 ze 0x10FFFF (1 Stécker). Wa mir eng Nummer an esou engem Beräich an eng Variabel wëllen setzen, da wiere weder 114 nach 112 Bytes fir eis duer. A well eis Prozessoren net ganz entwéckelt sinn fir mat dräi-Byte Zuelen ze schaffen, wäerte mir gezwongen sinn esou vill wéi 1 Bytes pro Charakter ze benotzen! Dëst ass UTF-2, awer et ass genee wéinst dëser "Verschwendung" datt dëst Format net populär ass.

Glécklecherweis ass d'Uerdnung vun de Charaktere bannent Unicode net zoufälleg. Hire ganze Set ass opgedeelt an 17 "Fligeren", jidderee vun deenen enthält 65536 (0x10000) "Code Punkten" D'Konzept vun engem "Code Punkt" hei ass einfach Zeechen Zuel, vun Unicode zougewisen. Awer, wéi uewen ernimmt, an Unicode sinn net nëmmen eenzel Charaktere nummeréiert, awer och hir Komponenten a Servicemarken (an heiansdo entsprécht näischt der Zuel - vläicht fir de Moment, awer fir eis ass dat net sou wichteg), also et ass méi richteg schwätzen ëmmer speziell iwwert d'Zuel vun Zuelen selwer, an net Symboler. Wéi och ëmmer, am folgenden, fir d'Kuerzlechkeet, wäert ech dacks d'Wuert "Symbol" benotzen, wat de Begrëff "Codepunkt" implizéiert.

Unicode Fligeren. Wéi Dir gesitt, ass de gréissten Deel (Fliger 4 bis 13) nach net benotzt.

Wat am meeschte bemierkenswäert ass ass datt all d'Haapt "Pulp" am Nullplang läit, et gëtt genannt "Basis Multilingual Fliger". Wann eng Zeil Text an enger vun de modernen Sproochen enthält (och Chinesesch), wäert Dir net iwwer dëse Fliger goen. Awer Dir kënnt och de Rescht vun Unicode net ofschneiden - zum Beispill Emoji sinn haaptsächlech um Enn vum den nächste Fliger,"Zousätzlech Multilingual Plane"(et geet aus 0x10000 ze 0x1FFFF). Also UTF-16 mécht dëst: all Charaktere falen dobannen Basis Multilingual Fliger, sinn kodéiert "wéi ass" mat enger entspriechender zwee-Byte Zuel. Wéi och ëmmer, e puer vun den Zuelen an dësem Beräich weisen guer net spezifesch Zeechen un, awer weisen datt no dësem Pair vu Bytes mir eng aner musse berücksichtegen - andeems Dir d'Wäerter vun dëse véier Bytes zesumme kombinéiere kréie mir eng Zuel déi deckt déi ganz gëlteg Unicode Gamme. Dës Iddi gëtt "Surrogat Koppelen" genannt - Dir hutt vläicht vun hinnen héieren.

Also UTF-16 erfuerdert zwee oder (a ganz rare Fäll) véier Bytes pro "Codepunkt". Dëst ass besser wéi véier Bytes déi ganzen Zäit ze benotzen, awer Laténgesch (an aner ASCII Zeechen) wann se op dës Manéier kodéiert verschwenden d'Halschent vum Raum op Nullen. UTF-8 ass entwéckelt fir dëst ze korrigéieren: ASCII an et besetzt, wéi virdrun, nëmmen ee Byte; Coden vun 0x80 ze 0x7FF - zwee Bytes; vun 0x800 ze 0xFFFF - dräi, an aus 0x10000 ze 0x10FFFF - véier. Engersäits ass d'laténgesch Alphabet gutt ginn: Kompatibilitéit mat ASCII ass zréck, an d'Verdeelung ass méi gläichméisseg "verbreet" vun 1 bis 4 Bytes. Awer aner Alphabeten wéi Latäin, leider, profitéieren op kee Fall am Verglach zum UTF-16, a vill erfuerderen elo dräi Bytes anstatt zwee - d'Gamme, déi vun engem Zwee-Byte-Rekord bedeckt ass, ass ëm 32 Mol verréngert, mat 0xFFFF ze 0x7FF, a weder Chinesesch nach, zum Beispill, Georgian sinn derbäi. Kyrillesch a fënnef aner Alphabeten - Hurra - Gléck, 2 Bytes pro Charakter.

Firwat geschitt dat? Loosst eis kucken wéi UTF-8 Charaktercodes duerstellt:

Direkt fir Zuelen ze representéieren, Bits markéiert mam Symbol ginn hei benotzt x. Et kann gesi ginn datt an engem Zwee-Byte-Rekord nëmmen 11 esou Bits sinn (vun 16). Déi féierend Bits hunn hei nëmmen eng Hëllefsfunktioun. Am Fall vun engem Véier-Byte-Rekord ginn 21 vun 32 Bits fir d'Codepunktnummer zougewisen - et géif schéngen datt dräi Bytes (déi am Ganzen 24 Bits ginn) genuch wieren, awer Servicemarker iessen ze vill.

Ass dëst schlecht? Net wierklech. Engersäits, wa mir eis vill ëm de Raum këmmeren, hu mir Kompressiounsalgorithmen déi all extra Entropie a Redundanz ganz einfach eliminéiere kënnen. Op der anerer Säit war d'Zil vum Unicode fir déi universellst méiglech Kodéierung ze bidden. Zum Beispill kënne mir eng Zeil, déi an UTF-8 encodéiert ass, uvertrauen, fir ze codéieren, déi virdru nëmme mat ASCII geschafft huet, an net Angscht datt et e Charakter aus der ASCII-Bereich wäert gesinn, déi tatsächlech net do ass (schliisslech an UTF-8 alles Bytes ugefaange mat dem Nullbit - dat ass genau wat ASCII ass). A wa mir op eemol e klenge Schwanz vun engem grousse String wëllen ofschneiden ouni et vun Ufank un ze decodéieren (oder en Deel vun der Informatioun no enger beschiedegter Sektioun restauréieren), ass et einfach fir eis de Offset ze fannen wou e Charakter ufänkt (et geet duer fir Bytes ze sprangen déi e bësse Präfix hunn 10).

Firwat dann eppes Neies erfannen?

Zur selwechter Zäit ginn et heiansdo Situatiounen wou Kompressiounsalgorithmen wéi Deflate schlecht applicabel sinn, awer Dir wëllt kompakt Späichere vu Saiten erreechen. Perséinlech hunn ech dëse Problem begéint wann ech iwwer d'Gebai denken kompriméiert Präfix Bam fir e grousst Wierderbuch abegraff Wierder an arbiträr Sproochen. Engersäits ass all Wuert ganz kuerz, sou datt et net effikass ass ze kompriméieren. Op der anerer Säit ass d'Bamimplementatioun, déi ech betruecht hunn, sou entworf datt all Byte vun der gespäichert String e separaten Bamvertex generéiert, sou datt hir Zuel miniméiert war ganz nëtzlech. A menger Bibliothéik Az.js (Wéi an pymorphy 2, op deem et baséiert) kann en ähnleche Problem einfach geléist ginn - Strings gepackt an DAWG-Wörterbuch, do gespäichert an gutt al CP1251. Awer, wéi einfach ze verstoen ass, funktionnéiert dat nëmme fir e limitéierten Alphabet - eng Zeil op Chinesesch kann net an esou engem Wierderbuch bäigefüügt ginn.

Separat wëll ech eng méi désagréabel Nuance notéieren, déi entsteet wann Dir UTF-8 an esou enger Datestruktur benotzt. D'Bild hei uewen weist datt wann e Charakter als zwee Bytes geschriwwe gëtt, d'Bits am Zesummenhang mat senger Nummer net an enger Zeil kommen, mee duerch e Paar Bits getrennt sinn. 10 an der Mëtt: 110xxxxx 10xxxxxx. Dofir, wann déi ënnescht 6 Bits vum zweete Byte am Zeechecode iwwerfléien (dh en Iwwergang geschitt 10111111 → 10000000), da ännert sech och den éischte Byte. Et stellt sech eraus datt de Bréif "p" mat Bytes bezeechent gëtt 0xD0 0xBF, an den nächsten "r" ass schonn 0xD1 0x80. An engem Präfix Bam féiert dat zu der Spaltung vun der Elterendeel Node an zwee - eent fir de Präfix 0xD0, an eng aner fir 0xD1 (obwuel dat ganzt kyrillescht Alphabet nëmme vum zweete Byte kodéiert ka ginn).

Wat krut ech

Géint dësem Problem hunn ech beschloss, Spiller mat Bits ze spillen, a gläichzäiteg e bësse besser mat der Struktur vum Unicode als Ganzt kennenzeléieren. D'Resultat war den UTF-C Kodéierungsformat ("C" fir kompakt), déi verbréngt net méi wéi 3 Bytes pro Code Punkt, a ganz oft erlaabt Iech nëmmen ze verbréngen een extra Byte fir déi ganz kodéiert Linn. Dëst féiert zu der Tatsaach, datt op villen net-ASCII Alfabeten esou Kodéierung erausstellt 30-60% méi kompakt wéi UTF-8.

Ech hunn Beispiller vun der Ëmsetzung vun Kodéierung an Dekodéierung Algorithmen an der Form presentéiert JavaScript a Go Bibliothéiken, Dir kënnt se fräi an Ärem Code benotzen. Awer ech wäert nach ëmmer ënnersträichen datt dëst Format an engem Sënn e "Vëlo" bleift, an ech recommandéieren et net ze benotzen ouni ze realiséieren firwat Dir et braucht. Dëst ass nach ëmmer méi en Experiment wéi eng sérieux "Verbesserung vun UTF-8". Trotzdem ass de Code do ordentlech, präzis geschriwwen, mat enger grousser Zuel vu Kommentaren an Testofdeckung.

Test Resultater a Verglach mat UTF-8

Ech hunn och Demo Säit, wou Dir d'Performance vum Algorithmus evaluéiere kënnt, an da wäert ech Iech méi iwwer seng Prinzipien an Entwécklungsprozess soen.

Redundante Bits eliminéieren

Ech hunn UTF-8 als Basis geholl, natierlech. Déi éischt an déi offensichtlechst Saach, déi dran geännert ka ginn, ass d'Zuel vun de Servicebits an all Byte ze reduzéieren. Zum Beispill fänkt den éischte Byte an UTF-8 ëmmer mat entweder un 0, oder mat 11 - e Präfix 10 Nëmmen déi folgend Bytes hunn et. Loosst eis de Präfix ersetzen 11 op 1, a fir déi nächst Bytes wäerte mir d'Präfixe komplett ewechhuelen. Wat wäert geschéien?

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

Waart, wou ass de véier-Byte Rekord? Mee et ass net méi gebraucht - wann Dir an dräi Bytes schreift, hu mir elo 21 Bits zur Verfügung an dat geet duer fir all Zuelen bis zu 0x10FFFF.

Wat hu mir hei geaffert? Déi wichtegst Saach ass d'Detektioun vu Charaktergrenze vun enger arbiträrer Plaz am Puffer. Mir kënnen net op eng arbiträr Byte weisen an den Ufank vum nächste Charakter dovunner fannen. Dëst ass eng Begrenzung vun eisem Format, awer an der Praxis ass dëst selten néideg. Mir kënnen normalerweis vun Ufank un duerch de Puffer lafen (besonnesch wann et ëm kuerz Linnen geet).

D'Situatioun mat der Ofdeckung vu Sprooche mat 2 Bytes ass och besser ginn: elo gëtt den Zwee-Byte Format eng Rei vu 14 Bits, an dat sinn Coden bis zu 0x3FFF. D'Chinesen sinn onglécklech (hir Charaktere reechen meeschtens vun 0x4E00 ze 0x9FFF), awer Georgianer a vill aner Vëlker hu méi Spaass - hir Sprooche passen och an 2 Bytes pro Charakter.

Gitt den Encoder Staat

Loosst eis elo iwwer d'Eegeschafte vun de Linnen selwer denken. Am Wierderbuch enthält meeschtens Wierder, déi a Charaktere vum selwechte Alphabet geschriwwe sinn, an dat gëllt och fir vill aner Texter. Et wier gutt dëst Alphabet eemol unzeginn, an dann nëmmen d'Zuel vum Buschtaf dran uginn. Loosst eis kucken ob d'Arrangement vun de Personnagen an der Unicode Dësch eis hëlleft.

Wéi uewen ernimmt, ass Unicode opgedeelt an Fliger 65536 Coden all. Awer dëst ass net eng ganz nëtzlech Divisioun (wéi scho gesot, meeschtens si mir am Nullfliger). Méi interessant ass d'Divisioun duerch spären. Dës Beräicher hunn net méi eng fix Längt, a si méi sënnvoll - als Regel, kombinéiert all Zeechen aus dem selwechten Alphabet.

E Block mat Charaktere vum Bengalesche Alphabet. Leider, aus historesche Grënn, ass dëst e Beispill vun net ganz dichter Verpakung - 96 Charaktere si chaotesch iwwer 128 Blockcodepunkte verspreet.

D'Ufanks vu Blocken an hir Gréissten sinn ëmmer Multiple vu 16 - dëst gëtt einfach gemaach fir d'Bequemlechkeet. Ausserdeem fänken a vill Blocken op Wäerter op, déi Multiple vun 128 oder souguer 256 sinn - zum Beispill, dat Basis kyrillescht Alphabet hëlt 256 Bytes aus 0x0400 ze 0x04FF. Dëst ass ganz bequem: wa mir de Präfix eemol späicheren 0x04, da kann all kyrillescht Zeechen an engem Byte geschriwwe ginn. True, sou wäerte mir d'Méiglechkeet verléieren op ASCII zréckzekommen (an all aner Personnagen am Allgemengen). Dofir maache mir dat:

1. Zwee Bytes 10yyyyyy yxxxxxxx net nëmmen e Symbol mat enger Zuel bezeechnen yyyyyy yxxxxxxx, awer och änneren aktuell Alphabet op yyyyyy y0000000 (dh mir erënneren all d'Bits ausser déi mannst bedeitend 7 bëssen);
2. Ee Byte 0xxxxxxx dat ass de Charakter vum aktuellen Alphabet. Et muss just op d'Offset bäigefüügt ginn, déi mir am Schrëtt 1 erënnert hunn. Och wa mir d'Alphabet net geännert hunn, ass de Offset null, also hu mir Kompatibilitéit mat ASCII behalen.

Och fir Coden déi 3 Bytes erfuerderen:

1. Dräi Bytes 110yyyyy yxxxxxxx xxxxxxxx uginn e Symbol mat enger Zuel yyyyyy yxxxxxxx xxxxxxxx, änneren aktuell Alphabet op yyyyyy y0000000 00000000 (huet alles erënnert ausser déi jéngst 15 bëssen), a kontrolléiert d'Këscht wou mir elo sinn laang Modus (wann Dir d'Alphabet zréck an en Duebelbyte ännert, wäerte mir dëse Fändel zrécksetzen);
2. Zwee Bytes 0xxxxxxx xxxxxxxx am laange Modus ass et de Charakter vum aktuellen Alphabet. Ähnlech addéiere mer et mat der Offset vum Schrëtt 1. Deen eenzegen Ënnerscheed ass datt mir elo zwee Bytes liesen (well mir op dëse Modus gewiesselt sinn).

Kléngt gutt: Elo, wa mir Zeechen aus dem selwechte 7-Bit Unicode-Bereich musse codéieren, verbrénge mir 1 extra Byte am Ufank an am Ganzen ee Byte pro Charakter.

Schafft vun enger vun de fréiere Versiounen. Et schléit schonn dacks UTF-8, awer et gëtt nach Plaz fir Verbesserung.

Wat ass méi schlëmm? Als éischt hu mir eng Konditioun, nämlech aktuell Alphabet Offset an Checkbox laang Modus. Dëst limitéiert eis weider: elo kënnen déiselwecht Zeechen a verschiddene Kontexter anescht kodéiert ginn. D'Sich no Substrings, zum Beispill, muss gemaach ginn andeems Dir dëst berücksichtegt, an net nëmmen duerch Vergläicher vu Bytes. Zweetens, soubal mir d'Alfabet geännert hunn, ass et schlecht ginn mat der Kodéierung vun ASCII Zeechen (an dëst ass net nëmmen dat laténgescht Alphabet, awer och Basis Punktuatioun, dorënner Plazen) - se brauchen d'Alphabet erëm op 0 z'änneren, dat heescht, erëm en extra Byte (an dann nach een fir op eisen Haaptpunkt zréckzekommen).

Een Alphabet ass gutt, zwee ass besser

Loosst eis probéieren eis Bit Präfixe e bëssen z'änneren, an e méi vun den dräi uewen beschriwwen ze pressen:

0xxxxxxx - 1 Byte am normale Modus, 2 am laange Modus
11xxxxxx — 1 Byt
100xxxxx xxxxxxxx - 2 Bytes
101xxxxx xxxxxxxx xxxxxxxx - 3 Bytes

Elo an engem Zwee-Byte-Rekord gëtt et ee manner verfügbare Bit - Code Punkten bis 0x1FFF, an net 0x3FFF. Wéi och ëmmer, et ass nach ëmmer merkbar méi grouss wéi an Duebelbyte UTF-8 Coden, déi meescht üblech Sprooche passen nach ëmmer an, de merkbarsten Verloscht ass erausgefall hiragana и katakana, d'Japaner sinn traureg.

Wat ass dësen neie Code? 11xxxxxx? Dëst ass e klengen "Stash" vu 64 Zeechen an der Gréisst, et ergänzt eis Haaptalfabet, also hunn ech et auxiliary genannt (auxiliary) Alphabet. Wa mir dat aktuellt Alphabet wiesselen, gëtt e Stéck vum alen Alphabet Auxiliary. Zum Beispill hu mir vun ASCII op Kyrillesch gewiesselt - de Stash enthält elo 64 Zeechen mat Latäin Alphabet, Zuelen, Raum a Komma (heefegste Insertiounen an Net-ASCII Texter). Wiesselt zréck op ASCII - an den Haaptdeel vum kyrillesche Alphabet gëtt zum Hilfsalfabet.

Duerch den Zougang zu zwee Alphabete kënne mir eng grouss Unzuel vun Texter mat minimalem Käschte fir Alphabeten ëmsetzen (Punctuatioun féiert meeschtens zu engem Retour op ASCII, awer duerno kréie mir vill net-ASCII Zeechen aus dem zousätzleche Alphabet, ouni erëm wiesselen).

Bonus: Präfix vum Ënner-Alfabet 11xxxxxx a wielt seng initial Offset ze sinn 0xC0, mir kréien deelweis Kompatibilitéit mat CP1252. An anere Wierder, vill (awer net all) westeuropäesch Texter, déi am CP1252 kodéiert sinn, wäerten d'selwecht an UTF-C ausgesinn.

Hei entsteet awer eng Schwieregkeet: Wéi kritt een en Auxiliary aus dem Haaptalfabet? Dir kënnt dee selwechte Offset verloossen, awer - leider - hei spillt d'Unicode Struktur scho géint eis. Ganz dacks ass den Haaptdeel vum Alphabet net am Ufank vum Block (zum Beispill, déi russesch Haaptstad "A" huet de Code 0x0410, obwuel de kyrillesche Block ufänkt mat 0x0400). Also, nodeems mir déi éischt 64 Zeechen an d'Stash geholl hunn, kënne mir den Zougang zum Schwanzdeel vum Alphabet verléieren.

Fir dëse Problem ze fixéieren, sinn ech manuell duerch e puer Blocks duerchgaang, déi zu verschiddene Sproochen entspriechen, an hunn d'Offset vum Hilfsalfabet am Haaptalfabet fir si spezifizéiert. Dat laténgescht Alfabet, als Ausnam, gouf allgemeng nei bestallt wéi base64.

Finale Touch

Loosst eis endlech iwwerdenken, wou mir soss eppes kënne verbesseren.

Notéiert datt d'Format 101xxxxx xxxxxxxx xxxxxxxx erlaabt Iech Zuelen ze codéieren bis 0x1FFFFF, an Unicode endet fréier, um 0x10FFFF. An anere Wierder, wäert de leschte Code Punkt vertruede ginn als 10110000 11111111 11111111. Dofir kënne mir soen datt wann den éischte Byte vun der Form ass 1011xxxx (Wou xxxx méi wéi 0), dann heescht et soss eppes. Zum Beispill kënnt Dir nach 15 Zeechen do addéieren, déi stänneg fir Kodéierung an engem Byte verfügbar sinn, awer ech hunn decidéiert et anescht ze maachen.

Loosst eis dës Unicode Blocks kucken, déi elo dräi Bytes erfuerderen. Prinzipiell, wéi scho gesot, sinn dës chinesesch Charaktere - awer et ass schwéier eppes mat hinnen ze maachen, et sinn 21 Tausend vun hinnen. Awer hiragana a katakana sinn och dohinner geflunn - an et sinn net méi sou vill, manner wéi zweehonnert. A well mir d'Japaner erënnert hunn, ginn et och Emojis (tatsächlech sinn se op ville Plazen an Unicode verspreet, awer d'Haaptblocken sinn am Beräich 0x1F300 - 0x1FBFF). Wann Dir un d'Tatsaach denkt datt et elo Emojis sinn déi aus verschiddene Codepunkte gläichzäiteg zesummegesat ginn (zum Beispill den Emoji ‍‍‍ besteet aus esou vill wéi 7 Coden!), Da gëtt et komplett schued dräi Bytes op all eent ze verbréngen (7 × 3 = 21 Bytes fir d'Wuel vun enger Ikon, engem Albdram).

Dofir wielt e puer ausgewielte Beräicher entspriechend Emoji, Hiragana a Katakana, numeréieren se an eng kontinuéierlech Lëscht a codéiere se als zwee Bytes anstatt dräi:

1011xxxx xxxxxxxx

Super: dee sougenannten Emoji, besteet aus 7 Code Punkten, hëlt 8 Bytes an UTF-25, a mir passen et an 14 (genau zwee Bytes fir all Code Punkt). Iwwregens, Habr refuséiert et ze verdauen (souwuel am alen wéi och am neien Editor), also ech hu missen et mat enger Foto asetzen.

Loosst eis probéieren ee méi Problem ze fixéieren. Wéi mir eis erënneren, ass d'Basis Alphabet am Wesentlechen héich 6 bëssen, déi mir am Kapp behalen an un de Code vun all nächst decodéiert Symbol gekollt. Am Fall vu chinesesche Charakteren déi am Block sinn 0x4E00 - 0x9FFF, dëst ass entweder Bit 0 oder 1. Dëst ass net ganz bequem: mir mussen d'Alphabet stänneg tëscht dësen zwee Wäerter wiesselen (dh dräi Bytes verbréngen). Awer bemierkt datt am laange Modus, aus dem Code selwer, d'Zuel vun den Zeeche subtrahéiere kënnen, déi mir am Kuerzmodus codéieren (no all den Tricken uewen beschriwwen, dat ass 10240) - da wäert d'Band vun den Hieroglyphen op 0x2600 - 0x77FF, an an dësem Fall, an dësem ganze Beräich, wäerten déi bedeitendst 6 Bits (vun 21) gläich sinn 0. Sou wäerte Sequenzen vun Hieroglyphen zwee Bytes pro Hieroglyph benotzen (wat fir esou eng grouss Gamme optimal ass), ouni Ursaach Alphabet Schalter.

Alternativ Léisungen: SCSU, BOCU-1

Unicode Experten, nodeems se just den Titel vum Artikel gelies hunn, wäerte méiglecherweis séier drun erënneren datt et direkt ënner den Unicode Standarden ass Standard Kompressiounsschema fir Unicode (SCSU), déi eng Kodéierungsmethod ganz ähnlech wéi déi am Artikel beschriwwen beschreift.

Ech ginn éierlech zou: Ech hunn iwwer seng Existenz eréischt geléiert nodeems ech déif an d'Schreiwen vun menger Entscheedung ënnerworf war. Wann ech dat vun Ufank un gewosst hätt, hätt ech wahrscheinlech probéiert eng Implementatioun ze schreiwen anstatt meng eegen Approche ze kommen.

Wat interessant ass, ass datt SCSU Iddie benotzt ganz ähnlech wéi déi, déi ech eleng erstallt hunn (amplaz vum Konzept vun "Alphabeten" benotze se "Fënsteren", an et gi méi verfügbar wéi ech hunn). Zur selwechter Zäit huet dëst Format och Nodeeler: et ass e bësse méi no un d'Kompressiounsalgorithmen wéi d'Kodéierung. Besonnesch gëtt de Standard vill Representatiounsmethoden, awer seet net wéi Dir déi optimal wielt - dofir muss den Encoder eng Art Heuristik benotzen. Also, e SCSU Encoder dee gutt Verpakung produzéiert wäert méi komplex a méi ëmständlech sinn wéi mäi Algorithmus.

Zum Verglach hunn ech eng relativ einfach Implementatioun vu SCSU op JavaScript iwwerginn - wat de Codevolumen ugeet, huet et sech vergläichbar mat menger UTF-C erausgestallt, awer an e puer Fäll war d'Resultat zéng Prozent méi schlëmm (heiansdo kann et iwwerschreiden, awer net vill). Zum Beispill, Texter op Hebräesch a Griichesch goufen duerch UTF-C kodéiert 60% besser wéi SCSU (wahrscheinlech wéinst hire kompakten Alphabeten).

Separat wäert ech addéieren datt nieft SCSU et och eng aner Manéier gëtt fir Unicode kompakt ze representéieren - BOCU-1, awer et zielt fir MIME Kompatibilitéit (déi ech net gebraucht hunn) an hëlt eng liicht aner Approche fir d'Kodéierung. Ech hunn seng Effektivitéit net bewäert, awer et schéngt mir datt et onwahrscheinlech méi héich ass wéi SCSU.

Méiglech Verbesserungen

Den Algorithmus, deen ech presentéiert hunn, ass net universell vum Design (dëst ass méiglecherweis wou meng Ziler am meeschte vun den Ziler vum Unicode Consortium divergéieren). Ech hu scho gesot datt et haaptsächlech fir eng Aufgab entwéckelt gouf (e méisproochegt Wierderbuch an engem Präfixbaum späicheren), an e puer vu senge Funktiounen kënnen net gutt fir aner Aufgaben passen. Awer de Fakt datt et kee Standard ass kann e Plus sinn - Dir kënnt et einfach änneren fir Äre Besoinen ze passen.

Zum Beispill, op déi offensichtlech Manéier kënnt Dir vun der Präsenz vum Staat lassgoen, stateless Kodéierung maachen - just d'Verännerlechen net aktualiséieren offs, auxOffs и is21Bit am Encoder an Decoder. An dësem Fall wäert et net méiglech sinn effektiv Sequenzen vun Zeechen vum selwechte Alphabet ze packen, awer et gëtt eng Garantie datt dee selwechte Charakter ëmmer mat de selwechte Bytes kodéiert ass, onofhängeg vum Kontext.

Zousätzlech kënnt Dir den Encoder op eng spezifesch Sprooch personaliséieren andeems Dir de Standardzoustand ännert - zum Beispill, op russesch Texter fokusséieren, den Encoder an den Decoder am Ufank setzen offs = 0x0400 и auxOffs = 0. Dëst mécht besonnesch Sënn am Fall vun stateless Modus. Am Allgemengen wäert dëst ähnlech sinn wéi déi al Aacht-Bit Kodéierung ze benotzen, awer ouni d'Fähigkeit ze läschen fir Zeeche vun all Unicode anzeginn wéi néideg.

En aneren Nodeel, dee virdru erwähnt gouf, ass datt am groussen Text kodéiert an UTF-C kee séiere Wee gëtt fir d'Zeechengrenz am nootste bei engem arbiträren Byte ze fannen. Wann Dir déi lescht, sot, 100 Bytes vum kodéierte Puffer ofgeschnidden hutt, riskéiert Dir Dreck ze kréien, mat deem Dir näischt maache kënnt. D'Kodéierung ass net entwéckelt fir Multi-Gigabyte Logbicher ze späicheren, awer allgemeng kann dëst korrigéiert ginn. Byte 0xBF däerf ni als éischten Byte erschéngen (awer kann den zweeten oder drëtten sinn). Dofir, wann Dir kodéiert, kënnt Dir d'Sequenz aginn 0xBF 0xBF 0xBF all, soen, 10 KB - dann, wann Dir braucht eng Grenz ze fannen, et wäert genuch ginn der gewielter Stéck ze scannen bis eng ähnlech Marker fonnt ass. No der leschter 0xBF ass garantéiert den Ufank vun engem Charakter. (Beim Dekodéierung muss dës Sequenz vun dräi Bytes natierlech ignoréiert ginn.)

Zesummefaassung

Wann Dir esou wäit gelies hutt, Gratulatioun! Ech hoffen Dir, wéi ech, eppes Neies geléiert (oder Är Erënnerung erfrëscht) iwwer d'Struktur vun Unicode.

Demo Säit. D'Beispill vun Hebräesch weist d'Virdeeler iwwer béid UTF-8 an SCSU.

Déi uewe beschriwwe Fuerschung sollt net als Iwwergrëff op Standarden ugesi ginn. Wéi och ëmmer, ech sinn allgemeng zefridden mat de Resultater vu menger Aarbecht, also sinn ech frou mat hinnen deelen: zum Beispill, eng minifizéiert JS Bibliothéik weit nëmmen 1710 Bytes (an huet natierlech keng Ofhängegkeeten). Wéi ech uewen ernimmt, hir Aarbecht kann op fonnt ginn Demo Säit (et gëtt och eng Rei vun Texter op deenen et mat UTF-8 an SCSU verglach ka ginn).

Schlussendlech wäert ech nach eng Kéier op Fäll opmierksam maachen an deenen UTF-C benotzt gëtt net wäert:

• Wann Är Linnen laang genuch sinn (vun 100-200 Zeechen). An dësem Fall sollt Dir iwwer d'Benotzung vun Kompressiounsalgorithmen wéi Deflate denken.
• Wann Dir braucht ASCII Transparenz, dat heescht, et ass wichteg fir Iech datt déi kodéiert Sequenzen keng ASCII Coden enthalen déi net an der ursprénglecher String waren. De Besoin fir dëst kann vermeit ginn wann Dir, wann Dir mat Drëtt Partei APIen interagéiert (zum Beispill, mat enger Datebank schafft), Dir d'Kodéierungsresultat als abstrakt Set vu Bytes passéiert an net als Saiten. Soss riskéiert Dir onerwaart Schwächen ze kréien.
• Wann Dir wëllt séier Charakter Grenzen op eng arbiträr Offset ze fannen (Zum Beispill, wann en Deel vun enger Linn beschiedegt ass). Dëst kann gemaach ginn, awer nëmmen andeems Dir d'Linn vun Ufank un scannt (oder d'Ännerung an der viregter Sektioun applizéiert).
• Wann Dir séier Operatiounen op den Inhalt vu Strings maache musst (sortéieren, sichen no Ënnerstringen an hinnen, concatenate). Dëst erfuerdert Strings fir d'éischt dekodéiert ze ginn, sou datt UTF-C an dëse Fäll méi lues ass wéi UTF-8 (awer méi séier wéi Kompressiounsalgorithmen). Zënter datt dee selwechte String ëmmer op déiselwecht Manéier kodéiert ass, ass de genaue Verglach vun der Dekodéierung net erfuerderlech a kann op Byte-by-Byte Basis gemaach ginn.

Aktualiséierung: de Benotzer Tyomitch an de Kommentaren hei drënner huet eng Grafik gepost déi d'Uwendbarkeetsgrenze vun UTF-C beliicht. Et weist datt UTF-C méi effizient ass wéi en allgemeng Zweck Kompressiounsalgorithmus (eng Variatioun vu LZW) soulaang de gepackte String méi kuerz ass ~140 Zeechen (Ech bemierken awer datt de Verglach op engem Text duerchgefouert gouf; fir aner Sproochen kann d'Resultat ënnerscheeden).


Source: will.com