Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Наборы символов Firebird

Наборы символов Firebird

Firebird поддерживает увеличивающееся количество интернациональных наборов символов, включая 2- и 3-байтовые наборы Unicode. Во многих случаях возможен выбор последовательности подбора (сортировки). В этом разделе мы рассмотрим:

* происхождение наборов символов;

* глобальные наборы символов по умолчанию для базы данных;

* альтернативные наборы символов и последовательности сортировки для доменов и столбцов;

• последовательности сортировки для:

• текстовых значений в операциях сравнения;

• предложений ORDER BY и GROUP BY;

• как указать серверу необходимость трансляции вводимых данных в конкретный набор символов.

Набор символов является собранием символов, который включает, по меньшей мере, один репертуар символов. Репертуар символов является набором символов, используемым в конкретной культуре для публикаций, письменной коммуникации и - в контексте базы данных - для компьютерного ввода и вывода. Например, ISO Latin 1 является набором символов, который охватывает английский (А, В, С ... Z) и французский (А, А, А, В, С, Q, D ... Z) репертуары, делающие его полезным для обоих сообществ.

Большинство наборов символов Firebird определены на основании стандартов и их имена близко соответствуют этим стандартам. Например, Microsoft определяет Windows 1251, a Firebird реализует его как WIN1251. Набор символов ISO8859_1 является "набором символов, определенным в стандарте ISO 8859-1, кодированным значениями, определенными в стандарте ISO 8859-1, каждое значение представлено одним 8-битовым байтом".

Имена алиасов наборов символов поддерживают разницу в именовании стандартов между платформами. Например, если вы найдете, что в операционной системе используется идентификатор WIN 1251 для набора символов WIN1251, вы можете использовать алиас, определенный в системной таблице RDB$TYPES, как описано в следующем разделе.

Наборы символов в настоящий момент "зашиты" в базу данных с момента ее создания. Одной из системных таблиц, создаваемых автоматически, является RDB$CHARACTER_SET. Для отображения имен наборов символов с последовательностью сортировки каждого из них выполните запрос:

SELECT

RDB$CHARACTER_SET_NAME,

RDB$DEFAULT_COLLATE_NAME,

RDB$BYTES_PER_CHARACTER

FROM RDB$CHARACTER_SETS

ORDER BY 1 ;

Если требуется, алиасы помещаются в RDB$TYPES- другую системную таблицу, которая хранит список алиасов, используемых сервером базы данных. Для просмотра всех алиасов, которые были установлены во время создания базы данных, выполните следующий запрос, который фильтрует RDB$TYPES для просмотра только имен наборов символов:

SELECT

С. RDB$CHARACTER_SET_NAME,

T.RDB$TYPE_NAME

FROM RDB$TYPES T

JOIN RDB$CHARACTER_SETS С

ON C.RDB$CHARACTER_SET_ID = T.RDB$TYPE

WHERE T.RDB$FIELD_NAME = 'RDB$CHARACTER_SET_NAME'

ORDER BY 1 ;

! ! !

ПРИМЕЧАНИЕ. Для того чтобы использовать наборы символов, отличные от NONE, ASCII, OCTETS и UNICODE_FSS, необходимо иметь библиотеку fbintl в каталоге /intl корневого каталога Firebird.

. ! .

Важно понимать, как ваш выбор набора символов влияет на хранение планируемых вами ограничений для данных. В случае столбцов CHAR и VARCHAR Firebird ограничивает максимальный объем памяти хранения любого поля в столбце значениями 32 767 и 32 765 соответственно. На самом деле требуемое фактическое количество может быть сильно ограничено.

Неиндексируемые столбцы, использующие последовательность сортировки по умолчанию, могут хранить не более (количество символов)*(количество байтов на символ) для типа данных. Например, VARCHAR(32765) с набором символов ISO_8859_1 может хранить не более 32 765 символов, тогда как при наборе символов UNICODE_FSS (который использует три байта на символ) максимальное количество 10 291 символ.

