cl8mswin1251 что за кодировка

Cl8mswin1251 что за кодировка

Начиная с версии Oracle 11.1 GUI утилита sqlplusw.exe объявлена как устаревшая (deprecated) и исключена из состава дистрибутива. Теперь приходиться использовать только консольную версию — sqlplus.exe. При её использовании, с русским языком, возникают проблемы. Сообщения самой sqlplus и сообщения выводимые скриптами (это разные вещи) отображаются не корректно (крякозябрами или символами псевдографики). Еще, некоторые стали задавать вопрос, как установить рабочую папку чтобы выполнялись вложенные скрипты. Разберёмся по порядку:

Проблемы некорректных сообщений возникают из-за того что консоль по умолчанию выводит всё в кодировке OEM DOS 866, а скрипты это обычно текстовые файлы в кодировке MS WIN 1251. Кодировка сообщений sqlplus зависит от переменной NLS_LANG, а т.к. базы с данными на русском языке обычно создаются в кодировке CL8MSWIN1251 (не RU8PC866), то и переменные NLS_LANG устанавливаются соответственно как CL8MSWIN1251. Т.е. проблема из-за несовпадения кодировок консоли и программ, которые выводят сообщения на консоль.

1) Чтобы русские сообщения отображались в консоли корректно нужно соблюсти ТРИ условия.

1. В свойствах консоли (правой мышью на заголовке окна cmd) должен быть установлен unicode шрифт, например Lucida Console.

cl8mswin1251 что за кодировка

cl8mswin1251 что за кодировка

2. За кодировку выводимых сообщений отвечает третья часть переменной NLS_LANG и она должна быть CL8MSWIN1251 (пример, AMERICAN_CIS.CL8MSWIN1251).

3. Нужно переключить кодовую страницу консоли на 1251, командой

Если все три условия соблюдены — проблем с русскими буквами не будет.

Примечания:

1. Переменную NLS_LANG можно задавать тремя способами:

а) (глобально) (по умолчанию) В реестре в HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE. Здесь переменная может быть в нескольких местах, особенно если на компьютере несколько ORACLE_HOME. Менять её нужно для того ORACLE_HOME из которого запускается sqlplus. Для 64-битных систем существует еще одна ветка реестра для Oracle — HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE. Если вы меняете переменную, а результат не меняется, хотя все остальные условия соблюдены, значит вы меняете не ту переменную, попробуйте поменять вообще все NLS_LANG, которые найдете или см.п. в).

б) (локально) Для конкретной DOS сессии. Прямо в консоли командой set

C:> SET NLS_LANG=AMERICAN_CIS.CL8MSWIN1251

в) (супер глобально) Задать как переменную окружения в ОС. Делать так я настоятельно НЕ рекомендую. Но, такая установка перекрывает переменную в реестре, поэтому если вы меняете NLS_LANG в реестре, а результат не меняется — проверьте переменные окружения, командой set без параметров.

2. Изменение переменной NLS_LANG на глобальном уровне влияет на все другие программы работающие с Oracle, например EXPIMP. Поэтому следует быть осмотрительным и для безопастности, для запуска sqlplus использовать bat или cmd файл в котором менять NLS_LANG на уровне текущей сессии.

2) Чтобы сообщения sqlplus выводились корректно см. п. 1).

Если сделать всё как описано в п.1) то все сообщения sqlplus будут выводить корректно на русском языке. Если у вас нет проблем с английским то я рекомендую выводит сообщения sqlplus на английском языке. Потому что в англоязычном сегменте сети гораздо больше информации чем в русском и если возникнет ошибка то по английскому сообщению найти решение будет проще и быстрее.

За язык сообщений sqlplus и других консольных утилит Oracle отвечает первая часть переменной NLS_LANG. Чтобы все сообщения было на английском языке — её нужно установить как AMERICAN (например, AMERICAN_CIS.CL8MSWIN1251).

3) Как установить рабочую папку чтобы выполнялись вложенные скрипты.

Для этого нужно запустить sqlplus из рабочей папки. Для примера предположим что в качестве рабочей папки нужно использовать папку c:\EGRP\SCRIPTS и запустить скрипт c:\EGRP\SCRIPTS\UPDATE.sql, который вызывает из себя другие скрипты, некоторые из которых находиться в подпапках c:\EGRP\SCRIPTS.

C:\> cd c:EGRP\SCRIPTS
c:\EGRP\SCRIPTS>c:\app32\admin\product\11.2.0\client_1\bin\sqlplus.exe /nolog
SQL> @update

(на картинке еще отображен момент переключения кодовой страницы)

cl8mswin1251 что за кодировка

