Здравствуйте, Videoman, Вы писали:

V> О каких проверках речь? На практике в 90% случаем обработка UTF-8 строк почти не отличается от таковой же в ASCII. Если мы итерируемся именно по символам, то символы в Юникоде в общем виде могут занимать несколько кодпоинтов, идти справа на лево, даже в UTF-32, так что не надо упрощать.

Итеририровать кодпоинты. В utf-8 четыре проверки, в utf-16 — одна. Вопрос нормализации выносим за скобки т.к. он существует вне зависимости от кодировки.

V> R>2. Все что за пределами ascii кодируется, либо тем же количеством байт, что и в UTF-16, либо большим.

V> Зависит от данных и статистики. На практике, многие многих форматы (Code, JSON, XML и т.д.) и наиболее распространенные языки будут занимать меньше.

Я вроде согласился, что как кодировка для сериализации utf-8 удобна, но мы говорим о хранении и обработке строк. При хранении той же кириллицы от utf-8 профита никакого, при хранении китайских иероглифов utf-8 еще и более требовательна к памяти. Единственный выигрыш это латиница.

V> R>3. В UTF-16 почти все что нужно лежит в пределах BMP (т.е. суррогатная пара не требуется), а значит такие строки могут иметь индексный доступ.

V> Что нужно ?! В Юникоде куча символов может состоять из нескольких кодпоинтов, независимо от суррогатных пар, и это в любой кодировке: UTF-8/16/32.

Я о том, что кодпоинты вне BMP это эмоджи и прочее.