Још један бицикл: складиштимо Уницоде низове 30-60% компактније од УТФ-8

Ако сте програмер и суочени сте са задатком да изаберете кодирање, онда ће Уницоде скоро увек бити право решење. Конкретан начин представљања зависи од контекста, али најчешће и овде постоји универзални одговор - УТФ-8. Добра ствар у вези с тим је што вам омогућава да користите све Уницоде знакове без трошења превише много бајтова у већини случајева. Истина, за језике који користе више од латиничног писма, „не превише“ је барем два бајта по карактеру. Можемо ли учинити боље без враћања на праисторијска кодирања која нас ограничавају на само 256 доступних знакова?

У наставку предлажем да се упознате са својим покушајем да одговорим на ово питање и применим релативно једноставан алгоритам који вам омогућава да складиштите линије на већини језика света без додавања редундантности која је у УТФ-8.

Одрицање одговорности. Одмах ћу направити неколико важних резерви: описано решење се не нуди као универзална замена за УТФ-8, погодан је само у уској листи случајева (више о њима у наставку), и ни у ком случају не би требало да се користи за интеракцију са АПИ-јима трећих страна (који чак и не знају за то). Најчешће су алгоритми компресије опште намене (на пример, дефлате) погодни за компактно складиштење великих количина текстуалних података. Осим тога, већ у процесу креирања свог решења пронашао сам постојећи стандард у самом Уницоде-у, који решава исти проблем – нешто је компликованији (а често и гори), али је ипак прихваћен стандард, а не само стављен заједно на колену. Рећи ћу вам и о њему.

О Уницоде-у и УТФ-8

За почетак, неколико речи о томе шта је то Уницоде и УТФ-КСНУМКС.

Као што знате, 8-битна кодирања су некада била популарна. Код њих је све било једноставно: 256 карактера може бити нумерисано бројевима од 0 до 255, а бројеви од 0 до 255 очигледно могу бити представљени као један бајт. Ако се вратимо на сам почетак, АСЦИИ кодирање је потпуно ограничено на 7 бита, тако да је најзначајнији бит у његовој бајтској представи нула, а већина 8-битних кодирања је компатибилна са њим (разликују се само у „горњем“ део, где је најзначајнији бит један ).

По чему се Уницоде разликује од тих кодирања и зашто је толико специфичних репрезентација повезаних са њим - УТФ-8, УТФ-16 (БЕ и ЛЕ), УТФ-32? Хајде да то средимо по реду.

Основни Уницоде стандард описује само кореспонденцију између знакова (иу неким случајевима, појединачних компоненти знакова) и њихових бројева. А у овом стандарду има пуно могућих бројева - од 0x00 до 0x10FFFF (1 комада). Ако бисмо желели да у променљиву ставимо број у таквом опсегу, не би нам били довољни ни 114 ни 112 бајта. А пошто наши процесори нису баш дизајнирани за рад са бројевима од три бајта, били бисмо приморани да користимо чак 1 бајта по карактеру! Ово је УТФ-2, али управо због те „расипности“ овај формат није популаран.

На срећу, редослед знакова у Уницоде-у није случајан. Цео њихов сет је подељен на 17"авиони“, од којих сваки садржи 65536 (0x10000) "кодне тачке" Концепт „кодне тачке“ овде је једноставан број карактера, који му је доделио Уницоде. Али, као што је горе поменуто, у Уницоде-у нису нумерисани само појединачни знакови, већ и њихове компоненте и сервисне ознаке (а понекад уопште ништа не одговара броју - можда за сада, али за нас то није толико важно), тако да тачније је увек говорити конкретно о броју самих бројева, а не симболима. Међутим, у наставку ћу, ради сажетости, често користити реч „симбол“, подразумевајући термин „кодна тачка“.

Уницоде авиони. Као што видите, већина (авиони 4 до 13) је још увек неискоришћена.

Оно што је најупечатљивије је да сва главна "пулпа" лежи у нултој равни, зове се "Основна вишејезична раван". Ако линија садржи текст на једном од модерних језика (укључујући кинески), нећете ићи даље од ове равни. Али не можете ни да одсечете остатак Уницоде-а - на пример, емоји се углавном налазе на крају следећи авион"Додатни вишејезични авион"(проширује се од 0x10000 до 0x1FFFF). Дакле, УТФ-16 ради ово: сви знакови спадају унутар Основна вишејезична раван, су кодирани „као што јесу“ одговарајућим двобајтним бројем. Међутим, неки од бројева у овом опсегу уопште не означавају одређене карактере, већ указују на то да након овог пара бајтова треба да размотримо још један – комбиновањем вредности ова четири бајта заједно, добијамо број који покрива цео важећи Уницоде опсег. Ова идеја се зове „сурогат парови“ – можда сте чули за њих.