Для удобства использования, можно создать bat или cmd файл для запуска sqlplus.

REM echo off
REM Установка рабочей папки (можно убрать)
cd c:\egrp\scripts
SET NLS_LANG=RUSSIAN_CIS.CL8MSWIN1251
chcp 1251
break
REM Два варианта запуска sqlplus
c:\app\admin\product\11.2.0\dbhome_1\BIN\sqlplus.exe /nolog
REM c:\app\admin\product\11.2.0\dbhome_1\BIN\sqlplus.exe /nolog @UPDATE
exit

Примечания:

— echo off — не выводить выполняемые команды на консоль, а только результат их выполнения. Я предпочитаю видеть что происходит поэтому отключил (REM) эту команду.

Источник

Исправить кодировку: кириллица записывается знаками вопроса

Кодировка в консоли, кириллица представлена знаками вопроса
подскажите плиз при таком Console.WriteLine(«русский текст»); коде, на консоль выводятся.

Некоторые шрифты в БД отображаются знаками вопроса
Может быть тему не там открыл. Есть некоторые шрифты, которые не определяются. Например: Ə.

Русский шрифт отображается знаками вопроса
в настройках студии character set установлен в Use Multi-Byte Character Set в ос: панель.

Замена русских букв знаками вопроса
Создаю сайт на DomainDXL (бесплатный Asp-хостинг). Закачал Access-ную базу. Написал простую выборку.

NLS_LANG Значенние: RUSSIAN_RUSSIA.CL8MSWIN1251

А какие поля прописать для таблицы?

если напишите как, то смогу

Кодировка вашей БД (WE8MSWIN1252) не предназначена для работы с кириллицей. Когда вы вставляете в БД кириллические символы то Oracle пытается их переконвертировать (так как NLS_LANG клиента (CL8MSWIN1251) не совпадает с кодировкий сервера) в что-то понятное для кодировки WE8MSWIN1252 и ему это не удаётся.
Выходов мне известно немного.
1 (Нормальный) пересоздать базу данных в подходящей кодировке.
2 (Ненормальный) использовать в таблицах поля не VARCHAR2 а NVARCHAR2, в этих полях данные будут храниться в кодировке AL16UTF16, тогда конвертация пройдёт нормально.
3 (Пожалуй самый плохой) Поменять на клиенте NLS_LANG с CL8MSWIN1251 на WE8MSWIN1252, тогда Oracle не будет проводить конвертацию а будет верить клиенту и хранить так как дали. При таком раскладе отображаться почти всё (или почти всё) долно нормально (теоритически), но в последующем сопровождении возможны проблеммы.

Я бы посоветовал 1 вариант.
Может у кого-то будут ещё идеи.

Источник

Cl8mswin1251 что за кодировка

Однобайтная кодировка в Oracle Database 11g Express Edition

При инсталляции, редакция Oracle Database 11g Express Edition ставит базу данных с набором символов по умолчанию AL32UTF8. Это конечно сильно сокращает максимальный размер и так небольшого лимитируемого табличного пространства в 11 Гб. В данном NLS наборе для кодировки русских символов используется два байта:

Приходится увеличивать вдвое размер символьных столбцов. Это в свою очередь ведёт к увеличению занятого табличного пространства и создаёт сложности в использовании утилит экспорта импорта при перекачке данных.

Если применять набор символов Unicode не планируется, то можно попробовать пересоздать базу данных в необходимой нам однобайтной кодировке. Посмотрим на примере, как это делается. Считаем, что Oracle Database 11g Express Edition у нас проинсталлирована по умолчанию.

Для начала установим переменную ORACLE_HOME и подключимся к экземпляру как sys:

Остановим базу данных и снова её запустим, но уже в смонтированном монопольном режиме и с ограничением по подключению:

Теперь удалим базу данных:

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

Первое, это создадим или скопируем файл инициализационных параметров initXE.ora в каталог c:\oraclexe\app\oracle\product\11.2.0\server\database. Второе, скачаем этот архив и распакуем его в каталог C:\oraclexe\app\oracle\product\11.2.0\server\rdbms\xml, зачем, об этом немного позже.

Все необходимые файлы скопированы, подключаемся к экземпляру и стартуем его с нашим файлом инициализации initXE.ora:

Создаём базу данных следующей командой, указав в ней необходимый нам набор символов (строка character set cl8mswin1251):

База данных в нужной нам кодировке создана. Добавим к ней табличное пространство USERS:

Запускаем на выполнение следующие скрипты:

Перезапускаем базу данных:

Смотрим значения параметров NLS базы данных:

