Источник: http://unicode.org/iuc/iuc17/b2/slides.ppt

17 Международная Юникод Конференция
Сан Хосе, Калифорния, сентябрь, 2000 г.
Из кода UCS-2 в код UTF-16

Обсуждение и типичные примеры по переводу библиотеки Юникода из кода UCS-2  в код UTF-16
В данном докладе рассматривается необходимость поддержки замещающих символов, исследуется множество вариантов их осуществления со всеми «за» и «против», а также предоставляются примеры на практике.
Так как подготовка второй части ISO 10646 и следующей версии Юникода подходит к концу, также необходимы приложения по Юникоду относительно поддержки заданных символов, существующих вне формата BMP. Хотя шифрование диапазона Юникод  было официально расширено по «замещающему»  принципу действия с помощью Юникода 2.0 в 1996, большое число внедрений все еще допускают, что шифр точки вписывается в 16 бит. В конце этого года, проекты для новых стандартных версий ожидаются неизменными, а предоставление замещающих символов для применения на рынках Восточной Азии вскоре потребует внедрений, поддерживающих полный диапазон Юникода.
К примеру, Международные составляющие для Юникода (ICU), проект открытого доступа, обеспечивает низкую степень поддержки в программе С и С++, подобно пакету Java JDK 1.1. Для поддержки полного диапазона шифрования некоторые интерфейсы прикладных программ и другие конечные программы разработки пришлось изменить. В данном докладе рассмотрены несколько вариантов по данной теме.
Интерфейсные блоки ввода данных и программные интерфейсы приложений напряду с готовыми разработанными программами были адаптированы для кода UTF-16 с 32-битным кодовым обозначением для единичных символов, а обзор их характерных особенностей привел к возможности работы с замещающими символами. Данный подход сравним с действиями других компаний и организаций, в особенности для Java, Linux и других программных средств, а также для Windows.
Почему это является проблемой?

Стандартный Юникод был разработан для шифрования свыше 65 000 символов; в программе «Стандартный Юникод, Версия 1.0» на второй странице сказано:
«Завершенность. Набор кодируемых символов достаточен для охвата всех символов, входящих в число наиболее используемых во всех текстовых обменах».
Считалось возможным наличие более 65 000 символов, так как редко применявшиеся, устаревшие, составные символы не шифровались – они не входили в число «наиболее используемых в текстовом обмене». Юникод включил область личного пользования нескольких тысяч кодируемых знаков для обеспечения подобных требований.
Единственная форма шифрования представляла собой постоянное 16-битное шифрование. С расширением кодового пространства, что стало необходимым позже, 16-битное шифрование стало меняющимся. Шифрование, базирующееся на байтах и 32-ьитном постоянном шифровании было добавлено позже. Данные изменения шли рука в руку с формированием и растущим признанием и применением Юникода.
16-битные  программные интерфейсы приложений

Программные библиотеки, разработанные несколько лет назад для Программных интерфейсов приложений и конечных программ, были рассчитаны на то, что текст Юникода будет сохранен в первоначальном 16-битной постоянной форме. Один 16-битный кодирующий блок в системе, которую стандарт ISO 10646 называет UCS-2,   всегда зашифровывал один символ Юникода. Это соответствует действительности в случае с версией Юникод 1.0 и 1.1.
В модели для библиотек, функционирующих с таким допущением, входят набор Microsoft Windows Win32 API  и все подобные наборы API, например, COM; Java с набором символов и комбинаций; Международные Комплектующие для Юникод (ICU); библиотека Qt от Troll Technologies для программирования пользовательского интерфейса с KDE-средой настольной системы, построенной на Qt.
Библиотеки, API и протоколы, разработанные в единицах байтовой обработки текстов применяет шифрование UTF-8 , базирующееся на байтовой системе. Оно шифрует практически все символы чуть больше, чем в один байт – такие системы были связаны с изменяющимся шифрованием после их окончательного становления международными.
Сходство с ISO-10646:

В 1993 Стандартный Юникод и ISO 10646-1 были объединены, поэтому они шифруют одинаковые символы с одинаковым цифровым кодом.
ISO 10646-1 определяет 31-битное кодовое пространство со значениями от нуля до fffffff16 для 2G символов. Каноническое шифрование, именуемое UCS-4, использует 32 интегральных значения (4 байта). Альтернативное шифрование UCS-2 покрывает множество значений вплоть до ffff16 с 16-битными (2-байтными) значениями. Ни к одному из символов не было применено значение выше, чем ffff16, однако несколько интервалов свыше данного значения были установлены для личного пользования. Первоначальный стандартный Юникод также использовал 16-битные кодирующие блоки, и два стандарта использовали подобные цифровые значения, начиная с объединения, завершенного в 1993.
UTF-8, первое изменяющееся шифрование на основе байтов для двух стандартов было создано даже раньше, чем (в 1992) системы с байтовой ориентацией для помощи переключений.  Оно допускает вплоть до 6 байт за символ  для всех систем UCS-4.
Определение (в 1994) UTF-16  как изменяющегося 16-битнтго шифрования для обоих стандартов позволяло расширение кодового диапазона Юникода. UTF-32 было охарактеризовано в 1999 для того, чтобы прояснить использование символов Юникода с более ограниченным диапазоном по сравнению с UCS-4 , но совершенно новым абсолютно совместимым способом.
В 2000, группа, работающая со стандартом ISO (JTC1/SC2/WG2) согласилась исключить любые перемещения над достижимым диапазоном UTF-16, то есть свыше 10ffff16, для того, чтобы исключить любые трудности в вопросе совместимости UCS-4, UTF-8, и UTF-16. 
Следующие слайды рассматривают каждую из этих мыслей
UCS-2 в UTF-32

