Здравствуйте,

такая проблема, никак не получается внести русский текст в Оракл 8.

в JSP пишу:


в Оракле:

а подробнее?

при занесении данных в базе отображаются вопросы. 
менял необходимые поля с VARCHAR2 на NVARCHAR2 - Оракл ругается ошибкой 
ERROR at line 1:
ORA-12704: character set mismatch

как именно ты данные пишешь в БД? Какие параметры у коннектора ты используешь?

ИМХО. везде юзай cp121

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

пишу так

1. Раз в базе кодировка ISO-8859-5, то юникод тебе только в NVARCHAR2 светит.

2. Определи где ошибка: накидай маленькое приложение которое будет соединяться с БД и писать туда текс в поля VARCHAR2 на NVARCHAR2. Если запишется нормально надо разбираться с JSP, что там не так, иначе смотреть параметры соединения с базой.

На клиенте (т.е. где приложение, общающееся с базой) - какой NLS_LANG в окружении стоит? Какая версия базы? Если вы делаете те же самые запросы из sqlplus - что происходит?

хмм, где посмотреть NLS_LANG клиента? (допустим это SQL Worksheet) БД - Oracle 8. 
делаю так, в поле с типом NVARCHAR2 вношу данные:



выдает:


если поле типа VARCHAR2, то заносятся вопросы.

На винде - в реестре. HKEY_LOCAL_MACHINE --> Software --> Oracle.

хм, NLS_LANG = N/A

Ну и поставьте там что-нить типа "AMERICAN_AMERICA.CL8MSWIN1251", главное что бы он понял, что русскими буквами кормят, а не какими-нибудь там 

откуда дровишки?   , т.е. откуда name, role, если постом получаешь, то они должны быть в ISO8859, по идее должны ложиться нормально

чем смотришь, уверен что в базе вопросы, а может только на клиенте?

прописал в реестре
 
AMERICAN_AMERICA.CL8MSWIN1251

те же вопросы.

Боюсь, что всё может оказаться ещё хитрее. Во-первых ваш thin JDBC драйвер может не поддерживать русские кодировки. Т.е. будь у вас в базе 1251 и на клиенте 1251 - то он бы ещё может и гнал бы буквы напрямую без конверсии а так - кто его знает. Это касается именно thin-драйвера, который ходит в базу напрямую и не требует установки клиента. Скачайте с oracle.com свежую версию, там у них к JDBC пакет для интернационализации приложен.

Но для чистоты эксперимента попробуйте неск. вещей: 
 - выставить NLS_LANG как переменную окружения процесса, хотя лучше забивать в параметры самому соединению thin может вообще не ориентироваться на системные настройки: мало ли что там у юзера, загрузившего апплет, понастроено.
 - использовать не Ср1251, а UTF8 кодировку
 - убедитесь, что для сессии выставлена правильная кодировка: select * from nls_session_parameters (этот селект должен быть сделан из проблемной сессии)
 - отказаться от thin JDBC в пользу просто JDBC, который будет лазать в базу через её родной OCI. На сервере-то это даже и лучше. Но это путь для слабых духом. 


PS
Попробую поколбасить сегодня ночью thin JDBC от десятки, только не факт, что удастся воспроизвести проблему, у меня там в базе NLS_CHARACTERSET=UTF8 забит, да и вообще она десятка экспресс без поддержки российской локализации - когда они говорят "Европа", то, видимо подразумевают "Западная Европа".
Да, вот ещё страничка, на которой много полезного про Oracle JDBC-драйвера http://www.oracle.com/technology/tech/java...c_faq.htm#34_03

Это сообщение отредактировал(а) 3x3 - 21.9.2006, 13:08

Вобщем вот так у меня заработало в тестовом сервлете, и вставляет русские буквы (проверял в стороннем приложении в эту базу лазающем - буквы в таблице русские) и вынимает:



У вас должно и нормальное соединение зажить:


У меня jdbc:oracle:oci не живёт из-за небольшого насилия над базой по части юникода в varchar2 - ломается на длине русских строк. Похоже в штатном oci-клиенте до сих пор присутствует непонимание того, что буквы бывают длиннее одного байта. В общем было бы интересно узнать - заживут ли у вас оба драйвера.


Для теста использована таблица простейшей структуры:


По ходу отмечена проблемка в связи с тем, что rollback не откатывает транзакцию, но, думаю, это режим у JDBC-драйвера по умолчанию такой интересный, надо разбираться.



Это сообщение отредактировал(а) 3x3 - 22.9.2006, 03:56

А в БД какая кодировка настроена?

UTF-8.
У меня сейчас европейский eXpress Edition стоит, русского NLS там нет вообще. Т.е. русских чарсетов нет, русской сортировки нет (не проверял, кстати), русских сообщений нет, русских дат нет. И UTF-8 я ему насильно прописал, только что-б буквы русские попробовать.

Без перекодировки (т.е. пришло в UTF8 и сохраняется в UTF8) - хоть русские буквы засовываются. Хотя varchar2 при этом считает длину не по количеству символов, а по количеству байтов, т.е. макс.допустимое количество букв в строке будет ниже указанного при создании таблицы ровно в два раза. Что бы в длине строк не зависеть от кодировки, с 9й версии можно задавать поля в символах:
    create table t 
      (  x varchar2( 20 CHAR ),
       ...
    )




Вам собственно нужно провести 2х3 экспериментов: используя oci и thin драйвера с кодировками как у Базы, UTF-8 и какую-нить 8-битную какую ваша Java понимает, 1251 например. При этом, на всякий случай, выставляйте соответствующий NLS_LANG и в окружении процесса.


Это сообщение отредактировал(а) 3x3 - 28.9.2006, 16:58

АААААААА!!!!!!!!
Кажись заработало! Спасибо огромное!!!!!!!

Ну так поделитесь чего и как заработало в вашей конкретной конфигурации. На будущее може ещё кому пригодится.

Пример 3х3 заработал.

ОК. По всей видимости из-за вот этого:
prop.setProperty("NLS_LANG", "AMERICAN_AMERICA.UTF8");

Тогда как резюме:

ИМХО можно сделать вывод, что thin-драйвер не полагается на настройки на клиенте - ведь он может и из апплетки работать на клиенте, который или настроен неправильно или вообще не знает про существование Oracle. Т.е. он полагается на дефолтные настройки базы, но ничего про ISO-8859-5, видимо, не знает - т.е. JVM не имеет установленных правил трансляции этой кодировки в юникод. 

Задав параметры соединения явно, вы указали базе во что она должна транслировать буквы перед отправкой их на клиента. Если это так, то вместо UTF8 должна бы и CL8MSWIN1251 работать, если она установлена на сервере БД и поддержана клиентской джавой.