Замечания по выпуску


40.1 Введение

Стандарт Unicode - универсальная схема кодирования символов для записи символов и текста. Unicode использует многобайтное представление символов. Unicode представляет логичный способ кодирования многоязычных текстов, поддерживающий международный обмен текстовыми данными и создающий основу для написания программ, работающих в любой языковой среде.

В Unicode есть две следующие схемы кодирования. По умолчанию используется схема кодирования UTF-16 с 16-битным форматом. UCS-2 представляет собой поднабор UTF-16, использующий для представления одного символа два байта. UCS-2 обычно воспринимается как универсальная кодовая страница, способная представлять все необходимые символы всех существующих одно- и двухбайтных кодовых страниц. UCS-2 зарегистрирована в IBM как кодовая страница 1200.

Другой формат кодирования Unicode - байт-ориентированный формат UTF-8, разработанный для облегчения его использования с существующими системами на основе ASCII. UTF-8 использует для хранения одного символа переменное число байтов (обычно 1 - 3, иногда 4). Инвариантные символы ASCII хранятся в виде одиночных байтов. Любой другой символ хранится, как несколько байт. В общем случае данные UTF-8 можно рассматривать как расширение данных ASCII, а не как код для многобайтных кодовых страниц. UTF-8 зарегистрирован в IBM как кодовая страница 1208.

Важно, чтобы прикладные программы учитывали требования к размеру данных при их преобразовании между национальной кодовой страницей, UCS-2 и UTF-8. Например, для 20 символов в UCS-2 потребуется ровно 40 байтов, а в UTF-8 - от 20 до 60 в зависимости от исходной кодовой страницы и использованных символов.

40.1.1 Базы данных Unicode и прикладные программы DB2

В Unix, Windows и OS/2 база данных DB2 UDB, созданная с кодовым набором UTF-8, может использоваться для хранения данных как в формате UCS-2, так и UTF-8. Такая база данных называется базой данных Unicode. Данные SQL с типом CHAR кодируются с использованием UTF-8, а данные SQL с типом GRAPHIC кодируются с использованием UCS-2. Это можно сопоставить с сохранением однобайтных (SBCS) и многобайтных кодовых наборов (MBCS) в столбцах CHAR и сохранением двухбайтных кодовых наборов (DBCS) в столбцах GRAPHIC.

Кодовая страница прикладной программы может не совпадать с кодовой страницей, которую DB2 использует для хранения данных. В других базах данных (не Unicode) при несовпадении этих кодовых страниц менеджер баз данных преобразует символьные и графические (исключительно DBCS) данные при переносе их между клиентом и сервером. В базе данных Unicode менеджер баз данных автоматически выполняет преобразование символьных данных между кодовой страницей клиента и UTF-8, но все графические данные (UCS-2) передаются между клиентом и сервером без преобразования.

Рис. 1. Преобразования кодовых страниц, выполняемые менеджером баз данных


Преобразования кодовых страниц, выполняемые менеджером баз данных

Примечания:

  1. Если при подключении к базам данных Unicode прикладная программа устанавливает DB2CODEPAGE=1208, локальная кодовая страница будет UTF-8, и преобразование кодовых страниц не требуется.

  2. При подключении к базе данных Unicode прикладные программы CLI могут также принимать символьные данные как графические данные, а графические данные - как символьные данные.

Для прикладной программы можно указать кодовую страницу UTF-8, что означает, что она будет передавать и получать все графические данные в UCS-2, а символьные данные - в UTF-8. Эта кодовая страница прикладной программы поддерживается только для баз данных Unicode.

При использовании Unicode необходимо также принимать во внимание следующее:

  1. Кодовая страница определяется во время создания базы данных, и по умолчанию ее значение определяется из версии (или кодовой страницы) операционной системы. Чтобы создать базу данных DB2 Unicode явным образом, можно использовать ключевые слова CODESET и TERRITORY. Например:
    CREATE DATABASE unidb USING CODESET UTF-8 TERRITORY US
    
  2. Кроме того, кодовая страница прикладной программы по умолчанию совпадает с локальной кодовой страницей, но может быть заменена на UTF-8 одним из двух способов:

    
    
  3. Данные в столбцах GRAPHIC будут занимать ровно по два байта на каждый символ Unicode, а данные в столбцах CHAR на каждый символ Unicode будут занимать от 1 до 3 байтов. Ограничения SQL на число символов для столбцов GRAPHIC в общем случае вдвое меньше, чем для столбцов CHAR, но по числу байтов они одинаковы. Максимальная длина в символах для столбца CHAR равна 254. Максимальная длина в символах для графического столбца равна 127. Дополнительную информацию смотрите описание MAX в главе "Functions" справочника SQL Reference.
    
    
  4. Графический литерал отличают от символьного литерала по префиксу G. Например:
    SELECT * FROM mytable WHERE mychar = 'данные utf-8' AND
    mygraphic = G'данные ucs-2'
    

    Прим.:Для баз данных Unicode префикс G не требуется.
    Дополнительная информация и обновленная поддержка приводятся в разделе "Литералы в базах данных Unicode".

    
    
  5. Поддержка для прикладных программ CLI/ODBC и JDBC отличается от поддержки для встроенных программ. Конкретную информацию о поддержке CLI/ODBC смотрите в разделе 40.3, "CLI Guide and Reference".
    
    
  6. Число байтов, необходимых для данных UCS-2, может быть различным на разных платформах. Во внутреннем формате DB2 используется прямой порядок байтов.

40.1.2 Обновление документации

В этом документе изменена следующая информация об использовании Unicode с DB2 версии 7.1:

Дополнительную информацию об использовании Unicode с DB2 смотрите в книге Руководство администратора, Приложение J. Поддержка национальных языков (NLS): "Поддержка Unicode/UCS-2 и UTF-8 в DB2 UDB".


[ Начало страницы | Страница назад | Страница вперед | Содержание | Индекс ]