Когда-то я мучился с этим то же и состряпал для себя такие тесты.

Все дело в том, что при создании базы данных и( или) таблицы не была указана кодировка и посему Interbase/Firebird принял NONE. Данные Ваши
записаны в коде Win1251, но Java об зтом ничего не знает и считывая символ
переводит его в Unicode, используя кодировку ISO8859 (на память точно не знаю).

Предположим следующее:

Создана база данных wSaga.gdb без указания кодовой страницы;
Создаем в этой базе две простые тестовые таблицы:
TestDS
TestDS1
Таблица TestDS создана с использованием:

/* Table: TESTDS, Owner: SYSDBA */

CREATE TABLE TESTDS
(
F1 VARCHAR(20),
F2 VARCHAR(20) CHARACTER SET WIN1251
)

Таблица TestDS1 создана с использованием:

/* Table: TESTDS1, Owner: SYSDBA */

CREATE TABLE TESTDS1
(
F1 VARCHAR(20),
)

Тест 1. Ввод с использованием утилиты IBConsole
Войдем в режим SQL, где выполним пункты меню:


Database + Disconnect

Теперь повторно выполним соединение с БД, выполнив пункты меню:


Database + Connect As

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

Вводим все, что необходимо и доходим до того, что нас в данный момент интересует, а именн: строки, озаглавленной Character Set c последующим comboBox - список доступных таблиц кодировок.

Выбираем WIN1251 - киррилица и щелкаем на кнопке Connect.

Если все правильно выполнено, то мы приконектились к нашей базе.

Выполним теперь следующий SQL оператор:

INSERT INTO TestDS ( F1 ) VALUES ("Бука")

Кажется, что все Ok. Но не спешим с выводами и пытаемся выдать SQL оператор COMMIT. Появляется сообщение об ошибке.

В конце-концов просто закройте консоль и вновь войдите в нее.

Выполните SQL запрос

SELECT Count(*) FROM TestDS

Убеждаемся, что, несмотря на сообщения об ошибках, IBConsole все-таки запихнула нашу запись, т.к. результат запроса дал 1.

( Кстати, такие же результаты с вариациями будут происходить и, когда смоделировать проделанную работу с использование Delphi или Java JDBC ).

Ну нет ни какой возможности посмотреть эту запись, например, выполните:

SELECT * FROM TestDS

Ни какого толку!!!

Тогда поступим следующим образом:

В режиме SQL, выполним пункты меню:


Database + Disconnect

Выполним соединение с БД, выполнив пункты меню:


Database + Connect As

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

Вводим все как и прежде, НО: выбираем NONE - нет кодировки.

Выполняем SQL запрос

SELECT * FROM TestDS

!!! Появились результаты выборки - одна запись со значением в поле F1 равным нами введенным "Бука".

Что же произошло ?

Вернемся к началу и вспомним, что мы приконектились к базе данных, предварительно указав кодовую страницу WIN1251. Таблица TestDS еще пуста и мы вводим в нее одну запись с русскими буквами для поля F1, которое ( см. выше ) определено БЕЗ указания Character Set.

Как далее "размышляет" InterBase, приняв на обработку наш SQL INSERT:

Смотрит: В какой кодировке эта строка? По значения подученному в процессе коннекта - WIN1251;
По описанию таблицы определяет, что там для поля F1 НЕ указано никакой кодировки;
Раз так, думает InterBase, то ничего не надо предпринимать, а просто взять последовательность поступивших для поля F1 байт и записать их в таблицу. Это конечно не хорошо и, поэтому, возмутимся и выдадим предупреждающее сообщение (хотя и сохраним данные).
Это то как происходил ввод записи. Теперь вспомним, что мы пытались прочитать ее (SELECT * FROM TestDS).

Как теперь действует InterBase:

Смотрит: В какой кодировке эта строка? По значения подученному в процессе коннекта - WIN1251. Поскольку это оператор SELECT, то надо пользователю возвратить данные из поля F1.
По описанию таблицы определяет, что там для поля F1 НЕ указано никакой кодировки;
InterBase в шоке: он не может сообразить, как из непонятного набора бит в батах поля F1 можно по требованию пользователя состряпать данные в русской кодировке WIN1251. Поэтому страшно ругается и дает невразумительные результаты. А представим себе, что кто-то от фонаря нацарапал набор нулей и единиц и говорит Вам: Это есть русское слово и Вы, используя WIN1251 таблицу дайте мне как оно звучит.
Затем мы произвели Disconnect и вновь приконектились, предварительно указав, что хотим данных от Interbase без каких либо перекодировок, т.е. проставили Character Set "NONE".

