> > Дим, если сейчас сервер (2.1) действительно стал возвращать кодовую > > страницу блоба - то оставляйте как есть.
> Дело немного не в этом. Ответь на вопрос - ты при чтении/записи > текстовых блобов чарсет (коннекта) в BPB всегда указываешь? Я туда передаю нули. То есть BPB не заполняю в принципе. Я как-то очень давно курил этот вопрос и решил отказаться от этой заморочки. То бишь я закладываюсь на то, что все блобы имеют кодовую страницу _подключения_. Потому что определить чарсет блобовой колонки, в общем случае, очень напряжно. > Вся проблема пошла оттого, что в 2.1 сервер стал конвертировать *строки* > из *чарсета коннекта* в UNICODE при занесении данных в RDB$SOURCE и > RDB$DESCRIPTION. Т.е. теперь предполагается, что русские буквы в DDL > (например, комментарии в процедуре) будут в чарсете коннекта. И это есть ГУД! > Этим гарантируется, что в поле будет именно UNICODE, а не хрен знает > что, как раньше (там обычно лежал ANSI-текст). Для чего это надо? А для > того, чтобы можно было нормально (т.е. не бинарно) с ними работать, как > и с обычными строками (upper/lower/substring и т.п.) Понятно > Побочный эффект - если RDB$SOURCE/DESCRIPTION блобы читать без указания > чарсета в BPB, то получишь юникодовскую белиберду вместо русского > текста. Именно это визуально наблюдается в IBE и компарере. ISQL же > указывает чарсет коннекта в BPB при чтении системных блобов, так что она > извлекает данные нормально. Не понятно. Если при записи блоба вы его перекодируете из чарсета_подключения в чарсет_колонки, то почему тогда вы его при чтении обратно не перекодируете в чарсет_подключения ... Хотя, наверное, есть какие-то побочные эффекты. Типа несоответствия длины полученной через isc_blob_info и фактических данных. В целом - Дим, как сделаете так и адаптируем :) Коваленко Дмитрий.