Если столбец предполагается индексировать и/или изменить предложением COLLATE, должно быть добавлено значительное количество "запасных" байтов. Даже наименее требовательный индекс - один столбец VARCHAR, использующий однобайтовый набор символов и последовательность сортировки по умолчанию - ограничен размером 252 байта для Firebird версии 1.5 и выше. Для столбцов с многобайтовыми наборами символов количество символов меньше, чем 252 / (количество байтов на символ). Многостолбцовые индексы требуют больше байтов, чем одностолбцовые, а те, которые используют последовательность сортировки не по умолчанию, требуют еще больше.

Более подробно об этих эффектах см. разд. "Последовательность сортировки и размер индекса" далее в этой главе.

! ! !

СОВЕТ. При проектировании столбцов всегда рассматривайте возможные требования с точки зрения использования набора символов, индексирования и ключа. Всегда держите "черновую" таблицу в разрабатываемой базе данных для тестирования ограничений индексов и ключей.

. ! .

Хранение столбцов BLOB, которые не являются индексируемыми, никак не ограничивается использованием набора символов.

Если вы не указываете набор символов по умолчанию для базы данных в объявлении CREATE DATABASE, то набор символов по умолчанию устанавливается в NONE. Набор символов NONE не предполагает никакого набора символов для текстовых столбцов, сохраняя данные точно в том виде, в каком они были введены. Если клиентское соединение не указывает набора символов, то данные также будут отыскиваться точно так, как они были введены. Алфавитно-цифровое упорядочение ограничено упорядочением кодов ASCII, а преобразование верхний/нижний регистр поддерживается только в кодах U.S.ASCII 65-90 и 97-102 соответственно.

Указывайте допустимый код набора символов в предложении DEFAULT CHARACTER SET:

CREATE DATABASE '/data/adatabase.fdb'

. . .

DEFAULT CHARACTER SET WIN1251;

Более подробную информацию об операторе CREATE DATABASE см. в главе 12.

Атрибут набора символов может быть добавлен к индивидуальному определению домена, столбца таблицы или переменной PSQL типа CHAR, VARCHAR или BLOB SUB_TYPE 1 для перекрытия набора символов по умолчанию базы данных.

Например, следующий фрагмент скрипта создает базу данных с набором символов по умолчанию ISO8859_1 и таблицу, содержащую различные версии языка похожих данных в отдельных столбцах:

CREATE DATABASE '/data/authors.fdb' DEFAULT CHARACTER SET ISO8859_1;