Выдаем SELECT * FROM TestDS и получаем результаты в нормальном "русском" виде. Это произошло потому, что Interbase увидел, что описание поля F1 не содержит Character Set, и пользователь также указал, что ему наплевать на перекодировку и возвращает поток байт поля F1 "как есть". А далее уже дело приложения (у нас IBConsole) как эти байты интерпретировать.


Теперь несколько изменим условия тестирования, но предварительно удалим запись из TestDS, затем:

Disconnect;
Connect AS с указанием CharacterSet WIN1251;
Выполним следующий SQL оператор:

INSERT INTO TestDS ( F2 ) VALUES ("Бука")

!!! Обратите внимание, что теперь используем поле F2.
Выполняем теперь Commit или Select - все как надо. Это потому, что Interbase точно знает, что пользователь вводит или желает получить данные как WIN1251, а поле F2 именно для таких данных и предназначено.

Вновь изменим условия тестирования

Disconnect;
Connect AS с указанием CharacterSet NONE;
Попробуем выполнить SELECT * FROM TestDS

Все проходит отлично. Поскольку InterBase увидел,что нам, как клиентам требуются данные "как есть" и перекодировки не требуется.

Нетрудно догадаться, что произойдет, если попытаться выполнить сейчас оператор

INSERT INTO TestDS ( F2 ) VALUES ("Бука")

Interbase грязно выругался и наотрез отказался выполнить этот оператор. Опять таки он не желает перекодировать непонятно что в WIN1251.

Конечно, возникает вопрос, а почему бы этому Interbase не плюнуть на все и не взять наш поток байт и, не пытаясь его перекодировать записать как есть?

Ответ вероятно таков: в условиях многопользовательской работы, когда один клиент использует Windows, другой DOS, а третий Linux и каждый из них работает с самими разнообразными редакторами в какой угодно кодировке безопаснее и корректнее все-таки отвергать попытку "засорить" базу данных и, требовать от клиента указывать ЯВНО кодировку в которой он вводит данные или в каком виде он желает их получить.

Тест 2. Java
При работе с Java необходимо учитывать следующие факторы:

Среда исполнения, т.е. Операционнная система (ОС);
Значение Character Set в поле таблицы;
Значение Character Set ЯВНО указанное клиентом Interbase-у; перед процедурой получения конэкта (Connection);
Java использует Unicode при работе со строками.
Предположим, что нам необходимо поле F1 из таблицы TestDS переписать в поле с тем же именем F1 таблицы TestDS1. Напомним, что в таблице TestDS поле F1 объявлено без указания Character Set, а в TestDS1 определено Character Set WIN1251. Кроме того, значение в поле F1 таблицы TestDS пропишем заранее, например, воспользовавшись IBConsole и пусть это будет "Бука".

Для организации соединения (Connection) с базой данных будем использовать Java класс DataSource потому, что именно этот способ позволяет перед коннэктом явно указать кодовую страницу.

Из результатов тестирования IBConsole следует полагать:

Для таблицы TestDS необходимо указать кодовую страницу NONE;
Для таблицы TestDS1 необходимо указать кодовую страницу WIN1251 ( в Java ей соответствует Cp1251);
После установления соединения с базой и получения выборки из таблицы TestDS в конце концов имеем экземпляр класса ResultSet rs. Теперь нам надо выдать один из getXXX методов, чтобы получить данные из rs.

Рассмотрим для начала метод rs.getString("F1"). Давайте запишем:

String f1Str = rs.getString("F1");

В итоге строка f1Str с точки зрения русского будет содержать крокозябры. Это происходит потому, что InterBase не в состоянии определить, в какой кодировке у него в поле f1Str хранятся данные и отсылает их Java-приложению "как есть". Приложение, также понятия не имеет, что там ему передал InterBase и поэтому принимает решение в пользу США и Европейского Союза ( исключая Россию ), т.е. использует кодировку ISO8859-1 для передаваемых в F1 символов. Поскольку все строки внутри Java должны быть представлены в Unicode, то Java преобразует каждый полученный символ (считая его ISO8859-1) в Unicode. А что это значит для строки "Бука" ? Это значит, что символ "Б" нормально (т.е. для части таблицы Unicode, соответствующей кириллице) должен был получить значение 0x0410, символ "у" значение 0x0443 и .т.д. А на самом деле получил совсем другие значения из соответствующей ISO8859-1 части таблицы Unicode.