Oracle, UTF-8, NVARCHAR2 y mucha confusión

Question

tengo la siguiente tabla "traducción" en una base de datos 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) 

Cuando trato de hacer esto:

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

Luego ejecutar esto:

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

y la columna de la traducción muestra: S en lugar de œ y tengo ni idea por qué

Debido a problemas heredados, no puedo convertir toda la base de datos para usar UTF-8, ¿hay alguna otra opción?

Actualmente el juego de caracteres nacional es AL16UTF16. El conjunto de caracteres ordinarios es WE8ISO8859P1.

Actualmente estoy usando Java 1.6

Lo anterior es un ejemplo simplificado. Esto es lo que la consulta se parece en mi aplicación real:

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 

El problema aquí es en lugar de añadir œufs añade ¿ufs

Answer 1

dado que está utilizando variables se unen en lugar de literales no modificables, usted debe estar capaz de pasar cadenas Unicode a tu instrucción UPDATE.

Si estaba utilizando JDBC directamente para escribir en la base de datos, hay un ejemplo en la Guía del desarrollador JDBC en writing data to a NVARCHAR2 column. Si está utilizando una JVM 1.5, es necesario utilizar la llamada OraclePreparedStatement.setFormOfUse para cada columna NVARCHAR2. En una JVM 1.6, la vida se vuelve más fácil porque JDBC 4.0 agregó tipos NCHAR y NVARCHAR2. Si está utilizando una JVM 1.5, obtener una estructura ORM como Spring para usar las extensiones de Oracle para JDBC puede no ser una tarea trivial. No estoy lo suficientemente familiarizado con Spring para saber qué pasos serían necesarios para que eso suceda.

Potencialmente, es posible que pueda modificar la cadena de conexión para especificar defaultNChar = true. Eso obligará al controlador a tratar todas las columnas de caracteres utilizando el juego de caracteres nacional. Eso puede ser suficiente para resolver su problema sin que Spring utilice las extensiones OraclePreparedStatement.