Почему UTF-32 вместо UTF-16, если у нас есть суррогатные пары?

Короткий ответ: нет.

Более длинный ответ: да, для совместимости с другими вещами, которые не получили заметку.

Меньше саркастического ответа: Когда Вы заботитесь больше о скорости индексации, чем об использовании пространства, или как какой-то промежуточный формат, или на машинах, где проблемы выравнивания были более важными, чем проблемы кэша, или...

Кто-то мог бы предпочесть иметь дело с UTF-32 вместо UTF-16, потому что контакт с суррогатными парами в значительной степени всегда обрабатывает 'особые случаи' и имеет необходимость иметь дело с теми средствами особых случаев, что у Вас есть области, где ошибки могут закрасться, потому что Вы имеете дело с ними неправильно (или более вероятно просто забываете иметь дело с ними вообще).

Если увеличенное использование памяти UTF-32 не является проблемой, уменьшенная сложность могла бы быть действительно преимуществом для выбора его.

Существует, вероятно, несколько серьезных оснований, но нужно было бы ускорить индексацию / поиск, т.е. в базах данных и т.п..

С UTF-32 Вы знаете, что каждый символ составляет 4 байта. С UTF-16 Вы не знаете, каков длина какой-то конкретный символ будет.

Например, у Вас есть функция, которая возвращает энный символ строки:

char getChar(int index, String s );

Если Вы кодируете на языке, который имеет прямой доступ к памяти скажем C, то в UTF-32 эта функция может быть столь же простой как некоторая арифметика указателя (s+(4*index)), который был бы некоторыми суммами O (1).

Если бы Вы используете UTF-16, хотя, необходимо было бы обойти строку, декодируя, когда Вы пошли, который будет O (n).

UTF-8 может также представить любой unicode символ!

Если Ваш текст является главным образом английским, можно оставить много свободного места при помощи utf-8, но символы индексации не являются O (1), потому что некоторые символы поднимают больше, чем всего один байт.

Если пространство не так важно для Вашей ситуации, как скорость, utf-32 подошел бы Вам лучше, потому что индексация является O (1)

UTF-16 может быть лучше, чем utf-8 для неанглийского текста, потому что в utf-8 у Вас есть ситуация, где некоторые символы поднимают 3 байта, где как в utf16 они только подняли бы два байта.

Вот и хорошая документация от Консорциума Unicode.

Сравнение преимуществ UTF-32, UTF-16 и UTF-8

Copyright © 1991–2009 Unicode, Inc. Стандарт Unicode, версия 5.2

На первый взгляд, UTF-32 Казалось бы, очевидный выбор форм кодирования Unicode для кода внутренней обработки, потому что это форма кодирования фиксированной ширины. Он может быть соответствующим образом привязан к C и C ++ wchar_t , что означает, что такие языки программирования могут предлагать встроенную поддержку и готовые строковые API-интерфейсы, которыми могут воспользоваться программисты. Однако UTF-16 имеет множество преимуществ, которые могут побудить разработчиков выбрать его вместо кода внутренней обработки. Хотя всем трем формам кодирования требуется не более 4 байтов (или 32 бита) данных для каждого символа, на практике UTF-32 почти во всех случаях для реальных наборов данных занимает вдвое больше памяти, чем требуется для UTF-16. Поэтому распространенной стратегией является использование во внутреннем хранилище строк UTF-16 или UTF-8, но использование UTF-32 при манипулировании отдельными символами.