Дакле, УТФ-16 захтева два или (у веома ретким случајевима) четири бајта по „кодној тачки“. Ово је боље него да стално користите четири бајта, али латиница (и други АСЦИИ знакови) када су кодирани на овај начин троше половину простора на нуле. УТФ-8 је дизајниран да ово исправи: АСЦИИ у њему заузима, као и раније, само један бајт; кодови из 0x80 до 0x7FF - два бајта; из 0x800 до 0xFFFF - три, и од 0x10000 до 0x10FFFF - четири. С једне стране, латиница је постала добра: вратила се компатибилност са АСЦИИ, а дистрибуција је равномерније „распрострањена“ од 1 до 4 бајта. Али алфабете осим латинице, нажалост, немају никакве користи у поређењу са УТФ-16, а многима су сада потребна три бајта уместо два – опсег који покрива двобајтни запис се сузио за 32 пута, са 0xFFFF до 0x7FF, а у њега нису укључени ни кинески ни, на пример, грузијски. Ћирилица и пет других писама - ура - срећа, 2 бајта по карактеру.

Зашто се то дешава? Хајде да видимо како УТФ-8 представља кодове знакова:

Директно за представљање бројева, овде се користе битови означени симболом x. Види се да у двобајтном запису има само 11 таквих битова (од 16). Водећи битови овде имају само помоћну функцију. У случају записа од четири бајта, 21 од 32 бита се додељује за број кодне тачке - чини се да би три бајта (који дају укупно 24 бита) била довољна, али сервисни маркери једу превише.

Да ли је ово лоше? Не баш. С једне стране, ако нам је много стало до простора, имамо алгоритме компресије који лако могу елиминисати сву додатну ентропију и редундантност. С друге стране, циљ Уницоде-а је био да обезбеди најуниверзалније могуће кодирање. На пример, можемо поверити линију кодирану у УТФ-8 коду који је раније радио само са АСЦИИ, и не плашити се да ће видети знак из АСЦИИ опсега који заправо није тамо (на крају крајева, у УТФ-8 сви бајтова који почињу од нултог бита – то је управо оно што је АСЦИИ). А ако одједном пожелимо да одсечемо мали реп од великог низа, а да га не дешифрујемо од самог почетка (или да вратимо део информација након оштећеног одељка), лако нам је да пронађемо помак где знак почиње (довољно је да прескочите бајтове који имају префикс бита 10).

Зашто онда измишљати нешто ново?

Истовремено, повремено постоје ситуације када су алгоритми компресије као што је дефлате слабо применљиви, али желите да постигнете компактно складиштење стрингова. Лично, наишао сам на овај проблем када сам размишљао о изградњи компримовано стабло префикса за велики речник који укључује речи на произвољним језицима. С једне стране, свака реч је веома кратка, тако да ће компресовање бити неефикасно. С друге стране, имплементација стабла коју сам разматрао је дизајнирана тако да сваки бајт ускладиштеног низа генерише посебан врх стабла, тако да је минимизирање њиховог броја било веома корисно. У мојој библиотеци Аз.јс (Као у пиморфија2, на којој се заснива) сличан проблем се може једноставно решити - стрингови упаковани у ДАВГ-речник, похрањен тамо у добри стари ЦП1251. Али, као што је лако разумети, ово добро функционише само за ограничено писмо - ред на кинеском се не може додати у такав речник.

Одвојено, желео бих да приметим још једну непријатну нијансу која се јавља када се користи УТФ-8 у таквој структури података. Слика изнад показује да када је карактер написан као два бајта, битови који се односе на његов број не долазе у ред, већ су раздвојени паром битова 10 у средини: 110xxxxx 10xxxxxx. Због тога, када се нижих 6 битова другог бајта преливају у коду карактера (тј. дође до прелаза 10111111 → 10000000), тада се мења и први бајт. Испоставило се да је слово „п“ означено бајтовима 0xD0 0xBF, а следеће „р“ је већ 0xD1 0x80. У стаблу префикса, ово доводи до раздвајања родитељског чвора на два – један за префикс 0xD0, а други за 0xD1 (иако је цела ћирилица могла бити кодирана само другим бајтом).

Шта сам добио

