IBProvider Developer's Blog

UNICODE Mode для IB/FB

Привет всем.

Шарясь по интернету, я в очередной раз наткнулся на существование ключика «юникодный режим» у различных компонент доступа к IB/FB. У провайдера такой тоже есть — unicode_mode. Но в IBP v3 он уже давно выполняет другую задачу.

В зависимости от значения этого свойства инициализации, провайдер будет публиковать текстовые данные либо в WSTR-колонках (unicode_mode=true), либо в STR-колонках (unicode_mode=false). Как правило, клиент запрашивает данные в формате колонки.

Больше «unicode_mode» ни на что не влияет. Вы можете принудительно работать с текстовые данные в виде WSTR. Вне зависимости от того какой тип (STR или WSTR) предлагает вам провайдер в описании колонки/параметра. Или в виде STR. Провайдер будет выполнять все необходимые (для корректной работы) преобразования автоматически. Приблизительно так же, как это делает сам сервер БД. Только лучше.

Если вы хотите работать с данными в виде STR (мультибайтные строки), то обратите внимание на свойство инициализации ctype_user. Оно определяет кодовую страницу пользователя. Например, вы храните данные в виде UNICODE_FSS, а работать с ними хотите в виде WIN1251. Тут некоторые воскликнут — а я укажу кодовую страницу подключения WIN1251, и сервер выполнит все необходимые преобразования автоматически. Выполнит, если это FB2.1+. А у остальных (включая все версии IB) будут реальные проблемы. У 2.1 тоже будут проблемы. Так что такие эксперименты — только начиная с FB2.5. Для остальных — «ctype=UNICODE_FSS;ctype_user=WIN1251» и никаких проблем.

Для преобразования кодовых страниц провайдер использует собственные таблицы/алгоритмы перекодировки. Большая часть которых были позаимствованы из исходных текстов Firebird. Поэтому вы можете не беспокоится о возможной зависимости от локализации операционной системы. Её просто нет.

В идеале, пользователь вообще не должен беспокоится о кодовой странице. И, полагаю, к нему можно приблизиться используя FB2.5 и кодовую страницу подключения (ctype) UTF8. Я говорю «приблизиться», потому что лучше было бы вообще ничего не указывать (то есть работать в NONE-подключении), и оставить все на усмотрение провайдера. Но к сожалению у NONE-подключения есть одна проблема — нужно использовать «маркеры» кодовых страниц для литер в тексте запроса. Типа «select _win1251 ‘русский текст’ from …». Не очень удобно. Так что будем ждать пока API сервера не станет нормальным, то есть юникодным. И без других «утомляющих» ограничений. Типа 32K на длину запроса.

Подводя черту под этими (трезвыми) размышлениями, могу сказать следующее. Провайдер, не зависимо от того включен ли UnicodeMode или выключен, всегда работает так, чтобы клиент получил текстовые данные в правильном виде. Предпочтительным является режим по-умолчанию (unicode_mode=true). Если у провайдера что-то «не получается» с текстовыми данными, то проблема скорее всего в вашем древнем/неправильном сервере. На текущий момент наиболее правильным является Firebird 2.5. Рекомендую.