UTF-32 против UTF-16. В среднем более 99 процентов всех данных UTF-16 выражаются с использованием единичных кодовых единиц. Сюда входят почти все типичные символы, которые программное обеспечение должно обрабатывать с помощью специальных операций с текстом, например, символы управления форматом. Как следствие, большинство операций сканирования текста вообще не нуждаются в распаковке суррогатных пар UTF-16, а могут безопасно обрабатывать их как непрозрачную часть символьной строки.Для многих операций UTF-16 так же прост в обращении, как и UTF-32, а производительность UTF-16 как кода обработки имеет тенденцию быть довольно хорошей. UTF-16 - это предпочтительный код внутренней обработки для большинства реализаций, поддерживающих Unicode. За исключением платформ Unix, UTF-16 обеспечивает правильное сочетание компактного размера с возможностью обработки случайных символов вне BMP. UTF-32 имеет некоторое преимущество, когда дело доходит до простоты разработки программного кода и обслуживания. Поскольку обработка символов имеет фиксированную ширину, обработка UTF-32 не требует поддержки ветвей в программном обеспечении для тестирования и обработки элементов двойного кода, необходимых для дополнительных символов UTF-16. И наоборот, 32-битные индексы в больших таблицах не особенно эффективны с точки зрения памяти. Чтобы избежать больших потерь памяти из-за таких индексов, таблицы Unicode часто обрабатываются как многоступенчатые таблицы (см. «Многоступенчатые таблицы» в разделе 5.1, Транскодирование в другие стандарты). В таких случаях 32-битные значения кодовой точки разделяются на меньшие диапазоны, чтобы разрешить сегментированный доступ к таблицам. Это верно даже для типичных реализаций UTF-32. Производительность UTF-32 как кода обработки на самом деле может быть хуже, чем производительность UTF-16 для тех же данных, потому что дополнительные накладные расходы памяти означают, что ограничения кеша будут превышаться чаще, а подкачка памяти будет происходить чаще. Для систем с процессорами, которые налагают штрафы за 16-битный доступ с выравниванием, но имеют очень большой объем памяти, этот эффект может быть менее заметным.В любом случае кодовые точки Unicode не обязательно соответствуют ожиданиям пользователей в отношении «символов». Например, следующие элементы не представлены одной кодовой точкой: последовательность комбинируемых символов, такая как; смежная последовательность джамо для корейского языка; или Деванагари в соединении «кша». Поскольку некоторая обработка текста Unicode должна учитывать и обрабатывать такие последовательности символов как текстовые элементы, преимущество формы кодирования с фиксированной шириной UTF-32 в некоторой степени компенсируется присущей обрабатываемым текстовым элементам природой переменной ширины. См. Технический стандарт № 18 Unicode, «Регулярные выражения Uni-code», где приведен пример, где обычно реализуемые процессы имеют дело с текстовыми элементами переменной ширины из-за ожиданий пользователя от идентичности «символа». UTF-8. UTF-8 достаточно компактен с точки зрения количества используемых байтов. На самом деле он имеет существенный недостаток в размере только при использовании для восточноазиатских реализаций, таких как китайский, японский и корейский, которые используют идеограммы хань или слоги хангыль, требующие трехбайтовых последовательностей кодовых единиц в UTF-8. UTF-8 также значительно менее эффективен с точки зрения обработки, чем другие формы кодирования. Бинарная сортировка. Бинарная сортировка строк UTF-8 дает тот же порядок, что и двоичная сортировка кодовых точек Unicode. Очевидно, это тот же порядок, что и для двоичной сортировки строк UTF-32.

Общая структура

Все три формы кодирования дают одинаковые результаты для сравнения двоичных строк или сортировки строк при работе только с символами BMP (в диапазоне U + 0000..U + FFFF).Однако при работе с дополнительными символами (в диапазоне U + 10000..U + 10FFFF) двоичный порядок UTF-16 не соответствует порядку кодовых точек Unicode. Это может привести к осложнениям при попытке взаимодействия с двоичными отсортированными списками - например, между системами UTF-16 и системами UTF-8 или UTF-32. Однако для данных, отсортированных в соответствии сИзобретения определенного языка или локали, а не использование двоичного порядка, данные будут упорядочены одинаково, независимо от формы кодирования.

В общем, вы просто используете строковый тип данных/кодировку базовой платформы, которая часто (Windows, Java, Cocoa...) UTF-16, а иногда UTF-8 или UTF-32. В основном это объясняется историческими причинами; разница между тремя кодировками Unicode невелика: все три хорошо определены, быстры и надежны, и все они могут кодировать все последовательности кодовых точек Unicode. Уникальная особенность UTF-32 в том, что это кодировка фиксированной ширины (это означает, что каждая кодовая точка представлена ровно одной кодовой единицей), на практике малоприменима: Ваш уровень управления памятью должен знать о количестве и ширине кодовых единиц, а пользователей интересуют абстрактные символы и графемы. Как указано в стандарте Unicode, приложениям Unicode все равно приходится иметь дело с комбинированными символами, лигатурами и так далее, и работа с суррогатными парами, несмотря на концептуальное отличие, может быть выполнена в тех же технических рамках.

Если бы мне пришлось заново изобретать мир, я бы, вероятно, выбрал UTF-32, потому что это просто наименее сложная кодировка, но в нынешнем виде различия слишком малы, чтобы иметь практическое значение.