Как видим, созданная вновь база данных имеет однобайтовый набор символов (NLS_CHARACTERSET CL8MSWIN1251). Что нам и надо было получить.

Напоследок хочется сказать о том, зачем надо было распаковывать файлы из архива xsl.rar в каталог C:\oraclexe\app\oracle\product\11.2.0\server\rdbms\xml. Если это не сделать до выполнения скрипта catproc, то потом окажется, что утилита Oracle Data Pump Export (expdp) отказывается работать, выдавая ошибку:

Если вы забыли скопировать файлы архива до выполнения скрипта, то ничего страшного, это можно сделать и позже. Единственное, надо не забыть выполнить после этого процедуру LOD_STYLESHEETS пакета DBMS_METADATA_UTIL:

Источник

Научим SQL*Plus говорить по-русски

cl8mswin1251 что за кодировка

Долго не мог понять, почему люди не любят пользоваться SQL*Plus.

Оказывается: интерфейс убогий и бестолковый.

Словом, не графический – мышкой ткнуть не куда (значит интуитивно не понятный).

. редко встретишь кодера, умеющего мышкой воять SELECT’ы.

Например, некоторые столкнулись со следующей заморочкой.

И как бы всё хорошо.

Но если в SQL-команде вы будете использовать слова набранные кириллицей, то после закрытия редактора, в SQL*Plus запросто сможете увидеть кракозябры вместо русских букв.

Как бы не то, что хотелось. Комфортно работать действительно невозможно.

Начнём с того, что во время установки оракла в реестр прописывается параметр NLS_LANG:

Смотрим на значение этого параметра (от знака равно до конца строки). Значение состоит из двух частей.

Значение первой части, которая до точки, я подробно объяснял, когда рассказывал про использование типа DATE. Вторая часть, стоящая после точки, задаёт кодировку символов, которая используется на клиентском компьютере. В этой кодировке вы вводите команды и в ней же получаете от оракла результат.

Если вы сидите за компьютером, на котором развёрнута оракловая база, то знайте, что клиентский софт у вас уже установлен (параметр прописан в реестре) и при работе с ораклом вы активно используете этот софт. Оракловый клиент одинаково работает и на удалённой машине, и на сервере.

Обращаю внимание на 2 момента:

Если вы работает в обычной российской конторе, то используйте кодировку CL8MSWIN1251.

Почему SQL*Plus пишет кракозябры?

Сразу скажу, что не все версии SQL*Plus пишут кракозябры.

Пишет кракозябры только консольная версия Windows. Исполняемый файл называется SQLPLUS.EXE

Этой версии и положено так себя вести. Поскольку консоль Windows использует кодировку RU866 (она поддерживается для того, чтобы можно было запускать старые dos-программы), то плюс, будучи консольным приложением, должен поддерживать эту кодировку.

Здесь возникает противоречие: оракловый клиент работает с кодировкой, которая задана параметром NLS_LANG, а консольный SQL*Plus в RU866.

Когда в «Блокноте» набраны русские слова в кодировке CL8MSWIN1251, то SQL*Plus будет их выводить на экран кракозябрами в кодировке RU866.

Чтобы заставить SQL*Plus «говорить по-русски» делайте так:

Теперь, когда вам нужен будет SQL*Plus, запускайте его через созданный ярлык.

Похожие статьи:

При написании SQL запросов есть ряд правил, которым нужно просто следовать. Можно вдаваться в поиски, почему надо писать так, а не иначе, но для понимания нужен багаж и некоторый практический опыт, а ведь зачастую SELECT’ы надо писать уже сейчас, да так, чтобы они летали и после не переписывать.

Решил публично ответить одному из подписчиков. Дело в следующем. У меня на сайте есть форма, через которую подписчики могут задавать вопросы, но форма анонимная и, даже если захочу, приватно ответить не смогу.

Источник

Cl8mswin1251 что за кодировка

ЛАСУ ТРИНИТИ, г. Троицк

Несколько «хакерских» способов русификации Oracle

1. Изменение DATABASE CHARSET

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

SQL> select value from V$NLS_VALID_VALUES

2 where parameter=’CHARACTERSET’

3 and (value like ‘RU%’ or value like ‘CL%’) 4

Кроме этих Вам могут встретиться или понадобиться CLKOI8R, BG8MSWIN(болгарская) и другие. Oracle Corp. позаботилась если не обо всех ситуациях, то по крайней мере о многих. Если Вам интересно, что представляет из себя та или иная кодировка, воспользуйтесь примером из пункта 4.

Текущие установки NLS БД можно просмотреть используя view NLS_DATABASE_PARAMETERS. Что представляет из себя это view?

