Добрый день, уважаемые!

Бьюсь уже битый день с проблемой кодировки, ничего не помогает....
Может быть, Вы сможете помочь.

Есть база данных Oracle 11gR2. Там таблица, с CLOB.

Выполняется запрос к базе, по извлечению этих данных:




К примеру, сообщение выглядит в базе так: Если Наташино здоровье позволяет, хотелось бы чаще видеть ее на моих уроках.
Но на выходе, в System.out.println(line); получаю то же сообщение, с пробелами в тех же местах, но в таком виде:
???? ???????? ???????? ?????????, ???????? ?? ???? ?????? ?? ?? ???? ??????.


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

Charset.defaultCharset() = UTF-8.
Кодировка в базе - UTF-8.

just_vladimir,

взял отсюда:
http://www.javaportal.ru/java/articles/javaandunicode.html

Преобразование между строками и потоком байт

just_vladimir,

1), 2) Хорошо, как предлагаете решить эту проблему Вы?
3) Осталось от старого кода, даже если использовать другие, типа "UTF-8" или "Cp1251", все-равно ничего.

Blazkowicz,

дело в том, что в дальнейшем мне нужен именно InputStream, для записи в NoSQL базу данных. (метод PutLob требует значение в виде Потока). Стандартные методы я реализовал, но по сравнению с BinaryStream они работаю много медленнее. А хотелось бы не терять производительность.

Insane_1990,
плюс кодировка базы и java - совпадает, везде UTF-8

Blazkowicz,

по поводу кодировки я писал в самом первом сообщении =)
Charset.defaultCharset() = UTF-8.
Кодировка в базе - UTF-8.

Blazkowicz То есть у вас есть InputStream, его надо использовать в методе pubLob, то к чему тогда все эти вопросы с выводом\перекодировкой?

Вопросы потому, что в дальнейшем я хочу посмотреть записанные данные из NoSQL хранилища. и когда я прошу его по ключу показать значение, то вводит он полную лабуду, а конкретно знаки вопросов=)

Не CLOb и BLOB парсятся и копируются немного по другому, с другими типами все ок. Даже с BLOB нет проблем. Проблемы именно с CLOB.

По поводу текста перед перекодировки - я уже писал, опять таки в первом сообщении. В базе он выглядит так:
Если Наташино здоровье позволяет, хотелось бы чаще видеть ее на моих уроках.

Дальше сразу идет поток байт, поэтому по всей видимости баг где то тут....

Blazkowicz,

Смотрите, уже на моменте
InputStream simpleValueStream = getkeyResultSet.getBinaryStream(2);

при дебаге все очень странно выглядит. Сообщение, которое я приводил ниже, в simpleValueStream хранится вот так:
[63,63,63,63,32,63,63,63,63,63,63,63,63,32,...]

И так в основном все остальные...в основном встречается число 63...в HEX : 3F 3F 3 F3 F20 3F и т.д..Это все с тем сообщением. К сожалению туда не могу сейчас ввести данные, сейчас на локальной введу, и скажу как поведет себя локальная база.

Blazkowicz,

думаете проблема в базе? Это странно, потому что кодировка одинаковая...

Blazkowicz,

и кстати, если делать не BinaryStream, а просто getString, то все окей...

Blazkowicz,

а может быть проблема в типе подключения ? Имеется ввиду драйвер подключения - thin или oci? у меня стоит thin. пробовал oci - ругается на несовместимость платформ

just_vladimir,

при использовании getCharacterStream возвращается следующее:
Reader r = getkeyResultSet.getCharacterStream(2);

[Е,с,л,и, ,н,а,т,а,ш,и,н,о, ,з,д,о,р,о,в,ь,е, ,п,о,з,в,о,л,я,е,т,,, ,х,о,т,е,л,о,с,ь, ,б,ы, ,ч,а,щ,е, ,в,и,д,е,т,ь, ,е,е, ,н,а, ,м,о,и,х, ,у,р,о,к,а,х,.]

Blazkowicz,




NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET AL32UTF8
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET UTF8
NLS_RDBMS_VERSION 10.2.0.5.0