Суочен са овим проблемом, одлучио сам да вежбам играње игрица са битовима, а да се у исто време мало боље упознам са структуром Уницоде-а у целини. Резултат је био УТФ-Ц формат кодирања („Ц“ за компактан), који не троши више од 3 бајта по кодној тачки, а врло често вам омогућава да трошите само један додатни бајт за целу кодирану линију. То доводи до чињенице да се на многим не-АСЦИИ алфабетима испоставља да постоји такво кодирање 30-60% компактнији од УТФ-8.

У форми сам приказао примере имплементације алгоритама кодирања и декодирања ЈаваСцрипт и Го библиотеке, можете их слободно користити у свом коду. Али ипак ћу нагласити да овај формат у извесном смислу остаје „бицикл“ и не препоручујем да га користите а да не схватате зашто вам је то потребно. Ово је и даље више експеримент него озбиљно „побољшање УТФ-8“. Ипак, код је написан уредно, сажето, са великим бројем коментара и покривености тестом.

Резултати теста и поређење са УТФ-8

И ја јесам демо страница, где можете проценити перформансе алгоритма, а затим ћу вам рећи више о његовим принципима и процесу развоја.

Уклањање сувишних битова

Узео сам УТФ-8 као основу, наравно. Прва и најочигледнија ствар која се у њему може променити је смањење броја сервисних битова у сваком бајту. На пример, први бајт у УТФ-8 увек почиње са било којим 0, или са 11 - префикс 10 Имају га само следећи бајтови. Заменимо префикс 11 на 1, а за следеће бајтове у потпуности ћемо уклонити префиксе. Шта ће се десити?

0xxxxxxx — 1 бајт
10xxxxxx xxxxxxxx - 2 бајта
110xxxxx xxxxxxxx xxxxxxxx - 3 бајта

Чекај, где је запис од четири бајта? Али то више није потребно – при писању у три бајта сада имамо на располагању 21 бит и ово је довољно за све бројеве до 0x10FFFF.

Шта смо ми овде жртвовали? Најважније је откривање граница карактера са произвољне локације у баферу. Не можемо показати на произвољан бајт и из њега пронаћи почетак следећег знака. Ово је ограничење нашег формата, али у пракси је то ретко потребно. Обично смо у могућности да прођемо кроз бафер од самог почетка (нарочито када су у питању кратке линије).

Ситуација са покривањем језика са 2 бајта такође је постала боља: сада двобајтни формат даје опсег од 14 бита, а то су кодови до 0x3FFF. Кинези немају среће (њихови ликови се углавном крећу од 0x4E00 до 0x9FFF), али Грузијци и многи други народи се више забављају - њихови језици се такође уклапају у 2 бајта по карактеру.

Унесите стање кодера

Хајде сада да размислимо о својствима самих линија. Речник најчешће садржи речи написане знаковима истог писма, а то важи и за многе друге текстове. Било би добро да једном назначите ово писмо, а затим назначите само број слова у њему. Да видимо да ли ће нам распоред знакова у Уницоде табели помоћи.

Као што је горе поменуто, Уницоде је подељен на авион 65536 кодова сваки. Али ово није баш корисна подела (као што је већ речено, најчешће смо у нултој равни). Занимљивија је подела по блокова. Ови опсези више немају фиксну дужину, већ су значајнији – по правилу сваки комбинује знакове из истог алфабета.

Блок који садржи знакове бенгалског алфабета. Нажалост, из историјских разлога, ово је пример не баш густог паковања - 96 карактера је хаотично распоређено у 128 блок кодних тачака.

Почеци блокова и њихове величине су увек вишеструки од 16 - то се ради једноставно ради погодности. Поред тога, многи блокови почињу и завршавају се на вредностима које су вишеструке од 128 или чак 256 - на пример, основно ћирилично писмо заузима 256 бајтова од 0x0400 до 0x04FF. Ово је прилично згодно: ако једном сачувамо префикс 0x04, онда се у једном бајту може написати било који ћирилични знак. Истина, на овај начин ћемо изгубити прилику да се вратимо на АСЦИИ (и на било које друге знакове уопште). Стога радимо ово:

1. Два бајта 10yyyyyy yxxxxxxx не само да означавају симбол бројем yyyyyy yxxxxxxx, али и промене актуелно писмо на yyyyyy y0000000 (тј. памтимо све битове осим оних најмање значајних КСНУМКС бит);
2. Један бајт 0xxxxxxx ово је карактер садашње абецеде. Само треба да се дода офсету којег смо запамтили у кораку 1. Иако нисмо променили абецеду, помак је нула, тако да смо задржали компатибилност са АСЦИИ.

