UTF-32: Разлика между версии

Изключително рядко е даден код да намери N-тата точка без предварително разглеждане на точките от 0 до N – 1. Това означава, че индекс увеличен с 1 за всеки знак може да бъде заменен с изместеното число, измерено в кодови единици и увеличено с броя кодови единици като всеки знак се разглежда. Това премахва всички предимства със скоростта при работа с UTF-32. В малкото случаи, където точката N е генерирана без предварително преглеждане на кода, като хеширане и високоскоростни алгоритми за търсене, няма нужда N да бъде представена с точност и по този начин, с орязване, може да бъде пригодено за за работа с UTF-8 или UTF-16, чрез настройване на позицията до най-близката граница на кодова точка, операция с фиксирано време.UTF-32 не пресмята показаната ширина на низа по-лесно, тъй като дори и при шрифт с „фиксирана ширина“ може да има знаци съдържащи повече от една кодова точка на позиция (комбинирани знаци) или повече от един знак на дадена позиция (на пример CJK (Китайски, Японски, Корейски) йероглифи). Редактори които се ограничават до езици с начин на изписване от ляво на дясно и по-сложни знаци могат да се възползват от фиксираните по размер кодови единици, но е малко вероятно да поддържат знаци които не са част от BMP и за това работят еднакво добре с UTF-16 кодиране.

От праткическа гледна точка, основният недостатък на UTF-32 е, че изисква 32 бита за всеки символ. В повечето случаи, за един символ в средностатистически текст са нужни по-малко, което води до лошо съотношение на значимите битове. В някои случаи, обаче, това не е от съществено значение (при употребата на APIs/приложно-програмни интерфейси изискващи UTF-32 текстови параметри, например) и удобството на фиксиран брой бита за кодова точка. Трябва да се има предвид и логичното следствие от увеличаването на нужното количество памет за съхраняване на еднакъв брой символи – а именно по-бързо достигане до кеш лимити; осезаемо увеличение на времето за писане/четене и т.н.