Запрос к Firebird возвращает нечитаемые символы вместо русских #763098

Доброго всем дня. При обращении к базе Firebird получаю ответ в формате UTF8 и русские буквы отражаются в форме нечитабельно. Попытка использовать при подключении CHARSET=UTF8 результата не даёт. Аналогично, пытаясь в запросе наложить условие с русскими символами, получаю «ничего». Если в условие вставлять возвращаемый запросом нечитабельный текст, то отбор срабатывает корректно. Вопрос: как получить содержимое полей в нормальной кодировке?

код полностью:

пример возвращаемого: ID_STAFF    LAST_NAME    FIRST_NAME    MIDDLE_NAME    TABEL_ID    PORTRET    DATE_BEGIN     41 801    РќРѕСЃРєРѕРІ    РљРёСЂРёР»Р»    РђР»РµРєСЃРµРµРІРёС‡    46    COMSafeArray    01.01.2008 0:00:00

Измени строку подключения.

В ней укажи кодировку.

надо применить CHARSET=WIN1251 для рекорд сета

Этого достаточно: СоединениеADO = Новый COMОбъект("ADODB.Connection"); Убери рекордсет.

Не обнаружил для Recordset свойства CHARSET Приведите, пожалуйста, пример.

Поясните, как без рекордсета (или прочих аналогичных объектов) получить данные, выполнив необходимый запрос?

Из IBExperta или подобной приблуды в какой кодировке видны русские символы?

"CHARSET=WIN1251"; Это, собственно, и есть строка подключения и в ней указана кодировка

Из IBExperta русские символы? В настройках подключения указана кодировка UTF8.

Из IBExperta русские символы видны. В настройках подключения указана кодировка UTF8.

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

что-то типа того (но детально нужно разбиратся): это стандартная засада когда параметры базы устанавливаются по дефолту каждому новому обьекту... а шарсет конекта - работает только на момент конекта (авторизации) я в свое время с мускулем колупасля с этим...

обнаружил в описании нужных мне полей, что Charset:NONE

это значит дефолтные из базы, если и в базе пусто - то с сервера

Что теперь с ними, болезными, делать? Править саму базу - не вариант. Стороннее решение. Они нас обвиняют во всех смертных грехах.

заставить их править базу ))

безрезультатно. Причем результат одинаковый, какую кодировку ни указывай (проверял на UNICODE_FSS, CP943C, WIN1251) на кодировке OCTETS выходит ошибка: Произошла исключительная ситуация (Microsoft OLE DB Provider for ODBC Drivers): [ODBC Firebird Driver]bad parameters on attach or create database CHARACTER SET OCTETS is not defined на DOS860 и ASCII: Произошла исключительная ситуация (Microsoft OLE DB Provider for ODBC Drivers): [ODBC Firebird Driver][Firebird]arithmetic exception, numeric overflow, or string truncation Cannot transliterate character between character sets Но всё это уже после того как я добавил новое поле в таблицу с кодировкой UTF8 и скопировал в него поле LAST_NAME. Так вот внешний вид содержимого нового поля меняется в зависимости от кодировки! А нужных полей - нет!

судя по РќРѕСЃРєРѕРІ - это утф

которую читают как анси

может драйвер на понимает утф. как было у старых версий мускула?

Новое поле, которое я создал с кодировкой UTF8 и скопировал в него информацию из "неразборчивого", читается драйвером прекрасно. Вопрос в том, как прочитать данные из поля, для которого разработчик указал кодировку NONE?

Тоже поставь NONE. Разработчик на дельфи писал?

Поставил NONE. Не помогает. Результат такой же как и при WIN1251, UTF8, UNICODE_FSS: поле с кодировкой NONE нечитабельно "РќРѕСЃРєРѕРІ", поле с кодировкой UTF8 выводится корректно "Носков". На чем писал разработчик не знаю (СКУД PERCo-S-20 ). Как определить и что от этого зависит? Существуют ли другие способы обратиться к базе Firebird?

А если сконвертировать базу в UTF с помощью этого? Функции ESF Database Migration Toolkit: » Интерфейс пошагового мастера, который позволит проделать все операции за 4 шага » Поддержка множества известных баз данных, включая MySQL, Oracle, PostgreSQL и другие <b>» Возможность конвертации между базами данных » Поддержка Юникода и автоматическая конвертация между различными кодировками</b> » Очень быстрая скорость обработки данных » И многие другие возможности

вариант не подходит RecordSet.ActiveConnection.CHARSET="WIN1251" {Форма.Форма.Форма}: Ошибка при установке значения атрибута контекста (CHARSET)         RecordSet.ActiveConnection.CHARSET="WIN1251"; по причине: Нет поименованных аргументов Кроме того "а шарсет конекта - работает только на момент конекта (авторизации) я в свое время с мускулем колупасля с этим..." не верно в данном случае (возможно, верно для MySQL). При смене кодировки в строке подключения на "CP943C" в поле с кодировкой UTF8 получаем "„N„Ђ„ѓ„{„Ђ„r" вместо привычного для WIN1251, UTF8 и UNICODE_FSS "Носков". Т.е. кодировка в строке подключения оказывает влияние на кодировку используемую в Recordset.

вариант не подходит, т.к. база "живая" и конвертация идет вразрез с понятием "поддержка" от поставщика СКУД, равно как и обращение напрямую к базе. )) Да и если говорить про конвертацию, то, как я писал в , достаточно скопировать нужные поля в новые поля с кодировкой UTF8. При желании можно удалить старые поля с кодировкой NONE и создать из заново с нужной кодировкой. Только неизвестно как будет с такой базой работать ПО поставщика и наверняка первое же "Исправить и реиндексировать БД" в ПО поставщика всё вернёт "на свои места".

Как то так:

+ пардон

работает, но результат тот же "РќРѕСЃРєРѕРІ" для поля в кодировке NONE "Носков" для поля в кодировке UTF8

+ в строке подключения указывал     "CHARSET=UTF8";

есть запасной вариант конвертить РќРѕСЃРєРѕРІ уже в 1с )))

какие есть "элегантные" способы для этого?

лучше задай вопрос тут

Это решается строкой(настройка) соединения. У самого была такая же проблема. Играйся с кодировкой.

+1 Причем врукопашную с помощью:

Дружок писал ODBC manager, я им пользуюсь. Они там на всю голову ужаленные.