CREATE TABLE COUNTRY_INTL(

CNTRYCODE BIGINT NOT NULL,

NOM_FR VARCHAR(30) NOT NULL,

/* использует набор символов по умолчанию */

NOM_EN VARCHAR(30), /* использует набор символов по умолчанию */

NOM_RU VARCHAR(30) CHARACTER SET WINI251,

NOM_JP VARCHAR(30) CHARACTER SET SJIS_0208

Другой фрагмент того же скрипта создает домен для хранения данных BLOB В наборе символов кириллицы:

CREATE DOMAIN MEMO_RU AS BLOB SUB_TYPE 1

CHARACTER SET WIN1251;

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

CREATE TABLE NOTES_RU (

DOC_ID BIGINT NOT NOLL,

NOTES MEMO_RU

Следующий фрагмент определяет хранимую процедуру, которая преобразует входную строку в другой набор символов перед сохранением ее в таблице:

CREATE PROCEDURE CONVERT_NOTES (

INPUT_TEXT VARCHAR(300) ) AS

DECLARE VARIABLE CONV_STRING WARCHAR(300)

CHARACTER SET WIN1251;

BEGIN

IF (INPUT JTEXT IS NOT NULL) THEN

BEGIN

CONV_STRING = _WIN1251 ' ' || : INPUT_TEXT;

/* использует INTRODUCER */

INSERT INTO NOTES_RU (DOC_ID, NOTES)

VALUES (GEN_ID (ANYGEN, 1) , :CONV_STRING) ;

END

END ^

Создание доменов объясняется в главе 13. Полный синтаксис оператора CREATE TABLE описан в главе 15. Объявление переменных в PSQL см. в главе 30.

Набор символов для текстовых значений в операторе интерпретируется в соответствии с набором символов соединения в процессе выполнения (а не в соответствии с набором символов, определенным для столбца при его создании), если только вы не зададите маркер набора символов (или "представитель") для указания другого набора символов.

Маркер набора символов - также известный как INTRODUCER- состоит из имени набора символов, перед которым стоит символ подчеркивания. Он требуется для "представления" входной строки, когда приложение клиента соединено с базой данных с использованием набора символов, отличного оттого, который определен для столбца в базе данных.

Установите маркер слева от отмечаемого текстового значения. Например, маркером для ввода в UMCODE_FSS поле является _UNICODE_FSS:

INSERT INTO EMPLOYEE(Emp_ID, Emp_Name)

values(1234, _UNICODE_ESS 'Smith, John Joseph');

! ! !

СОВЕТ. Для ясности вы можете вставить пробел между маркером и строкой без какого-либо влияния на способ синтаксического анализа вводимого данного.

. ! .

Строковый литерал в условии проверки или поиска, например в предложении WHERE, интерпретируется в соответствии с набором символов клиентского соединения в момент проверки условия. Маркер потребуется, когда отыскиваемый столбец базы данных имеет набор символов, отличный от того, который был указан в клиентском соединении:

... WHERE name = _ISO8859_1 'joe';

! ! !

СОВЕТ. Когда вы разрабатываете приложение со смешанными наборами символов, то удобно использовать маркеры, особенно если ваше приложение будет работать со многими базами данных и/или будет распространяться интернационально.

. ! .

Преобразование символов из одного набора символов Firebird в другой - например, конвертирование из DOS437 в ISO8859_1 - является транслитерацией. Транслитерация в Firebird сохраняет точность символов: по определению она не подставляет никакого "заменителя" для входного символа, который не представлен в выходном наборе символов. Назначением такого ограничения является гарантия того, что возможна транслитерация одного и того же текста из одного набора символов в другой в любом направлении без потери символов в процессе транслитерации.

Firebird выдает сообщение об ошибке, если символ во входном наборе не имеет точного представления в выходном наборе.

Пример, где может появиться ошибка транслитерации: когда приложение передает данные некоторого неопределенного набора символов в столбец, определенный с NONE, и позже пытается выбрать эти данные и поместить в другой столбец, который был определен с отличающимся набором символов. Хотя вы думаете, что это должно работать, потому что образы символов, похоже, принадлежат набору символов столбца назначения, транслитерация будет ошибочной, поскольку символ не представлен в наборе символов столбца назначения.

Как вы можете работать с группой символьных данных, которые вы сохранили с использованием неверного набора символов? "Трюк" заключается в использовании набора символов OCTETS в качестве "промежуточного аэродрома" между ошибочным и правильным кодированием. Поскольку OCTETS является специальным набором символов, который, не глядя, сохраняет то, что вы ему подсовываете (без транслитерации), он является идеальным для того, чтобы сделать символьные коды нейтральными в отношении кодовой страницы.

Предположим, ваша проблемная таблица имеет столбец COL ORIGINAL, который вы случайно создали с набором символов NONE, когда имели в виду CHARACTER SET WIN1251. Вы загрузили в этот столбец данные на русском языке, но каждый раз, когда вы пытаетесь получить из него данные, вы получаете противную ошибку транслитерации.

Вот что вам нужно сделать:

ALTER TABLE TABLEA

ADD COL_WIN1251 VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET COL_WIN1251 = CAST(COL_ORIGINAL AS CHAR(30) CHARACTER SET OCTETS);

Теперь у вас есть временный столбец, созданный для хранения русских текстов, он хранит все из ваших "потерянных" текстов из неиспользуемого столбца COL ORIGINAL. Вы можете удалить столбец COL_ORIGINAL, а затем новый столбец COL_ORIGINAL С корректным набором символов. Просто скопируйте данные из временного столбца, и после подтверждения транзакции удалите временный столбец:

ALTER TABLE TABLEA

DROP COL_ORIGINAL;

COMMIT;

ALTER TABLE TABLEA

ADD COL_ORIGINAL VARCHAR(30) CHARACTER SET WIN1251;

COMMIT;

UPDATE TABLEA

SET СOL_ORIGINAL = COL_WIN1251;

COMMIT;

/* Было бы разумным сейчас посмотреть ваши данные! */

ALTER TABLE TABLEA

DROP COL_WIN1251;

COMMIT;

Оглавление книги