Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Как вы можете работать с группой символьных данных, которые вы сохранили с использованием неверного набора символов? "Трюк" заключается в использовании набора символов 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;

Набор символов для клиентского соединения

Когда клиентское приложение, например, isql, соединяется с базой данных, в протоколе соединения присутствует часть, которая информирует сервер о требуемом наборе символов. Набором символов соединения является нейтральный набор символов NONE, если не указано другое с использованием:

* SET NAMES во встроенном приложении или в isql;

* параметра isc_dpb_ic_ctype в блоке параметров базы данных (DPB) для API- функции isc_attach_database(). Классы RAD соединения с базой данных для Delphi, Java и других обычно представляют этот параметр как свойство.

Клиентское приложение задает набор символов до его соединения с базой данных. Например, следующая команда isql определяет, что isql использует набор символов ISO88591. По команде происходит соединение с базой данных autord.fdb из нашего предыдущего примера:

SET NAMES WIN1251;

CONNECT 'lserver:/data/authors.fdb' USER 'ALICE' PASSWORD 'XINEOHP';

Специальные наборы символов

Основное правило для наборов символов то, что каждый байт (пара или тройка байтов в случае многобайтовых наборов) специально определен по стандарту его реализации. Существует четыре особых исключения - NONE, OCTETS, ASCII и UNICODE FSS. В табл. 11.1 показаны специальные свойства этих наборов.

Таблица 11.1. Специальные наборы символов

Имя	Свойства
NONE	Каждый байт является частью строки, но не имеется никаких предположений, к какому набору символов он принадлежит. Код клиентской стороны или определенный пользователем на сервере код является ответственным за правильность символа
OCTETS	Байты, которые не интерпретируются как символы. Полезен для хранения двоичных данных
ASCII	Значения 0-127 определены как ASCII. Значения за пределами этого диапазона не являются символами, но поддерживаются. Firebird совершенно либерален относительно транслитерации байтов в диапазоне 0-127 символов ASCII
UNICODE_FSS	Разработчикам нужно знать, что он эффективен при реализации UTF8. Пользователям нужно знать, что он может быть использован для хранения символов UCS16, но не UCS32 (может занимать до шести байтов на символ). Недоступна ни одна последовательность сортировки, кроме двоичной последовательности по умолчанию

ISO8859_1 (LATIN_1) и WIN1252