{"id":95911,"date":"2020-10-05T01:42:09","date_gmt":"2020-10-04T23:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/eshhyo-odin-velosiped-hranim-yunikodnye-stroki-na-30-60-kompaktnee-chem-utf-8"},"modified":"2020-10-05T01:42:09","modified_gmt":"2020-10-04T23:42:09","slug":"eshhyo-odin-velosiped-hranim-yunikodnye-stroki-na-30-60-kompaktnee-chem-utf-8","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/eshhyo-odin-velosiped-hranim-yunikodnye-stroki-na-30-60-kompaktnee-chem-utf-8","title":{"rendered":"Veel \u00fcks jalgratas: salvestame Unicode'i stringid 30-60% kompaktsemalt kui UTF-8","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Veel
\n
\nKui olete arendaja ja silmitsi valikuga kodeeringu osas, siis peaaegu alati on \u00f5ige lahendus Unicode. Konkreetne esitamise meetod s\u00f5ltub kontekstist, kuid enamasti on siin samuti universaalne vastus \u2014 UTF-8. See on hea seet\u00f5ttu, et v\u00f5imaldab kasutada k\u00f5iki Unicode'i m\u00e4rke, kulutamata liialt<\/em> palju baite enamikul juhtudel. T\u00f5si, keelte puhul, mis ei kasuta ainult ladina t\u00e4hestikku, t\u00e4hendab \u201eliialt v\u00e4he\u201d v\u00e4hemalt kaht byte'i s\u00fcmboli kohta<\/strong>. Kas on v\u00f5imalik paremini, naasmata eelajaloolistesse kodeeringutesse, mis piiravad meid vaid 256 saadaval s\u00fcmboliga?<\/p>\n

Allpool pakun v\u00e4lja oma katse anda sellele k\u00fcsimusele vastus ja teostada suhteliselt lihtne algoritm, mis v\u00f5imaldab salvestada ridu enamikus maailma keeltes, lisamata neid \u00fcleliigseid koormusi, mis on omased UTF-8-le.<\/a><\/noindex><\/p>\n

\u00c4ratus.<\/i> T\u00f5in esile mitmeid olulisi juhtn\u00f6\u00f6re: kirjeldatud lahendust ei pakuta universaalse asendusena UTF-8-le<\/strong>, see sobib vaid kitsas nimekirjas juhtudest (millest kirjutan allpool), ja seda ei tohi mingil juhul kasutada kolmandate osapoolte API-dega suhtlemiseks (kes sellest isegi ei tea). Enamasti sobivad suure hulga tekstiliste andmete kompaktseks hoidmiseks \u00fcldotstarbelised tihendamisalgoritmid (n\u00e4iteks deflate). Lisaks leidsin juba oma lahenduse loomise k\u00e4igus olemasoleva standardi ise Unicode'is, mis lahendab sama \u00fclesande \u2014 see on veidi keerulisem (ja tihti kehvem), kuid siiski vastuv\u00f5etud standard, mitte jalgaastatud lahendus. Kannan ka sellest teada.<\/p>\n

Unicode ja UTF-8<\/h2>\n

\nAlustuseks \u2014 paar s\u00f5na sellest, mis see \u00fcldiselt on Unicode<\/strong> ja UTF-8<\/strong>.<\/p>\n

Kuidas on teada, olid varem populaarsed 8-bitised kodeeringud. Nendega oli k\u00f5ik lihtne: 256 s\u00fcmbolit saab nummerdada numbritega vahemikus 0 kuni 255, ning numbrid vahemikus 0 kuni 255 on selgelt esitatavad \u00fche baidina. Kui minna tagasi algusesse, siis ASCII kodeering piirneb isegi 7 bitiga, seega on selle baidiesituses k\u00f5ige vanem bit null, ja enamik 8-bitisi kodeeringuid on sellega \u00fchilduvad (need erinevad ainult \u201e\u00fclemises\u201d osas, kus vanem bit on \u00fcks).<\/p>\n

Kuidas eristub Unicode neist kodeeringutest ja miks on sellega seotud korraga mitmed konkreetsed esitused \u2014 UTF-8, UTF-16 (BE ja LE), UTF-32? Selgitame j\u00e4rjest.<\/p>\n

Peamine Unicode'i standard kirjeldab ainult vastavust t\u00e4hem\u00e4rkide (ja m\u00f5nel juhul - t\u00e4hem\u00e4rkide eraldi komponentide) ja nende numbrite vahel. Ja v\u00f5imalikke numbreid selles standardis on v\u00e4ga palju - alates 0x00<\/b><\/code> kuni 0x10FFFF<\/b><\/code> (1 114 112 t\u00fckki). Kui me tahaksime sellises vahemikus arvu muutuja sisse panna, ei piisaks meile ei 1 ega 2 baitist. Ja kuna meie protsessorid ei ole kolmbaitsete arvudega v\u00e4ga harjutanud, oleksime sunnitud kasutama terveid 4 baiti \u00fche t\u00e4hem\u00e4rgi jaoks! Just see ongi UTF-32, kuid just selle \"rahakulu\" t\u00f5ttu ei ole see formaat populaarne.<\/p>\n

\u00d5nneks ei ole Unicode'i t\u00e4hem\u00e4rgid korduvad juhuslikult. Nende suur hulk on jaotatud 17 \u00abtasandisse<\/em>\u00bb, millest iga\u00fcks sisaldab 65536 (0x10000<\/b><\/code>) \u00abkoodipunkti<\/em>\u00bb. M\u00f5isted \u201ekoodipunkt\u201d t\u00e4histab siin lihtsalt t\u00e4hem\u00e4rgi numbrit<\/em>, mille Unicode on talle m\u00e4\u00e4ranud. Kuid nagu eespool mainitud, on Unicode'is nummerdatud mitte ainult eraldi t\u00e4hem\u00e4rgid, vaid ka nende komponendid ja teenindusm\u00e4rkmed (ja m\u00f5nikord ei vasta number \u00fcldse millelegi - v\u00f5ib-olla ajutiselt, kuid meile pole see niiv\u00f5rd oluline), seega on korrektsem alati r\u00e4\u00e4kida just numbrite koguarvust, mitte t\u00e4hem\u00e4rkidest. Siiski, edaspidigi kasutan sageli s\u00f5na \u201et\u00e4hem\u00e4rk\u201d, silmas pidades m\u00f5istet \u201ekoodipunkt\u201d.<\/p>\n

\"Veel
\nUnicode'i tasandid. Nagu n\u00e4ha, on suur osa (tasandid 4 kuni 13) endiselt kasutamata.<\/i><\/p>\n

Mis k\u00f5ige t\u00e4helepanuv\u00e4\u00e4rsem on see, et kogu peamine \"sisu\" asub nulltasemel, seda nimetatakse \"Basic Multilingual Plane<\/em>\". Kui rida sisaldab teksti \u00fches kaasaegses keeles (sealhulgas hiina keeles), ei saa te sellest tasemest v\u00e4lja minna. Kuid ka \u00fclej\u00e4\u00e4nud Unicode'i osa ei tohi eemaldada \u2014 n\u00e4iteks emoji'd asuvad peamiselt j\u00e4rgmise taseme l\u00f5pupoole \"Supplementary Multilingual Plane<\/em>\" (see ulatub alates 0x10000<\/b><\/code> kuni 0x1FFFF<\/b><\/code>). Seet\u00f5ttu k\u00e4itub UTF-16 nii: k\u00f5ik t\u00e4hem\u00e4rgid, mis j\u00e4\u00e4vad Basic Multilingual Plane<\/em>, kodeeritakse \u201enagu on\u201d, nende vastav kahekohaline number. Kuid osa numbritest selles vahemikus ei t\u00e4hista \u00fcldse konkreetseid t\u00e4hem\u00e4rke, vaid osutavad sellele, et p\u00e4rast seda kaht baidi paari tuleb vaadata veel \u00fchte - kombineerides nende nelja baidi v\u00e4\u00e4rtused, saame numbri, mis katab kogu lubatud Unicode'i vahemiku. Seda esitusviisi nimetatakse \u201esuurte paarideks\u201d - v\u00f5ib-olla olete neist kuulnud.<\/p>\n

Seega, UTF-16 n\u00f5uab \u00fche \"koodipunkti\" jaoks kahte v\u00f5i (v\u00e4ga harvadel juhtudel) neli baiti. See on parem kui pidev nelja baitide kasutamine, kuid ladina t\u00e4hestiku (ja teiste ASCII-m\u00e4rkide) puhul kulutab see sellise kodeerimisega pool salvestatud ruumist nullidele. UTF-8 on loodud seda parandama: ASCII v\u00f5tab seal nagu varem ainult \u00fche bait; koodid alates 0x80<\/b><\/code> kuni 0x7FF<\/b><\/code> \u2014 kahest baitist; alates 0x800<\/b><\/code> kuni 0xFFFF<\/b><\/code> \u2014 kolmest ja alates 0x10000<\/b><\/code> kuni 0x10FFFF<\/b><\/code> \u2014 neljast. \u00dchelt poolt on ladina t\u00e4hestikul n\u00fc\u00fcd h\u00e4sti: tagasiviidatud \u00fchildus ASCII-ga, ning jaotus on \u00fchtlasemalt \"jaotatud\" 1 kuni 4 baidi vahel. Kuid ladina t\u00e4hestikust erinevad t\u00e4hestikud, kahjuks, ei saa UTF-16-ga v\u00f5rreldes midagi v\u00f5ita, ja paljud n\u00f5uavad n\u00fc\u00fcd kolmandat bait; kahe baitiga kirje katab vahemiku 32 korda v\u00e4henenud, ulatudes 0xFFFF<\/b><\/code> kuni 0x7FF<\/b><\/code>, ja see ei h\u00f5lma enam hiina keelt ega n\u00e4iteks gruusi keelt. Kirillitsa ja veel viiele t\u00e4hestikule \u2014 uh-huh \u2014 vedas, 2 baiti s\u00fcmboli kohta.<\/p>\n

Kuidas see siis v\u00e4lja tuleb? Vaatame, kuidas UTF-8 esindab s\u00fcmbolite koode:
\n\"Veel
\nNumbrite otseseks esitamiseks on siin kasutatud bitte, t\u00e4histatud s\u00fcmboliga x<\/b><\/code>. On n\u00e4ha, et kahe baitiga kirjes on selliseid bitte vaid 11 (16-st). Esialgsed bitid kannavad siin ainult teeninduslikku funktsiooni. Nelja baitiga kirje puhul on koodipunkti number m\u00e4\u00e4ratud t\u00e4ielikult 21 bitile 32-st \u2013 n\u00e4iliselt peaks siin piisama kolmest baitist (mis annab kokku 24 bitti), kuid teenindusm\u00e4rgid v\u00f5tavad liiga palju ruumi.<\/p>\n

Kas see on halb? Tegelikult mitte. \u00dchelt poolt \u2013 kui me hoolime v\u00e4ga salvestusruumist, on meil olemas tihendamisalgoritmid, mis k\u00f5rvaldavad kergesti kogu liigse entropia ja \u00fcleliigsuse. Teiselt poolt \u2013 Unicode eesm\u00e4rk oli anda v\u00f5imalikult universaalne kodeerimine. N\u00e4iteks v\u00f5ime UTF-8-s kodeeritud stringi usaldada koodile, mis t\u00f6\u00f6tas varem ainult ASCII-ga, ja ei muretse, et seal n\u00e4eb s\u00fcmbolit ASCII vahemikust, mida seal tegelikult ei ole (sest UTF-8-s on k\u00f5ik baitid, mis algavad nullbitiga \u2013 need ongi ASCII). Ja kui me tahame \u00e4kki suurt stringist m\u00f5ne v\u00e4ikese saba \u00e4ra l\u00f5igata, ilma et me seda algusest peale dekodeeriksime (v\u00f5i taastaksime teavet p\u00e4rast kahjustatud osa) \u2013 ei ole meil keeruline leida seda nihke kohta, kust m\u00f5ni s\u00fcmbol algab (piisab, kui m\u00f6\u00f6da minna baitsidest, millel on bittide eellane 10<\/b><\/code>).<\/p>\n

Miks siis midagi uut v\u00e4lja m\u00f5elda?<\/h2>\n

\nSamas ajal esineb harva olukordi, kus kokkusurumisalgoritmid nagu deflate ei ole h\u00e4sti rakendatavad, kuid soov on saavutada kompaktsed stringide salvestamise vormid. Isiklikult olen sellise \u00fclesande ees seisnud, kui olen m\u00f5elnud kokkusurutud prefikspuu<\/a><\/noindex> suure s\u00f5navara jaoks, mis sisaldab s\u00f5nu erinevates keeltes. \u00dchelt poolt on iga s\u00f5na v\u00e4ga l\u00fchike, seega on selle kokkusurumine ebaefektiivne. Teiselt poolt - puu realiseerimine, millele ma m\u00f5tlesin, eeldas, et iga salvestatud stringi bait genereeris eraldi puu tipu, mist\u00f5ttu oli nende arvu v\u00e4hendamine v\u00e4ga kasulik. Minu teegis Az.js<\/a><\/noindex> (nagu ka pymorphy2<\/a><\/noindex>, millele see p\u00f5hineb) selline probleem lahendatakse lihtsalt - stringid, mis on pakitud DAWG<\/a><\/noindex>-s\u00f5naraam, s\u00e4ilitatakse seal vana hea CP1251<\/a><\/noindex>. Kuid nagu on lihtne m\u00f5ista, t\u00f6\u00f6tab see h\u00e4sti ainult piiratud t\u00e4hestikuga - hiina stringi sellesse s\u00f5naraamatusse ei saa juba paigutada.<\/p>\n

Eraldi m\u00e4rgin veel \u00fche ebameeldiva n\u00fcansi, mis tekib UTF-8 kasutamisel sellises andmestruktuuris. \u00dclaltoodud pildilt on n\u00e4ha, et kui s\u00fcmbolit salvestatakse kahe baitina, siis selle numbri bitid ei paikne j\u00e4rjestikku, vaid on katkenud paari bitti 10<\/b><\/code> vahepeal: 110xxxxx 10xxxxxx<\/b><\/code>. Selle t\u00f5ttu, kui s\u00fcmboli koodis \u00fcletatakse teise baidi madalamad 6 bitti (st toimub \u00fcleminek 10111111<\/b><\/code> \u2192 10000000<\/b><\/code>), muutub ka esimene bait. Tulemuseks on, et t\u00e4ht \u201e\u043f\u201d t\u00e4histatakse baitidega 0xD0 0xBF<\/b><\/code>, ja j\u00e4rgmine \u201e\u0440\u201d juba 0xD1 0x80<\/b><\/code>. Prefikspuus p\u00f5hjustab see vanema tipu jagunemise kaheks - \u00fcheks prefiksi 0xD0<\/b><\/code>, ja teiseks 0xD1<\/b><\/code> (kuigi kogu kirillitsa v\u00f5iks kodeerida ainult teise baidi kaudu).<\/p>\n

Mida ma sain<\/h2>\n

\nSelle \u00fclesande ees seistes otsustasin natuke m\u00e4ngida bittidega ja samal ajal tutvuda paremini Unicode'i struktuuriga. Tulemuseks sai koodimisformaat UTF-C (\u201eC\u201d t\u00e4histab compact<\/em>), mis kulutab \u00fche koodipunkti jaoks mitte \u00fcle 3 baidi ning sageli v\u00f5imaldab kulutada vaid \u00fche lisabait terve kodeeritud stringi peale.<\/strong>See toob kaasa selle, et paljude mitte-ASCII t\u00e4hestike korral osutub selline kodeering 30-60% kompaktselt kui UTF-8.<\/strong>.<\/p>\n

Olen vormistatud koodimise ja dekodeerimise algoritmide n\u00e4idised teekidena JavaScriptis ja Go-s.<\/a><\/noindex>, v\u00f5ite neid oma koodis vabalt kasutada. Kuid tahaksin siiski r\u00f5hutada, et teataval m\u00e4\u00e4ral j\u00e4\u00e4b see formaat \u201ejalgrattaks\u201d ja ma ei soovita seda kasutada ilmse arusaamata, miks see teile vajalik on<\/strong>. See on siiski pigem eksperiment kui t\u00f5sine \u201eUTF-8 t\u00e4iustamine\u201d. Sellegipoolest on sealne kood kirjutatud korralikult, kompaktsetena, koos rohkete kommentaaride ja katsetega.<\/p>\n

\"Veel
\nTestide tulemused ja v\u00f5rdlus UTF-8-ga<\/i><\/p>\n

Lisaks tegin ma demonstreerimise lehe<\/a><\/noindex>, kus saab hinnata algoritmi t\u00f6\u00f6d, ja hiljem r\u00e4\u00e4gin selle p\u00f5him\u00f5tetest ja v\u00e4ljat\u00f6\u00f6tamisprotsessist \u00fcksikasjalikumalt.<\/p>\n

Eemaldame \u00fcleliigsed bitid<\/h2>\n

\nAluseks v\u00f5tsin loomulikult UTF-8. Esimene ja ilmselge asi, mida seal muuta saab \u2014 v\u00e4hendada teenindusbitide arvu igas baitis. N\u00e4iteks hakkab esimene bait UTF-8-s alati kas 0<\/b><\/code>, v\u00f5i 11<\/b><\/code> \u2014 ja prefiks 10<\/b><\/code> on ainult j\u00e4rgnevate baitide jaoks. Asendame prefiksi 11<\/b><\/code> . Tundub, et 1<\/b><\/code>, ja j\u00e4rgmiste baitide puhul eemaldame prefiksid t\u00e4ielikult. Mis juhtub?<\/p>\n

0xxxxxxx<\/b><\/code> \u2014 1 bait
\n10xxxxxx xxxxxxxx<\/b><\/code> \u2014 2 baiti
\n110xxxxx xxxxxxxx xxxxxxxx<\/b><\/code> \u2014 3 baiti<\/p>\n

Peatus, aga kus on nelja-baitline kirje? See pole enam vajalik \u2014 kolme baitiga kirjutamisel on meil n\u00fc\u00fcd 21 bitti ja seda piisab kuni 0x10FFFF<\/b><\/code>.<\/p>\n

Mida me siin ohverdasime? Peamine \u2014 s\u00fcmbolite piiride avastamine juhuslikust buffri kohast. Me ei saa torkida juhuslikku baidi ja leida sealt j\u00e4rgmise s\u00fcmboli algust. See on meie formaadi piirang, kuid praktikas ei esine sellist vajadust tihti. \u00dcldiselt saame p\u00fcsida buffri algusest alates (eriti kui on tegemist l\u00fchikeste ridadega).<\/p>\n

Kaks baitide katvuse olukord on ka paranenud: n\u00fc\u00fcd annab kaheettev\u00f5tmise formaat 14 bitist vahemiku, mis katab koodid kuni 0x3FFF<\/b><\/code>. Hiinlastel ei vea (nende ideogrammid asuvad peamiselt vahemikus 0x4E00<\/b><\/code> kuni 0x9FFF<\/b><\/code>), kuid gruusia rahvas ja paljud teised on n\u00fc\u00fcd \u00f5nnelikumad \u2014 nende keeled mahuvad samuti 2 baiti s\u00fcmboli kohta.<\/p>\n

Sissev\u00f5ttes oleme dekooder<\/h2>\n

\nN\u00fc\u00fcd m\u00f5tleme ridade omadustele. S\u00f5naraamatus on sageli s\u00f5nad, mis on kirjutatud \u00fche t\u00e4htede alfabeediga, ja paljude teiste tekstide puhul on see samuti t\u00f5si. Oleks hea korra n\u00e4idata see alfabet, ja seej\u00e4rel n\u00e4idata ainult t\u00e4htede numbrit selle sees. Vaadakem, kas Unicode'i tabelis olevad s\u00fcmbolite asukohad aitavad meid.<\/p>\n

Nagu \u00fclalpool mainitud, on Unicode jagatud tasanditeks<\/em> koodide iga 65536. Kuid see ei ole eriti kasulik jaotus (nagu juba mainitud, oleme enamasti nulltasemel). Huvi pakkub jaotus plokkideks.<\/em> Need vahemikud ei ole enam fikseeritud pikkusega ja omavad rohkem t\u00e4hendust \u2014 reeglina koondavad nad sama t\u00e4hestiku s\u00fcmbolid.<\/p>\n

\"Veel
\nPlokk, mis sisaldab bengali t\u00e4hestiku s\u00fcmboleid. Kahjuks on ajaloolistel p\u00f5hjustel see n\u00e4ide \u00fcsna eba\u00fchtlasest pakkimisest \u2014 96 s\u00fcmbolit on juhuslikult hajutatud 128 koodipunkti vahel plokis.<\/i><\/p>\n

Plokkide algused ja nende suurused on alati 16-kordsed \u2014 see on lihtsalt mugavuse t\u00f5ttu. Lisaks, paljud plokid algavad ja l\u00f5ppevad v\u00e4\u00e4rtustes, mis on 128 v\u00f5i isegi 256 kordne \u2013 n\u00e4iteks, p\u00f5hikirillika h\u00f5ivab 256 baiti alates 0x0400<\/b><\/code> kuni 0x04FF<\/b><\/code>. See on \u00fcsna mugav: kui salvestame kordumatu prefiksi 0x04<\/b><\/code>, siis saame igat kirillika s\u00fcmbolit kirjutada \u00fche baitiga. T\u00f5si, me kaotame v\u00f5imaluse tagasi p\u00f6\u00f6rduda ASCII (ja \u00fcksk\u00f5ik milliste teiste s\u00fcmbolite) juurde. Seega teeme j\u00e4rgmist:<\/p>\n

    \n
  1. Kaks baiti 10yyyyyy yxxxxxxx<\/b><\/code> ei t\u00e4hista mitte ainult s\u00fcmbolit numbriga yyyyyy yxxxxxxx<\/b><\/code>, vaid muudavad kehtivat t\u00e4hestikku<\/em> . Tundub, et yyyyyy y0000000<\/b><\/code> (st me salvestame k\u00f5ik bitid, v\u00e4lja arvatud madalamad 7 bitti<\/strong>);<\/li>\n
  2. \u00dcks bait 0xxxxxxx<\/b><\/code> on kehtiva t\u00e4hestiku s\u00fcmbol. Selle tuleb lihtsalt liita selle nihkega, mille me salvestasime sammul 1. Seni, kuni me t\u00e4hestikku ei muuda, on nihke v\u00e4\u00e4rtus null, seega oleme ASCII-ga \u00fchilduvad.<\/li>\n<\/ol>\n

    \nSarnaselt koodide puhul, mis n\u00f5uavad 3 bait:<\/p>\n

      \n
    1. Kolm baiti 110yyyyy yxxxxxxx xxxxxxxx<\/b><\/code> t\u00e4histavad s\u00fcmbolit numbriga yyyyyy yxxxxxxx xxxxxxxx<\/b><\/code>, muudab kehtivat t\u00e4hestikku<\/em> . Tundub, et yyyyyy y0000000 00000000<\/b><\/code> (salvestame k\u00f5ik, v\u00e4lja arvatud madalamad 15 bitti<\/strong>), ja seab m\u00e4rkeruumi, et oleme n\u00fc\u00fcd pikamas<\/em> re\u017eiimis (t\u00e4hestiku tagasi keeramisel kahekaupa, me t\u00fchistame selle m\u00e4rkeruumi);<\/li>\n
    2. Kaks baiti 0xxxxxxx xxxxxxxx<\/b><\/code> pikamas re\u017eiimis on see kehtiva t\u00e4hestiku s\u00fcmbol. Samuti liidame selle sammul 1 saadud nihkega. K\u00f5ik erinevused on vaid selles, et n\u00fc\u00fcd me loeme kahte baiti (sest me oleme sellesse re\u017eiimi \u00fcle l\u00e4inud).<\/li>\n<\/ol>\n

      \nTundub hea: n\u00fc\u00fcd, seni kuni peame kodeerima s\u00fcmboleid samas 7-bitises Unicode\u2019i vahemikus, kulutame \u00fche lisabaiti alguses ja vaid \u00fche baidi igas s\u00fcmbolis.<\/p>\n

      \"Veel
      \n\u00dche varase versiooni t\u00f6\u00f6. Juba sageli \u00fcletab UTF-8, kuid veel on t\u00e4iustamiseks ruumi.<\/i><\/p>\n

      Mis on halvenenud? Esiteks, meil on n\u00fc\u00fcd olek, nimelt kehtiva t\u00e4hestiku nihke<\/em> ja m\u00e4rkeruumi pikamas re\u017eiimis<\/em>. See, this additionally restricts us: now the same characters can be encoded differently in different contexts. For example, substring searches will have to take this into account, rather than just comparing bytes. Secondly, once we switched the alphabet, we faced issues with the encoding of ASCII characters (which include not only the Latin alphabet but also basic punctuation, including spaces)\u2014they require a re-switch of the alphabet at 0, meaning an extra byte again (and then another to return to our main one).<\/p>\n

      One alphabet is good, two is better<\/h2>\n

      \nLet's try to slightly change our bit prefixes by squeezing in one more alongside the three described above:<\/p>\n

      0xxxxxxx<\/b><\/code> \u2014 1 byte in normal mode, 2 in long mode
      \n11xxxxxx<\/b><\/code> \u2014 1 bait
      \n100xxxxx xxxxxxxx<\/b><\/code> \u2014 2 baiti
      \n101xxxxx xxxxxxxx xxxxxxxx<\/b><\/code> \u2014 3 baiti<\/p>\n

      \"Veel
      \n
      \nNow with two-byte encoding, there's one less available bit\u2014code points fit up to 0x1FFF<\/b><\/code>, mitte 0x3FFF<\/b><\/code>. However, it's still significantly more than in two-byte UTF-8 codes; the majority of common languages still fit in, the most noticeable loss is from       hiragana<\/a><\/noindex> ja katakana<\/a><\/noindex>, the Japanese are in sadness.<\/p>\n

      So what is the new code 11xxxxxx<\/b><\/code>? \u042d\u0442\u043e \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u00ab\u0437\u0430\u0433\u0430\u0448\u043d\u0438\u043a\u00bb \u0440\u0430\u0437\u043c\u0435\u0440\u043e\u043c \u0432 64 \u0441\u0438\u043c\u0432\u043e\u043b\u0430, \u043e\u043d \u0434\u043e\u043f\u043e\u043b\u043d\u044f\u0435\u0442 \u043d\u0430\u0448 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u0430\u043b\u0444\u0430\u0432\u0438\u0442, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u043d\u0430\u0437\u0432\u0430\u043b \u0435\u0433\u043e \u0432\u0441\u043f\u043e\u043c\u043e\u0433\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u043c (auxiliary<\/em>) alphabet. When we switch the current alphabet, a piece of the old alphabet becomes auxiliary. For example, switching from ASCII to Cyrillic means we now have 64 characters in the 'warehouse' containing the Latin alphabet, digits, a space, and a comma<\/strong> (the most common insertions in non-ASCII texts). Switching back to ASCII will make the main part of Cyrillic the auxiliary alphabet.<\/p>\n

      Thanks to access to two alphabets, we can handle a larger amount of text with minimal switching costs (punctuation will often lead to a return to ASCII, but after that, many non-ASCII characters will be retrieved from the additional alphabet, without re-switching).<\/p>\n

      Bonus: by designating the additional alphabet with a prefix 11xxxxxx<\/b><\/code> and setting its initial offset to 0xC0<\/b><\/code>, we achieve partial compatibility with CP1252. In other words, many (but not all) Western European texts encoded in CP1252 will appear the same in UTF-C.<\/p>\n

      Here, however, arises the challenge: how to derive an auxiliary alphabet from the main one? You can keep the same offset, but\u2014unfortunately\u2014Unicode structure plays against us here. Very often the main part of the alphabet is not at the beginning of the block (for example, the uppercase 'A' in Russian has code 0x0410<\/b><\/code>, kuigi ts\u00fcroliitne blokk algab 0x0400<\/b><\/code>). Nii et, v\u00f5ttes \u201evarustusse\u201c esimesed 64 s\u00fcmbolit, v\u00f5ime kaotada ligip\u00e4\u00e4su t\u00e4hestiku l\u00f5pupoolele.<\/p>\n

      Selle probleemi lahendamiseks k\u00e4isin ma k\u00e4sitsi l\u00e4bi m\u00f5ned plokid, mis vastavad erinevatele keeltele, ja m\u00e4rkisin neile p\u00f5hiallika sees abialfabeedi nihke. Ladina t\u00e4hestikku, erandina, \u00fcmber j\u00e4rjestasin hoopis base64 sarnaselt.<\/p>\n

      \"Veel<\/p>\n

      Viimased puudutused<\/h2>\n

      \nM\u00f5elgem l\u00f5petuseks, kus me saame veel midagi t\u00e4iustada.<\/p>\n

      Pane t\u00e4hele, et formaat 101xxxxx xxxxxxxx xxxxxxxx<\/b><\/code> lubab kodeerida numbreid kuni 0x1FFFFF<\/b><\/code>, kuid Unicode l\u00f5peb varem, number 0x10FFFF<\/b><\/code>. Teisis\u00f5nu, viimane koodipunkt esindatakse kui 10110000 11111111 11111111<\/b><\/code>. Nii et, me v\u00f5ime \u00f6elda, et kui esimene bait on kujul 1011xxxx<\/b><\/code> kui xxxx<\/b><\/code> suurem kui 0), siis see t\u00e4histab midagi muud. N\u00e4iteks v\u00f5ib sinna juurde lisada veel 15 s\u00fcmbolit, mis on pidevalt koodimiseks \u00fche baidi jagu, kuid ma otsustasin k\u00e4ituda teisiti.<\/p>\n

      Seet\u00f5ttu valime v\u00e4lja m\u00f5ned valitud vahemikud, mis vastavad emotikonidele, hiraganale ja katakanale, nummerdame need \u00fchte pidevasse loetellu ja kodeerime kahena baidina kolmest:<\/p>\n

      1011xxxx xxxxxxxx<\/b><\/code> <\/p>\n

      Suurep\u00e4rane: eelmainitud emotikon \u200d\u200d\u200d\"Veel<\/a><\/noindex>, mis koosneb 7 koodipunktist, kasutab UTF-8-s 25 baidi, kuid mahutasime selle 14<\/strong> kahe baitiga igale koodipunktile). Muide, Habra keeldus seda t\u00f6\u00f6tlema (nii vanas kui ka uues toimetajas), nii et tuli see pildina sisestada.<\/p>\n

      Proovime parandada veel \u00fchte probleemi. Kuidas me m\u00e4letame, et p\u00f5hialfabeet on sisuliselt \u00fclemised 6 bitti<\/strong>, mida me peame meeles ja kinnitame iga dekooditava s\u00fcmboli koodi. Hiina hierogl\u00fc\u00fcfide puhul, mis asuvad plokis 0x4E00<\/b><\/code> \u2013 0x9FFF<\/b><\/code>, on see kas bit 0 v\u00f5i 1. See pole v\u00e4ga mugav: meil tuleb pidevalt vahetada t\u00e4hestikku nende kahe v\u00e4\u00e4rtuse vahel (st kasutada kolm bitti). Kuid m\u00e4rkame, et pikemas re\u017eiimis saame koodist lahutada s\u00fcmbolite arvu, mida kodeerime l\u00fchikeses re\u017eiimis (aine eelneva kirjeldatud nipi j\u00e4rgi 10240) \u2014 siis nihkub hierogl\u00fc\u00fcfide vahemik 0x2600<\/b><\/code> \u2013 0x77FF<\/b><\/code>, ja sel juhul on kogu selle vahemiku \u00fclemised 6 bitti (21-st) v\u00f5rdsed 0-ga. Seega kasutavad hierogl\u00fc\u00fcfide j\u00e4rjestused iga hierogl\u00fc\u00fcfi jaoks kahte bitti (mis on suurte vahemike jaoks optimaalselt), p\u00f5hjustamata t\u00e4hestiku vahetust. <\/p>\n

      Alternatiivsed lahendused: SCSU, BOCU-1<\/h2>\n

      \nUnicode'i asjatundjad, lugedes ainult artikli nime, kiirustavad t\u00f5en\u00e4oliselt meelde tuletama, et Unicode'i standardite seas on Standard Compression Scheme for Unicode<\/a><\/noindex> (SCSU), mis kirjeldab kodeerimise meetodit, mis on v\u00e4ga sarnane artiklis kirjeldatuga.<\/p>\n

      Tunnistan ausalt: tema olemasolust sain ma teada alles p\u00e4rast seda, kui olin s\u00fcgavalt oma lahenduse kirjutamisega sisse elanud. Kui oleksin sellest alguses teada, oleksin ilmselt proovinud kirjutada tema rakenduse, mitte v\u00e4lja m\u00f5elda oma l\u00e4henemist.<\/p>\n

      Huvitav on see, et SCSU kasutab ideid, mis on v\u00e4ga sarnased sellele, milleni ma ise j\u00f5udsin (seal, kus kasutatakse \u201eaknaid\u201c t\u00e4hestiku asemel, on neid rohkem, kui mul on). Samas on sellel formaadil ka miinuseid: see on veidi l\u00e4hemal pakkimisalgoritmidele, mitte kodeerimisele. Eelk\u00f5ige annab standard palju esitlusviise, kuid ei \u00fctle, kuidas neist parimat valida \u2014 selleks peab kodeerija kasutama mingeid heuristikume. Seega on SCSU kodeerija, mis pakub head pakkimist, keerulisem ja mahukam kui minu algoritm.<\/p>\n

      V\u00f5rdluseks t\u00f5in suhteliselt lihtsa SCSU rakenduse JavaScriptis \u2014 koodi mahult oli see v\u00f5rreldav minu UTF-C-lahendusega, kuid m\u00f5nel juhul n\u00e4itas see tulemusi, mis olid k\u00fcmnete protsentide v\u00f5rra halvemad (m\u00f5nikord v\u00f5ib see ka \u00fcletada, kuid mitte palju). N\u00e4iteks heebrea ja kreeka tekstid kodeeris UTF-C lausa 60% paremini kui SCSU<\/strong> (t\u00f5en\u00e4oliselt t\u00e4nu nende kompaktsetele t\u00e4hestikele).<\/p>\n

      Lisaks mainin, et lisaks SCSU-le on olemas ka teine kompaktne Unicode'i esitusviis \u2014 BOCU-1<\/a><\/noindex>, kuid selle eesm\u00e4rk on saavutada \u00fchilduvus MIME-iga (mida mul ei olnud vaja) ning see kasutab veidi teistsugust kodeerimise l\u00e4henemist. Ma ei ole selle t\u00f5husust hinnanud, kuid mulle tundub, et see ei saa olla efektiivsem kui SCSU.<\/p>\n

      V\u00f5imalikud t\u00e4iustused<\/h2>\n

      \nKasutatud algoritm ei ole disaini poolest universaalne (selle t\u00f5ttu lahknevad mu eesm\u00e4rgid k\u00f5ige rohkem Unicode'i konsortsiumi eesm\u00e4rkidest). Olen juba maininud, et see t\u00f6\u00f6tati v\u00e4lja peamiselt \u00fche \u00fclesande jaoks (mitmekeelse s\u00f5naraamatu salvestamine prefiksipuu kujul), ja m\u00f5ned selle omadused v\u00f5ivad teiste \u00fclesannete jaoks mitte sobida. Kuid fakt, et see ei ole standard, v\u00f5ib olla ka positiivne \u2014 saate seda h\u00f5lpsasti oma vajadustele kohandada<\/strong>.<\/p>\n

      N\u00e4iteks on ilmne, et v\u00f5imalik on eemaldada oleku olemasolu, muuta kodeerimine riistadesse mitteoluliseks \u2014 lihtsalt mitte v\u00e4rskendada muutujaid kingad<\/b><\/code>, auxOffs<\/b><\/code> ja is21Bit<\/b><\/code> kodeerijas ja dekodeerijas. Sellisel juhul ei saa efektiivselt pakkida s\u00fcmboolsete j\u00e4rjestusi, kuid on garantii, et sama s\u00fcmbol kodeeritakse alati samade baitidega, s\u00f5ltumata kontekstist.<\/p>\n

      Lisaks v\u00f5ib kodeerijat kohandada konkreetse keele j\u00e4rgi, muutes vaikeseisundi \u2014 n\u00e4iteks, suunates Venemaa tekstide peale, seadistada alguses kodeerijat ja dekodeerijat offs = 0x0400<\/b><\/code> ja auxOffs = 0<\/b><\/code>. See on eriti m\u00f5istlik just staatiliste re\u017eiimide korral. \u00dcldiselt sarnaneb see vana 8-bitise kodeerimise kasutamisega, kuid ei v\u00e4lista v\u00f5imalust vajadusel lisada s\u00fcmboleid kogu Unicode'ist.<\/p>\n

      Veel \u00fcks varem mainitud puudus \u2014 mahukas tekstis, mis on kodeeritud UTF-C-s, ei ole kiiret viisi, kuidas leida s\u00fcmboli piir, mis asub juhusliku baidi l\u00e4hedal. Kui l\u00f5ikate kodeeritud puhverdamist viimased, \u00fctleme, 100 baidi, riskite saada pr\u00fcgi, millega ei saa midagi teha. Suurte logide hoidmiseks ei ole kodeerimine m\u00f5eldud, kuid seda on v\u00f5imalik parandada. Bait 0xBF<\/b><\/code> ei tohi kunagi esimesena esineda (aga see v\u00f5ib olla teine v\u00f5i kolmas). Seet\u00f5ttu saab kodeerimise k\u00e4igus lisada j\u00e4rjestuse 0xBF 0xBF 0xBF<\/b><\/code> iga, \u00fctleme, 10 Kb \u2014 siis piisab valitud osa skaneerimisest, et leida piir, kuni sarnane marker on leitud. Viimane 0xBF<\/b><\/code> garantereeritult on s\u00fcmboli algus. (Dekodeerimisel tuleb see kolmest baitist koosnev j\u00e4rjestus muidugi ignoreerida.)<\/p>\n

      Kokkuv\u00f5tteks<\/h2>\n

      \nKui olete siiani lugenud \u2014 \u00f5nnitleme! Loodan, et olete nagu mina midagi uut \u00f5ppinud (v\u00f5i v\u00e4rskendanud m\u00e4lu) Unicode'i seadistusest.<\/p>\n

      \"Veel
      \nDemonstratsioonileht. Heebrea n\u00e4itel on n\u00e4ha eelistusi nii UTF-8 kui ka SCSU ees.<\/i><\/p>\n

      \u00c4rge k\u00e4sitlege eespool toodud uurimusi standardite rikkumisena. Siiski olen \u00fcldiselt tulemuste \u00fcle rahul ja seet\u00f5ttu olen r\u00f5\u00f5muga valmis neid<\/a><\/noindex>: n\u00e4iteks JS-raamatukogu minimeeritud kujul kaalub vaid 1710 baiti (ja loomulikult ei ole tal s\u00f5ltuvusi). Nagu ma enne mainisin, on selle t\u00f6\u00f6ga v\u00f5imalik tutvuda demonstreerimislehe<\/a><\/noindex> (seal on ka tekstide komplekt, millega seda saab v\u00f5rrelda UTF-8 ja SCSU-ga).<\/p>\n

      L\u00f5petuseks tuletan veel kord meelde olukordi, kus UTF-C-d ei tohiks kasutada<\/b>:<\/p>\n

      Vaadakem neid Unicode'i plokke, mis praegu n\u00f5uavad kolme bait: enamasti, nagu mainitud, on need hiina ideogrammid \u2013 aga nendega on raske midagi teha, neid on 21 tuhat. Kuid sinna on juhtunud ka hiragana ja katakana \u2013 neid on juba v\u00e4hem, alla kahesaja. Ja kuna me juba jaapanlastest r\u00e4\u00e4kisime \u2013 seal on ka emotikonid (tegelikult on neid palju jaotatud Unicode'is, kuid p\u00f5hiplokid on vahemikus 0x1F300<\/b><\/code> \u2013 0x1FBFF<\/b><\/code>). Kui m\u00f5elda, et praegu on olemas emotikonid, mis koosnevad mitmest koodipunktist (n\u00e4iteks emotikon \u200d\u200d\u200d\"Veel<\/a><\/noindex> koosneb lausa 7 koodist!), siis hakkab t\u00f5eliselt kurb olema raisata iga\u00fchele kolm bait (7\u00d73 = 21 bait \u00fche s\u00fcmboli eest, see on \u00f5udne).<\/p>\n