Oracle, utf-8, NVARCHAR2 и много путаницы

у меня есть следующая таблица "перевод" в базе данных oracle 10g:

ID  VARCHAR2(100 BYTE)
LANGUAGE    CHAR(2 BYTE)
COUNTRY CHAR(2 BYTE)
TRANSLATION NVARCHAR2(2000 CHAR)
TRACK_TIMESTAMP DATE
TRACK_USER  VARCHAR2(2000 BYTE)

когда я пытаюсь сделать это:

update translation set translation = 'œ' where id = 'MY_ID' And language = 'fr';

тогда я запускаю это:

select * from translation where id = 'MY_ID' and language = 'fr';

и столбец перевода показывает:S вместо œ и я понятия не имею, почему.

из-за устаревших проблем я не могу преобразовать всю базу данных для использования UTF-8, есть ли другие варианты?

в настоящее время Национальный набор символов AL16UTF16. Обычный символ набор WE8ISO8859P1.

в настоящее время я использую java 1.6

выше приведен упрощенный пример. Вот как выглядит запрос в моем фактическом приложении:

UPDATE TRANSLATION SET TRANSLATION=? WHERE TRANSLATION.COUNTRY=? and TRANSLATION.ID=? and TRANSLATION.LANGUAGE=? 1=1,800 - 2,500 œufs par heure 2=CA 3=3_XT_FE_ECS18 4=fr

проблема здесь вместо добавления œufs добавляет ¿ufs

1 ответов


поскольку вы используете переменные привязки, а не жестко закодированные литералы, вы должны иметь возможность передавать строки Unicode в инструкцию UPDATE.

Если вы использовали прямой JDBC для записи в базу данных, есть пример в руководстве разработчика JDBC по запись данных в столбец NVARCHAR2. Если вы используете 1.5 JVM, необходимо использовать OraclePreparedStatement.вызов setFormOfUse для каждого столбца NVARCHAR2. В 1.6 JVM жизнь становится проще, потому что JDBC 4.0 добавлены типы NCHAR и NVARCHAR2. Если вы используете 1.5 JVM, получение платформы ORM, такой как Spring, для использования расширений Oracle для JDBC может быть нетривиальным предприятием. Я недостаточно знаком с весной, чтобы знать, какие шаги необходимы для этого.

потенциально вы можете изменить строку подключения, чтобы указать defaultNChar=true. Это заставит водителя обрабатывать все столбцы символов, используя национальный набор символов. Этого может быть достаточно, чтобы устраните проблему, не заставляя Spring использовать расширения OraclePreparedStatement.