Вот хорошая документация от Консорциума Unicode.
Copyright © 1991–2009 Unicode, Inc. Стандарт Юникод, версия 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 не обязательно соответствуют ожиданиям пользователя в отношении «символов». Например, следующее не представлено одной кодовой точкой: комбинация символьной последовательности, такая как; последовательность джамо для корейского; или конъюнкт Деванагари «ksha». Поскольку некоторая обработка текста в Юникоде должна учитывать такие последовательности символов и обрабатывать их как текстовые элементы, преимущество UTF-32 в форме кодирования с фиксированной шириной несколько компенсируется присущей ему переменной. Характер ширины обработки текстовых элементов. См. Технический стандарт Unicode № 18 «Регулярные выражения Unicode», где приведен пример, в котором обычно реализуемые процессы имеют дело с текстовыми элементами по своей природе переменной ширины из-за ожиданий пользователя в отношении идентичности «символа».
UTF-8. UTF-8 - это причинаbly compact с точки зрения количества используемых байтов. На самом деле он имеет только существенный недостаток в размере, когда используется для восточноазиатских реализаций, таких как китайский, японский и корейский, которые используют идеограммы Хань или слоги хангыль, требующие трехбайтовых последовательностей кодовых единиц в UTF-8. UTF-8 также значительно менее эффективен с точки зрения обработки, чем другие формы кодирования.
Бинарная сортировка. Бинарная сортировка строк UTF-8 дает тот же порядок, что и двоичная сортировка кодовых точек Юникода. Это, очевидно, тот же порядок, что и для двоичной сортировки строк UTF-32.
Общая структура
Все три формы кодирования дают одинаковые результаты для сравнения двоичных строк или сортировки строк при работе только с символами BMP (в диапазоне U + 0000..U + FFFF). Однако при работе с дополнительными символами (в диапазоне U + 10000..U + 10FFFF) двоичный порядок UTF-16 не соответствует порядку кодовых точек Unicode. Это может привести к осложнениям при попытке взаимодействия с двоичными отсортированными списками, например, между системами UTF-16 и системами UTF-8 или UTF-32. Однако для данных, которые отсортированы в соответствии с условностями конкретного языка или локали, а не с использованием двоичного порядка, данные будут упорядочены одинаково, независимо от формы кодирования.