Исто тако за кодове који захтевају 3 бајта:

1. Три бајта 110yyyyy yxxxxxxx xxxxxxxx означава симбол са бројем yyyyyy yxxxxxxx xxxxxxxx, промена актуелно писмо на yyyyyy y0000000 00000000 (сећао се свега осим млађих КСНУМКС бит) и означите поље у којем се сада налазимо дуго режим (када се абецеда врати на двобајтну, ресетоваћемо ову заставицу);
2. Два бајта 0xxxxxxx xxxxxxxx у дугом режиму то је знак тренутног алфабета. Слично томе, додајемо га са помаком из корака 1. Једина разлика је у томе што сада читамо два бајта (јер смо прешли на овај режим).

Звучи добро: сада док морамо да кодирамо знакове из истог 7-битног Уницоде опсега, трошимо 1 додатни бајт на почетку и укупно један бајт по карактеру.

Ради од једне од ранијих верзија. Већ често надмашује УТФ-8, али још увек има простора за побољшање.

Шта је горе? Прво, имамо услов, тј тренутни абецедни помак и поље за потврду дуги режим. Ово нас додатно ограничава: сада исти знакови могу бити различито кодирани у различитим контекстима. Претраживање подстрингова, на пример, мораће да се обави узимајући у обзир ово, а не само поређењем бајтова. Друго, чим смо променили абецеду, постало је лоше са кодирањем АСЦИИ знакова (а ово није само латиница, већ и основна интерпункција, укључујући и размаке) - захтевају да поново променимо писмо на 0, тј. поново додатни бајт (а затим још један да се вратимо на нашу главну тачку).

Једна азбука је добра, два је боља

Покушајмо мало да променимо наше битне префиксе, истискујући још један на три горе описана:

0xxxxxxx — 1 бајт у нормалном режиму, 2 у дугом режиму
11xxxxxx — 1 бајт
100xxxxx xxxxxxxx - 2 бајта
101xxxxx xxxxxxxx xxxxxxxx - 3 бајта

Сада у двобајтном запису постоји један мање доступан бит - код показује до 0x1FFFИ не 0x3FFF. Међутим, и даље је приметно већи него у двобајтним УТФ-8 кодовима, најчешћи језици се и даље уклапају, најуочљивији губитак је испао хирагана и катакана, тужни су Јапанци.

Шта је овај нови код? 11xxxxxx? Ово је мали „склад“ величине 64 знака, допуњује нашу главну абецеду, па сам је назвао помоћним (помоћни) азбука. Када променимо тренутну азбуку, део старе азбуке постаје помоћни. На пример, прешли смо са АСЦИИ-а на ћирилицу - складиште сада садржи 64 карактера Латиница, бројеви, размак и зарез (најчешћа уметања у текстове који нису АСЦИИ). Вратили смо се на АСЦИИ - и главни део ћирилице ће постати помоћно писмо.

Захваљујући приступу два алфабета, можемо да обрађујемо велики број текстова уз минималне трошкове за пребацивање алфабета (интерпункција ће најчешће довести до повратка на АСЦИИ, али након тога добијамо много не-АСЦИИ знакова из додатне абецеде, без поново пребацивање).

Бонус: префикс под-абецеде 11xxxxxx и одабиром његовог почетног одступања да буде 0xC0, добијамо делимичну компатибилност са ЦП1252. Другим речима, многи (али не сви) западноевропски текстови кодирани у ЦП1252 ће изгледати исто у УТФ-Ц.

Овде, међутим, настаје потешкоћа: како добити помоћну из главног алфабета? Можете оставити исти офсет, али - авај - овде Уницоде структура већ игра против нас. Врло често главни део абецеде није на почетку блока (на пример, руско велико „А“ има шифру 0x0410, иако ћирилични блок почиње са 0x0400). Дакле, узимајући прва 64 знака у складиште, можемо изгубити приступ репу абецеде.

Да бих решио овај проблем, ручно сам прошао кроз неке блокове који одговарају различитим језицима и одредио помак помоћног алфабета унутар главног за њих. Латиница је, као изузетак, генерално преуређена као основа64.

Финал тоуцхс

Хајде да коначно размислимо где још можемо нешто да побољшамо.