SQL> select text from dba_views where view_name=’NLS_DATABASE_PARAMETERS’;

where name like ‘NLS%’

SQL> select * from props$ where name=’NLS_CHARACTERSET’;

NAME VALUE$ COMMENT$

NLS_CHARACTERSET WE8ISO8859P1 Character set

SQL> update props$ set VALUE$=’CL8MSWIN1251′ where name=’NLS_CHARACTERSET’;

SQL> select * from props$ where name like ‘NLS_CHARACTERSET’;

NAME VALUE$ COMMENT$

NLS_CHARACTERSET CL8MSWIN1251 Character set

И после этого остается только поменять переменную среды NLS_LANG на сервере и клиентах и спокойно наслаждаться видом неизвращенных «Я» и «Ч» как больших так и маленьких.

Если Вы делаете экспорт в системе с кодировкой WE8ISO8859P1, а импорт на системе с русской кодировкой (или наоборот) Вы с удивлением (по крайней мере первый раз) обнаруживаете вместо русских букв сплошные вопросы (как на экране, так и вашей голове). Использование параметра CHARSET применимо для импорта данных из версий ранее 7 (Oracle 5, 6). Экспортный файл версии 7 содержит в себе информацию о кодировке данных, что и приводит к образованию вопросов. Как же этого избежать?

Таблица 1. Идентификаторы CHARSET.

КодировкаCS_ID(hex)CS_ID(dec)NLS RTL 3.1 WindowsNLS RTL 3.2 Windowsмодуль из libnlsrtl.a *
US7ASCII0x011lx20001.dlx20001.nlblic001.o
WE8ISO8859P10x1F31x2001F.dlx2001F.nlblic031.o
CL8ISO8859P50x2335lx20023.dlx20023.nlblic035.o
RU8PC8660x98152lx20098.dlx20098.nlblic152.o
RU8BESTA0x99153lx20099.dlx20099.nlblic153.o
RU8PC8550x9B155lx2009B.dlx2009B.nlblic155.o
CL8MACCYRILLIC0x9E158lx2009E.dlx2009E.nlblic158.o
CL8MACCYRILLICS0x9F159lx2009F.dlx2009F.nlblic159.o
CL8MSWIN12510xAB171lx200AB.dlx200AB.nlblic171.o
CL8EBCDIC10250xB9185lx200B9.dlx200B9.nlblic185.o
CL8EBCDIC1025X0xBA186lx200BA.dlx200BA.nlb
CL8BS20000xEB235lx200EB.dlx200EB.nlblic235.o

*- для Oracle 7.1.4 for SCO Unix (в других версиях может отличаться)

3. Изменение кодировки приложений разработанных с помощью Developer/2000

Принцип изменения кодировки Forms(.FMB), Menu (.MMB), Reports (.RDF) одинаков :

1) преобразовать Binary-to-Text (NLS_LANG=WE8ISO8859P1)

2) исправить CHARSET с помощью редактора

Поскольку данные выбираются из БД и «перекодируются на лету» необходимо изменить только кодировку константных строк, которые в текстовых вариантах модулей описаны как

В действительности нужно заменить «cs = 31» на «cs = 171» (для кодировки отличной от CL8MSWIN1251, см. Табл 1).

3) изменить NLS_LANG=CL8MSWIN1251

4) преобразовать Text-to-Binary

4. Принцип перекодировки «на лету»

Для перекодировок Oracle NLS использует четыре таблицы:

unsigned char t_UPPER[256];

unsigned char t_LOWER[256];

unsigned int t_TOUNI[256];

unsigned char t_TOLOC[1000];

/* для Windows размер этого массива 2000, но учитывая, что русские символы UNI находятся в первой тысяче этой таблицы, и что в некоторых версиях, например в моем Oracle 7.1.4 for SCO размер его действительно равен 1000, я рекомендую описывать структуру NLS указанным способом */

char Translate(char c, struct NLS * FROM, struct NLS * TO)

/* Show Oracle NLS table */

unsigned char t_UPPER[256];

unsigned char t_LOWER[256];

unsigned int t_TOUNI[256];

unsigned char t_TOLOC[2000];

int lbl; /* NLS label 0x5A5A */

int fl; /* File length */

int nl; /* Coding name length */

int cc; /* Current code oxAB for CL8MSWIN1251 */

int nl2; /* Coding name length ( nl2 == nl ) */

int Translate(int c, struct NLS * FROM, struct NLS * TO )

fread( bn, BT.nl, 1, bf );

fread( sn, ST.nl, 1, sf );

printf(«Error: Oracle Base Coding for %s and %s don’t equal»,bn, sn );

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *