|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
ORA 12.2 x64 В SQL Developer никаких проблем, корректно пишет и читает. А вот SQL Assistant пишет в БД всё правильно (Developer'ом видно), а при чтении показывает всякую гадость, если символы юникодные. Например, символ цента (буква "c" с вертикальной чертой, на форуме неправильно показывается как "¢") Assistant читает как "Вў". Пробовал клиентов x64 и x32 (соответственно и версии Assistant), результат одинаковый. Куда копать? Это какие-то настройки Оракла или проблемы Assistant? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 17:30 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяКуда копать? Это какие-то настройки Оракла или проблемы Assistant? Oracle Globalization Support Guide. Не всё, что "видно правильно" на самом деле правильно. Надо аккуратно проверять байты на соответствие кодировкам на всех этапах, включая хранение. Функция dump() тебе поможет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 17:36 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный Вася, Возможно проблемы с фонтом, системными таблицами перекодировки Начни с SQL.ru FAQ: CodePage, NLS_LANG: решение проблем с отображением сообщений на русском языке ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 17:42 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Смотрю по таблице символов для знака евро код 20AC. А в developer запрос Код: plsql 1.
возвращает Typ=96 Len=3 CharacterSet=AL32UTF8: e2,82,ac Как это понять? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 18:13 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяСмотрю по таблице символов для знака евро код 20AC. А в developer запрос Код: plsql 1.
возвращает Typ=96 Len=3 CharacterSet=AL32UTF8: e2,82,ac Как это понять? Вроде правильно, три байта: Unicode Character 'EURO SIGN' (U+20AC) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 18:30 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяКак это понять? Это значит, что тебе надо открывать для себя удивительный мир кодировок, включая UTF-8. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 18:31 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Значит, в БД записывается правильно (из таблиц dump для евро те же коды показывает). Тогда возвращаемся к первому посту: сохранение происходит верно, а вот чтение кривое. Как такое может быть? Настройки ведь не меняю между ними. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 19:15 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный Вася, Скорее всего это не чтение кривое, это разные фонты ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 21:14 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Vadim LejninСкорее всего это не чтение кривое, это разные фонты Одна и та же программа, одно и то же окошко в ней. Какие разные фонты? С какого перепуга? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 22:00 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяОдна и та же программа, одно и то же окошко в ней.И один и тот же символ. Может ты глазами поочередно мигаешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 22:11 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяORA 12.2 x64 В SQL Developer никаких проблем, корректно пишет и читает. А вот SQL Assistant пишет в БД всё правильно (Developer'ом видно), а при чтении показывает всякую гадость, если символы юникодные. Например, символ цента (буква "c" с вертикальной чертой, на форуме неправильно показывается как "¢") Assistant читает как "Вў". Ошибка конфигурации клиента: NLS_LANG на клиенте установлен в .al32utf8, сам клиент (окошко) работает в локали (шрифтом) win1251. Корректные варианты: - объявить NLS_LANG .cl8mswin1251 - получите знак вопроса, поскольку 1251 не содержит "¢" - объявить NLS_LANG .cl8mswin1252 - отработает "¢", но русские буквы (if any) станут вопросами - переключить SQL Assistant на работу в UTF8. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2019, 00:22 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
andrey_anonymousNLS_LANG на клиенте установлен в .al32utf8 Запрос Код: plsql 1.
дает RUSSIAN, причем одинаково и в SQL Developer, и в SQL Assistant ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2019, 23:05 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
И в реестре стоит NLS_LANG=RUSSIAN_RUSSIA.CL8MSWIN1251 для HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB12Home1 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2019, 23:19 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяЗапрос не имеет отношения к проблеме. Правильный ВасяИ в реестре стоит NLS_LANG=RUSSIAN_RUSSIA.CL8MSWIN1251 для HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB12Home1 "Все врут" (с) Судя по Правильный Васязапрос Код: plsql 1.
возвращает Typ=96 Len=3 CharacterSet=AL32UTF8: e2,82,ac серверный characterset суть al32utf8. Если бы для SQL Assistant действовала CL8MSWIN1251, то Вы получили бы "?", а не "Вў", которая свидетельствует о попытке отобразить кодовую последовательность e2,82,ac в кодировке 1251. ...конкретно SQL Developer: - джавный, oracle client не использует и потому на на NLS_LANG не реагирует - внутренне-юникодный, ему такие проблемы не свойственны. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.03.2019, 00:22 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
andrey_anonymous"Все врут" (с) Удивительно, но запрос Код: plsql 1.
возвращает RUSSIAN_RUSSIA.AL32UTF8 Тогда не понимаю, почему значение из реестра не берётся? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.03.2019, 16:26 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Правильный ВасяУдивительно, но запрос Попытка узнать кодировку клиента запросом к серверу - идея не очень удачная, сервер о ней просто не знает, за ненадобностью. Взялось-не взялось... Под Win есть много мест, откуда oracle клиент выдернет кодировку. Первый приоритет - переменная окружения NLS_LANG, которая может быть задана: - локально в процессе (обычно при запуске приложения пакетным файлом). - унаследована из пользовательских переменных - унаследована из общесистемных переменных Далее - штук пять ключей в реестре в приоритете "от частного к общему", я их давно и прочно забыл за ненадобностью. Вроде как в platform guide было описание реестра, попробуйте там посмотреть... только переменные окружения в любом случае приоритетнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.03.2019, 17:12 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.03.2019, 17:24 |
|
Ломается кодировка при чтении данных из таблиц
|
|||
---|---|---|---|
#18+
Спасибо. andrey_anonymousПервый приоритет - переменная окружения NLS_LANG Почему-то для SQL Assistant не помогает, ничего не поменялось. Устанавливал поочередно и в батнике, и в общесистемных. andrey_anonymous- локально в процессе (обычно при запуске приложения пакетным файлом). Такой метод пытался использовать и для еще одной программы, но тоже не помогало. А вот через общесистемные для нее помогло. Теперь я еще больше в непонятках. В какой бубен еще стучать, вокруг какой пальмы прыгать... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.03.2019, 20:52 |
|
|
start [/forum/topic.php?fid=52&fpage=83&tid=1882726]: |
0ms |
get settings: |
12ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 291ms |
total: | 439ms |
0 / 0 |