Функции:
Изменение типа комбинации от 16-битного интеграла до 32-битного интеграла
Преимущества:
Допущения при программировании для UCS-2 остаются нетронутыми
Каждый символ сохраняется в едином кодовом блоке и тот же тип может быть применен для обоих строк и кодов
Недостатки:
Коэффициент загрузки памяти и вероятный спад в выполнении
Так как Юникод использует только 21бит, вне 11 из 32 бит  – 33%  никогда не будут использованы.
В действительности, с тех пор, как большинству общераспространенных символов были присвоены меньшие значения, типичные приложения никогда не будут использовать более чем 50 % памяти, которую занимают строки.
В текстовой обработке необходимо переместить больше памяти из основной и виртуальной в запас центрального процессора, что может занять большего времени  выполнения, чем сокращение в действии на символ с облегченного постоянного шифрования.
UCS-2 в UTF-8

Функция
Преобразование типа строки в UTF-8, что не влияет на выбор типа данных для кодируемых точек
Преимущество
UTF-8 является широкоизвестным меняющимся шифрованием ддля Юникода. Потребление памяти выше или ниже, чем с UTF-16 в зависимости от текста.
Недостаток
Изменение библиотеки UCS-2 для использования UTF-8 вполне разрушит большинство кодов для кодовых точек ниже ffff16 так как большая часть внедрения строится на том, что специальные символы (цифры, модификаторы, элементы управления за двунаправленным текстом, и т.д.) должны быть зашифрованы каждый в единичном блоке.
Примечание
Существующие UTF-8 системы требуют уверенности, что применены 4-байтные ряды и 21-битные кодовые точки; некоторые могут допускать, что UTF-8  никогда не будут использовать более чем 3 байта за символ и что скалярные значения впишутся в 16 бит, что было в случае с Юникод 1.1
Замещающие пары для единичных символов

Функция
Копирование кодовых точек программных интерфейсов приложений путем добавления замещающих вариантов. Строки находятся в UTF-16. Абоненту нужно проверить замещающую систему памяти и вызвать функциональный вариант и продвижение по тексту одним или двумя блоками в случае повтора.
Также возможно перемещение существующих функций одной системой памяти; абонент может всегда перемещаться между текущим и предыдущим кодирующим блоком. В данном случае, в функцию должно быть возвращено число блоков, применяемых для дальнейшего повтора. Для обратного повтора могут быть предусмотрены другие шаги.
Преимущество
Программные интерфейсные приложения могут работать с 16-битными интегралами
Недостаток
Модель применения заметно усложняется. Некоторая работа по распознаванию и взаимосвязи с заменяющими устройствами должна быть сделана дважды для трудоемких интерфейсов, первый раз абонентом, и второй раз для внедрения. Программное интерфейсное приложение по себе становится более запутанным и сложным в применении. Также кодирование символов является рассматриваемым. Обсуждаемым и применяемым в скалярных величинах. Принуждение программиста к расчету замещающих величин громоздко и подвержено ошибкам.
Функциональная совместимость

Дальнейшие заключения о поддержке замещающих символов содержат вопросы изменения и функциональной совместимости.
Желательно не изменять программную модель чаще, чем положено.
Также желательно применять подобный тип строк для использования других известных и важных систем: лидирующего программного продукта Юникода в Windows Win32 и COM, а также в Java применять 16-битные Юникодные строки,  также как XML DOM спецификацию и многие другие системы -  Windows является важной платформой, Java важный язык программирования,  и в особенности для ICU, открытый синтаксический анализатор  IBM XML является одним из важнейших приложений, использующих ICU.
UTF-16 является  также отступающим шифрованием Юникода, и подает надежды на одновременное использование памяти, выполнения и простоты применения.
Это приводит к решению продолжать применять 16-битные строки в ICU.

Вывод

Переход шифрования Юникода с UCS-2 в UTF-16 , начавшийся в 1994 с характеристики UTF-16 и был выпущен как часть Юникода 2.0 в 19996 приобретает значимость с действующими допущениями символов свыше ffff16, исследованных в 2001. В особенности символы CJKV ожидаются в восточноазиатской текстовой обработке и по всей вероятности они примут  доступ Юникода Восточной Азии.
Программное обеспечение, использующее 16-битный Юникод, требует модифицирования в расширенный диапазон шифрования. На уровне интерфейсов прикладных программ 16-битные строки синтаксически совместимы.  Односимвольные интерфейсы прикладных программ требуют изменений, или более доступной версии, если они используют 16-битьные интегралы для Юникодовых точек. Действующие кодовые точки принимают до 21 бита.
Для передачи интерфейсов прикладных программ в замещающую поддержку существует несколько способов, и несколько из них рассматриваются в данной презентации.
Литература

ВЕРНУТЬСЯ НАЗАД