Имајте на уму да је формат 101xxxxx xxxxxxxx xxxxxxxx омогућава вам да кодирате бројеве до 0x1FFFFF, а Уницоде се завршава раније, на 0x10FFFF. Другим речима, последња кодна тачка ће бити представљена као 10110000 11111111 11111111. Стога можемо рећи да ако је први бајт облика 1011xxxx (Где xxxx веће од 0), онда то значи нешто друго. На пример, тамо можете додати још 15 карактера који су стално доступни за кодирање у једном бајту, али сам одлучио да то урадим другачије.

Хајде да сада погледамо оне Уницоде блокове који захтевају три бајта. У суштини, као што је већ поменуто, ово су кинески знакови - али тешко је било шта урадити са њима, има их 21 хиљада. Али тамо су летеле и хирагана и катакана – а нема их више толико, мање од двеста. А, пошто смо се сетили Јапанаца, постоје и емоји (у ствари, они су разбацани на много места у Уницоде-у, али главни блокови су у опсегу 0x1F300 - 0x1FBFF). Ако размислите о чињеници да сада постоје емоји који су састављени из неколико кодних тачака одједном (на пример, емоји ‍‍‍ састоји се од чак 7 кодова!), онда постаје потпуна штета потрошити три бајта на сваки (7×3 = 21 бајт зарад једне иконе, ноћна мора).

Због тога бирамо неколико изабраних опсега који одговарају емојији, хирагани и катакани, пренумерујемо их у једну непрекидну листу и кодирамо их као два бајта уместо три:

1011xxxx xxxxxxxx

Одлично: горе поменути емоџи, који се састоји од 7 кодних тачака, заузима 8 бајтова у УТФ-25 и ми га уклапамо 14 (тачно два бајта за сваку тачку кода). Иначе, Хабр је одбио да га свари (и у старом и у новом едитору), па сам морао да га убацим са сликом.

Хајде да покушамо да решимо још један проблем. Као што се сећамо, основно писмо је у суштини висока 6 бита, што имамо на уму и лепимо за код сваког следећег декодираног симбола. У случају кинеских знакова који се налазе у блоку 0x4E00 - 0x9FFF, ово је или бит 0 или 1. Ово није баш згодно: мораћемо стално да мењамо абецеду између ове две вредности (тј. трошимо три бајта). Али имајте на уму да у дугом режиму, од самог кода можемо одузети број знакова које кодирамо користећи кратки режим (после свих трикова описаних изнад, ово је 10240) - тада ће се опсег хијероглифа померити на 0x2600 - 0x77FF, иу овом случају, у целом овом опсегу, најзначајнијих 6 битова (од 21) биће једнако 0. Дакле, секвенце хијероглифа ће користити два бајта по хијероглифу (што је оптимално за тако велики опсег), без изазивајући промене абецеде.

Алтернативна решења: СЦСУ, БОЦУ-1

Стручњаци за Уницоде, који су управо прочитали наслов чланка, највероватније ће пожурити да вас подсете да директно међу Уницоде стандардима постоји Стандардна шема компресије за Уницоде (СЦСУ), који описује метод кодирања веома сличан оном описаном у чланку.

Искрено признајем: сазнао сам за његово постојање тек пошто сам био дубоко уроњен у писање своје одлуке. Да сам знао за то од почетка, вероватно бих покушао да напишем имплементацију уместо да смислим сопствени приступ.

Оно што је интересантно јесте да СЦСУ користи идеје веома сличне онима које сам ја смислио (уместо концепта „абецеде“ користе „прозоре“, а има их више него што имам). Истовремено, овај формат има и недостатке: мало је ближи алгоритмима за компресију него код кодирања. Конкретно, стандард даје многе методе представљања, али не каже како одабрати оптималну - за то енкодер мора користити неку врсту хеуристике. Стога ће СЦСУ кодер који производи добро паковање бити сложенији и гломазнији од мог алгоритма.

Поређења ради, пренео сам релативно једноставну имплементацију СЦСУ-а на ЈаваСцрипт – у смислу обима кода испоставило се да је упоредив са мојим УТФ-Ц, али у неким случајевима резултат је био десетине процената лошији (понекад га може премашити, али не много). На пример, текстови на хебрејском и грчком били су кодирани УТФ-Ц 60% боље од СЦСУ (вероватно због њиховог компактног писма).

Одвојено, додаћу да поред СЦСУ постоји и други начин да се компактно представи Уницоде - БОЦУ-1, али има за циљ МИМЕ компатибилност (која ми није била потребна) и има мало другачији приступ кодирању. Нисам проценио његову ефикасност, али ми се чини да је мало вероватно да ће бити већи од СЦСУ.

Могућа побољшања

