Наткнулся на статью «UTF-8 is a Brilliant Design», которая довольно хорошо объясняет, как работает кодировка UTF-8.
Но мне кажется, автор, говоря о дизайне UTF-8, забыл упомянуть, что UTF-8 ещё и хорошо справляется с чтением со случайного места: если ткнуть в случайный байт, и он начинается с битов 10, то мы можем прочитать несколько байтов назад до начального, т.е. у нас не будет ситуаций, что символ, который мы прочтём, будет битым.
Но вот если где UTF-8 и проседает, так это в определении количества символов. Да, ты можешь ткнуть в определённый байт, и прочесть его, и понять, какой это символ. Но когда тебе нужен определённый символ по номеру, возникает проблема, потому что тебе надо пробежаться по всей строке.
UTF-16 и UTF-32 в этом плане больше выигрывают: ты попросту делишь байты на 2 или 4 и сразу можешь узнать индекс символа. Главное разве что знать, в каком порядке байты идут. Но, конечно же, размер файла (особенно, если там только латиница из таблицы ASCII) будет сильно выше.
Но мне кажется, автор, говоря о дизайне UTF-8, забыл упомянуть, что UTF-8 ещё и хорошо справляется с чтением со случайного места: если ткнуть в случайный байт, и он начинается с битов 10, то мы можем прочитать несколько байтов назад до начального, т.е. у нас не будет ситуаций, что символ, который мы прочтём, будет битым.
Но вот если где UTF-8 и проседает, так это в определении количества символов. Да, ты можешь ткнуть в определённый байт, и прочесть его, и понять, какой это символ. Но когда тебе нужен определённый символ по номеру, возникает проблема, потому что тебе надо пробежаться по всей строке.
UTF-16 и UTF-32 в этом плане больше выигрывают: ты попросту делишь байты на 2 или 4 и сразу можешь узнать индекс символа. Главное разве что знать, в каком порядке байты идут. Но, конечно же, размер файла (особенно, если там только латиница из таблицы ASCII) будет сильно выше.