Алгоритам који сам представио није универзалан по дизајну (ту се вероватно моји циљеви највише разликују од циљева Уницоде конзорцијума). Већ сам поменуо да је развијен првенствено за један задатак (чување вишејезичног речника у стаблу префикса), а неке од његових карактеристика можда нису погодне за друге задатке. Али чињеница да то није стандард може бити плус - можете га лако модификовати тако да одговара вашим потребама.

На пример, на очигледан начин можете се ослободити присуства стања, направити кодирање без стања - само немојте ажурирати варијабле offs, auxOffs и is21Bit у кодеру и декодеру. У овом случају неће бити могуће ефикасно паковати низове знакова исте абецеде, али ће постојати гаранција да је исти знак увек кодиран истим бајтовима, без обзира на контекст.

Поред тога, можете да прилагодите кодер одређеном језику променом подразумеваног стања - на пример, фокусирајући се на руске текстове, поставите кодер и декодер на почетку offs = 0x0400 и auxOffs = 0. Ово посебно има смисла у случају режима без држављанства. Генерално, ово ће бити слично коришћењу старог осмобитног кодирања, али без уклањања могућности уметања знакова из целог Уницоде-а по потреби.

Још један недостатак који је раније поменут је да у великом тексту кодираном у УТФ-Ц не постоји брз начин да се пронађе граница карактера најближа произвољном бајту. Ако одсечете последњих, рецимо, 100 бајтова из кодираног бафера, ризикујете да добијете смеће са којим не можете ништа да урадите. Кодирање није дизајнирано за складиштење вишегигабајтних дневника, али генерално то се може исправити. Бите 0xBF никада се не сме појавити као први бајт (али може бити други или трећи). Стога, када кодирате, можете уметнути секвенцу 0xBF 0xBF 0xBF сваких, рецимо, 10 КБ - онда, ако треба да пронађете границу, биће довољно да скенирате изабрани комад док се не пронађе сличан маркер. Следећи последњу 0xBF гарантовано је почетак лика. (Приликом декодирања, овај низ од три бајта ће, наравно, морати да се занемари.)

Резиме

Ако сте читали до сада, честитам! Надам се да сте, као и ја, научили нешто ново (или освежили памћење) о структури Уницоде-а.

Демо страница. Пример хебрејског показује предности у односу на УТФ-8 и СЦСУ.

Горе описано истраживање не треба сматрати задирањем у стандарде. Међутим, генерално сам задовољан резултатима свог рада, тако да сам задовољан њима поделити: на пример, минимизована ЈС библиотека тежи само 1710 бајтова (и нема зависности, наравно). Као што сам горе поменуо, њен рад се може наћи на демо страница (постоји и скуп текстова на којима се може упоредити са УТФ-8 и СЦСУ).

На крају, још једном ћу скренути пажњу на случајеве у којима се користи УТФ-Ц не исплати:

• Ако су ваши редови довољно дуги (од 100-200 карактера). У овом случају, требало би да размислите о коришћењу алгоритама компресије као што је дефлате.
• Ако ти треба АСЦИИ транспарентност, односно за вас је важно да кодиране секвенце не садрже АСЦИИ кодове који нису били у оригиналном низу. Потреба за овим се може избећи ако, приликом интеракције са АПИ-јима трећих страна (на пример, рад са базом података), проследите резултат кодирања као апстрактни скуп бајтова, а не као низове. У супротном, ризикујете да добијете неочекиване рањивости.
• Ако желите да будете у могућности да брзо пронађете границе карактера на произвољном померању (на пример, када је део реда оштећен). Ово се може урадити, али само скенирањем линије од почетка (или применом модификације описане у претходном одељку).
• Ако треба брзо да извршите операције над садржајем низова (сортирајте их, потражите подстрингове у њима, спојите). Ово захтева да се стрингови прво декодирају, тако да ће УТФ-Ц у овим случајевима бити спорији од УТФ-8 (али бржи од алгоритама компресије). Пошто је исти низ увек кодиран на исти начин, тачно поређење декодирања није потребно и може се обавити на бази бајта по бајт.

Упдате: корисник Тиомитцх у коментарима испод објавио графикон који истиче границе применљивости УТФ-Ц. Показује да је УТФ-Ц ефикаснији од алгоритма компресије опште намене (варијација ЛЗВ-а) све док је паковани стринг краћи ~140 знакова (међутим, напомињем да је поређење обављено на једном тексту; за друге језике резултат се може разликовати).


Извор: ввв.хабр.цом