Как узнать character set oracle

Обновлено: 25.01.2025

Главная /
Статьи /
Oracle /
Однобайтная кодировка в Oracle Database 11g Express Edition

Однобайтная кодировка в 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:

I знать , как набор символов базы данных ( NLS_CHARACTERSET в select * from v$nls_parameters; ) и набор символов клиента (настройка клиентской среды NLS_LANG ).

Однако я не могу узнать, как или если я могу определить для установленного сеанса , что Oracle считает, что текущий набор символов клиента.

Возможно ли это вообще?

Примечание: SELECT * FROM NLS_SESSION_PARAMETERS; not включает набор символов (на 10g2).

Чтобы полностью понять, чего я хотел бы сделать:

NLS_LANG устанавливается в клиентской среде на произвольное значение (например, GERMAN_GERMANY.WE8MSWIN1252 )
Приложение базы данных [*] запускает и устанавливает соединение /сеанс с базой данных Oracle.
Приложение базы данных [*] хочет «спросить» Oracle (а не его ОС), что предполагает набор символов клиента Oracle.

[*]: Если приложение db является sqlplus, пример будет выглядеть следующим образом:

Примечание Джека в его ответе поднимает два важных момента:

С Oracle, кто выполняет перевод символов. Это код клиентской библиотеки или выполняется на стороне сервера?
Как представляется, клиенту, client нужно будет разоблачить этот параметр - то, что клиентский lib /tool предполагает этот параметр. Есть ли какие-либо из клиентских библиотек /инструментов Oracle (sqlplus, OCI /OCCI, Pro * C, . ), которые могут быть запрошены для того, что он считает этим параметром?

2 ответа

Я немного сомневаюсь, что это именно то, что вы ищете, но

показывает клиентскую переменную среды nls_lang на клиенте.

Я не думаю, что будет SQL-запрос, который вы можете запустить, чтобы дать «текущий» параметр, потому что AFAIK сервер не знает, какой перевод сделан на стороне клиента, поэтому любая команда для отображения текущей настройки будет иметь быть родным для клиента - я использовал SQL Developer для указанной выше команды, но я предполагаю, что она будет работать одинаково в SQL * Plus

только клиент знает свой набор символов - он недоступен "в база данных "

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

клиент делает свой желаемый перевод знака знака [sic] в базу данных через NLS_LANG settting.

Если вы были на 11.1+, у вас может быть радость с v $ session_connect_info, потому что:

Эта информация выводится OCI на сервер при входе в систему.

Но я обнаружил, что все равно будет зависеть от того, как вы подключаетесь, например, из Тонкого драйвера JDBC вы не используете OCI, и поэтому информация не нажата

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

Стандарт Юникод решает все эти проблемы. Он разрабатывается и сопровождается Консорциумом Юникода. Содержимое каждой версии определяется Стандартом Юникода и Базой данных символов Юникода, или USD (Unicode Character Database).

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

Oracle11g Release 2 поддерживает Юникод версии 5.0. Этот стандарт, впервые опубликованный в 2006 году, обеспечивает кодирование более одного миллиона символов. Этого достаточно для поддержки всех современных символов, а также многих древних или малораспространенных алфавитов. Oracle Database 12c включает поддержку Юникода 6.1 (стандарт опубликован в январе 2012 г.) и вводит несколько новых лингвистических порядков сопоставления, соответствующих правилам UCA (Unicode Conation Algorithm).
Наборы символов Юникода в Oracle11g включают кодировки UTF-8 и UTF-16 . В UTF-8 для представления символа используется 1, 2 или 3 байта в зависимости от символа. В UTF-16 символ всегда представляется двумя байтами. В обеих схемах поддерживаются дополнительные символы, использующие 4-байтовое представление независимо от выбранного набора символов Юникода.
Наборы символов Юникода в Oracle Database 11g и 12c включают кодировки UTF-8 и UTF-16 . В UTF-8 символы представляются 1, 2 или 3 байтами в зависимости от символа. В UTF-16 все символы представляются 2 байтами. Дополнительные символы поддерживаются обеими кодировками и представляются 4 байтами на символ независимо от выбранной кодировки.

Каждая база данных Oracle имеет два набора символов. Первичный набор символов используется для большинства функций приложений, а отдельный набор символов NLS — для типов данных и функций, специфических для NLS . Для определения используемых наборов символов используется следующий запрос:

В данном случае параметр NLS_CHARACTERSET (первичный набор символов базы данных) имеет значение AL32UTF8 . В этот 32-разрядный набор символов Юникода UTF-8 входит большинство самых распространенных символов в мире. Параметр NLS_NCHAR_ CHARACTERSET , используемый прежде всего для столбцов NCHAR и NVARCHAR2 , представляет собой 16-разрядный набор символов UTF-16 .

Структура имен, присваиваемых наборам символов в Oracle , содержит полезную информацию. Например, US7ASCII поддерживает символы английского языка для США. Набор символов AL32UTF8 поддерживает любые языки. Вторая часть строки определяет количество битов на символ. В US7ASCII символ представляется 7 битами, а AL32UTF8 использует до 32 бит на символ. Оставшаяся часть строки содержит «официальное» название набора символов. Структура имени представлена на рис. 1.

Рис. 1. Структура имени набора символов в Oracle

За дополнительной информацией о Юникоде обращайтесь на сайт Стандарта Юникод по адресу.

Типы данных и национальные наборы символов

Типы данных Globalization Support nclob , nchar и nvarchar2 используют набор символов, определяемый параметром nls_nchar_characterset , — вместо набора символов по умолчанию, устанавливаемого для базы данных в параметре nls_characterset . Эти типы данных поддерживают только многобайтовые символы Юникода, поэтому даже при работе с базой данных, в которой по умолчанию вместо Юникода используется другая кодировка, они будут хранить символы в национальном наборе символов. А так как национальный набор символов поддерживает только кодировки UTF-8 и UTF- 16 , NCLOB , NCHAR и NVARCHAR2 гарантированно будут хранить данные в многобайтовом Юникоде.

Прежде это создавало проблемы при сравнении столбцов nclob/nchar/nvarchar2 со столбцами clob/char/varchar2 . Во всех версиях, поддерживаемых в настоящее время, Oracle выполняет автоматическое преобразование, благодаря которому становится возможным корректное сравнение.

Кодировка символов

Выбор набора символов во время создания базы данных определяет тип кодировки символов. Каждому символу ставится в соответствие код, уникальный для данного символа (кодовая точка). Это значение является частью таблицы отображения символов Юникода, содержимое которой находится под контролем Консорциума Юникода.

Кодовые точки состоят из префикса U+ (или обратной косой черты \ ), за которым следует шестнадцатеричный код символа с диапазоном допустимых значений от U+0000 до U+10FFFF16 . Комбинированные символы (например, А ) могут разбиваться на компоненты (A с умляутом), а затем снова восстанавливаться в своем исходном состоянии. Скажем, декомпозиция А состоит из кодовых точек U+0041 (A) и U+0308 (умляут). В следующем разделе будут рассмотрены некоторые функции Oracle для работы с кодовыми точками.

Кодовой единицей ( code unit ) называется размер в байтах типа данных, используемого для хранения символов. Размер кодовой единицы зависит от используемого набора символов. В некоторых обстоятельствах кодовая точка слишком велика для одной кодовой единицы, и для ее представления требуется несколько кодовых единиц.

Конечно, пользователи воспринимают символы, а не кодовые точки или кодовые единицы. «Слово» \0053\0074\0065\0076\0065\006E вряд ли будет понятно среднему пользователю, который распознает символы на своем родном языке. Не забывайте, что глиф (изображение символа, непосредственно отображаемое на экране) является всего лишь представлением кодового пункта. Даже если на вашем компьютере не установлены необходимые шрифты или он по другим причинам не может вывести символы на экран, это вовсе не означает, что в Oracle соответствующая кодовая точка хранится некорректно.

Параметры Globalization Support (NLS)

Поведение Oracle по умолчанию определяется параметрами Globalization Support (NLS) . Значения параметров, задаваемые при создании базы данных, определяют многие аспекты ее работы — от наборов символов до используемых по умолчанию денежных единиц. В табл. 1 перечислены параметры, которые вы можете изменить в ходе сеанса, с примерами значений и пояснениями. За текущими значениями параметров в вашей системе обращайтесь к представлению NLS_SESSI0N_PARAMETERS .

Таблица 1. Сеансовые параметры NLS

Функции юникода

Поддержка Юникода в PL/SQL начинается с простейших строковых функций. Впрочем, в табл. 2 видны небольшие отличия этих функций от их хорошо известных аналогов.

К именам функций INSTR , LENGTH и SUBSTR добавляется суффикс B, C, 2 или 4; он означает, что функция работает с байтами, символами, кодовыми единицами или кодовыми точками соответственно.

Функции INSTR , LENGTH и SUBSTR используют семантику длины, связанную с типом данных столбца или переменной. Эти базовые функции и версии с суффиксом C часто возвращают одинаковые значения — до тех пор, пока вы не начнете работать со значениями NCHAR или NVARCHAR . Поскольку NLS_NCHAR_ CHARACTERSET и NLS_CHARACTERSET могут различаться, результат вызова INSTR , LENGTH и SUBSTR может отличаться (в зависимости от типа данных) от результата их символьных аналогов.

Таблица 2. Функции Юникода

Рассмотрим эти функции подробнее.

ASCIISTR

ASCIISTR пытается преобразовать полученную строку в ASCII -символы. Если строка содержит символы, отсутствующие в наборе ASCII , они представляются в формате \xxxx . Как будет показано ниже при описании функции DECOMPOSE , такое форматирование иногда оказывается очень удобным.

COMPOSE

Некоторые символы могут иметь несколько вариантов представления кодовых пунктов. Это создает проблемы при сравнении двух значений. Символ А может быть представлен как одним кодовым пунктом U+00C4 , так и двумя кодовыми пунктами U+0041 (буква A) и U+0308. При сравнении PL/SQL считает, что эти два варианта представления не равны.

Однако после использования функции COMPOSE эти две версии равны:

На этот раз сравнение дает другой результат:

DECOMPOSE

Как нетрудно догадаться, функция DECOMPOSE является обратной по отношению к COMPOSE : она разбивает составные символы на отдельные кодовые точки или элементы:

INSTR/INSTRB/INSTRC/INSTR2/INSTR4

Все функции INSTR возвращают позицию подстроки внутри строки и различаются лишь по способу определения позиции. Для демонстрации мы воспользуемся таблицей publication из схемы g11n .

Позиция символа У отличается только для INSTRB . Одна из полезных особенностей INSTR2 и INSTR4 заключается в том, что они могут использоваться для поиска кодовых точек, не представляющих полные символы. Возвращаясь к примеру с символом А, умляут можно включить как подстроку для выполнения поиска.

LENGTH/LENGTHB/LENGTHC/LENGTH2/LENGTH4

Функции LENGTH возвращают длину строки в разных единицах:

LENGTH — возвращает длину строки в символах;

LENGTHB — возвращает длину строки в байтах;

LENGTHC — возвращает длину строки в символах Юникода;

LENGTH2 — возвращает количество кодовых единиц в строке;

LENGTH4 — возвращает количество кодовых точек в строке.

Если строка состоит из композиционных символов, функция LENGTH эквивалентна LENGTHC .

В данном примере только функция LENGTHB дает другой результат. Как и ожидалось, LENGTH и LENGTHC вернули одинаковые результаты. Впрочем, при работе с декомпозиционными символами ситуация меняется. Пример:

Функции возвращают следующие значения длины:

Функция LENGTH возвращает количество символов, но считает A и умляут разными символами. LENGTHC возвращает длину в символах Юникода и видит только один символ.

SUBSTR/SUBSTRB/SUBSTRC/SUBSTR2/SUBSTR4

Разные версии SUBSTR определяются по тому же принципу, что и их аналоги у функций INSTR с LENGTH . SUBSTR возвращает часть строки заданной длины начиная с заданной позиции. Функции этого семейства работают следующим образом:

SUBSTR — определяет позицию и длину по символу;

SUBSTRB — определяет позицию и длину в байтах;

SUBSTRC — определяет позицию и длину в символах Юникода;

SUBSTR2 — использует кодовые единицы;

SUBSTR4 — использует кодовые точки.

Использование этих функций продемонстрировано в следующем примере:

Обратите внимание на отличие SUBSTRB от других функций в результатах выполнения сценария:

UNISTR

Функция UNISTR преобразует строку в Юникод. Эта функция использовалась в ряде предыдущих примеров для вывода символов строки, подвергнутой декомпозиции. В разделе «Кодировка символов» в качестве примера была приведена строка, состоящая из кодовых пунктов. Чтобы привести ее к понятному виду, можно воспользоваться функцией UNISTR :

Рассматриваемые вопросы

Дополнительные сведения см. в документе Oracle Database Globalization Support Guide.

Что такое кодировка?

При обработке символов в компьютерной системе используются числовые коды символов, а не их графическое представление. Схема кодирования символов (encoded character set) задает соответствие между символами, которые могут приниматься и выводиться компьютером или терминалом, и их кодовым представлением. База данных Oracle в настоящее время поддерживает около 30 схем кодирования символов и при этом значительно большее количество языков и территорий (около 100). Это возможно, потому что Unicode - универсальная кодировка, содержащая большинство основных символов, используемых при письме (scripts) в современном мире.

База данных Oracle поддерживает различные схемы кодирования символов:

однобайтовую;
многобайтную переменной ширины;
всемирную.

Однобайтовые кодировки

Примеры однобайтовых кодировок

American Standard Code for Information Interchange (Американский стандартный код обмена информацией - ASCII) 7-bit American (US7ASCII)
ASCII 7-bit Yugoslavian (YUG7ASCII)
DEC VTTOO 7-bit French (F7DEC)

Примечание: ASCII-кодировки поддерживаются только на платформах, основанных на использовании ASCII. Кодировки EBCDIC используются только на платформах, основанных на использовании EBCDIC.

Многобайтовые кодировки

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

Примеры многобайтовых кодировок переменной ширины

Shift-JIS 16-bit Japanese (JA16S Л S)
MS Windows Code Page 950 with Hong Kong Supplementary Character Set HKSCS-2001
(ZHT16HKSCS)
Unicode 4.0 UTF-8 Universal character set (AL32UTF8)

Кодировки Unicode

Unicode - это всемирный стандарт кодирования символов, который позволяет хранить информацию на различных языках в одной схеме кодирования. Unicode предоставляет уникальный код для каждого символа независимо от платформы, программы или языка.
Стандарт Unicode был одобрен многими производителями программного и аппаратного обеспечения. В настоящее время Unicode поддерживается многими операционными системами и браузерами. Стандарты XML, Java, JavaScript, LDAP и WML требуют использования Unicode. Кроме того, стандарт Unicode согласован с стандартом 1SO/1EC 10646.

Кодировка AL32UTF8

Один символ в этой кодировке Unicode может быть предоставлен 1, 2, 3 или 4 байтами. Символы европейских национальных алфавитов поддерживаются с использованием 1 или 2 байтов; Символы азиатских национальных алфавитов - 3 байтами, а дополнительные символы - 4 байтами.

Кодировка AL16UTF16

AL16UTF16 - кодировка Unicode, использующая 16-битовые кодовые последовательности.

В этой системе кодирования один символ может быть представлен 2 или 4 байтами. Символы европейских алфавитов (а также ASCII) и большинства азиатских алфавитов представлены 2 байтами. Дополнительные символы отображаются 4 байтами. AL16UTF16 - основная кодировка Unicode для Microsoft Windows 2000 и Windows ХР.

Дополнительные символы

В первоначальной версии Unicode использовался 2-байтовый формат кодирования. Такое использование 16 бит для каждого кодируемого элемента позволяет представить до 65536 символов. Однако требуется поддерживать значительно большое количество символов. Например, только сообщество говорящих на китайском использует более 55000 символов.
В таких языках, как китайский, японский и корейский еще не закодированы десятки тысяч идеограмм. И несмотря на то, что многие из этих символов используются редко, они все еще представлены в документах, которые должны сохраняться в электронном виде.

Для удовлетворения этого требования в стандарте Unicode определяются дополнительные символы (supplementary characters). Применяя два 16-битовых кодовых указателя (их называют также заменяющими парами (surrogate pairs)) для представления одного символа, можно дополнительно определить до 1 048 576 символов.

Первая группа дополнительных символов (4944 символа) была добавлена в стандарт Unicode 3.1, выпущенный в марте 2001 года. Вместе с уже существовавшими в Unicode 3.0 49194 символами общее число символов, закодированных в Unicode 3.1, составляет сейчас 94140. Это вносит большую сложность в стандарт Unicode. Однако это значительно проще, чем сопровождать большое количество отдельных кодировок. База данных Oracle 10g поддерживает стандарт Unicode 4.0.

Примечание: кодировки UTF-16 и UTF-8 (с дефисом) относятся к кодировкам стандарта Unicode; UTF8, AL32UTF8 и AL16UTF16 (без дефиса) относятся к кодировкам Oracle, основанным на стандарте Unicode.

Примечание: дополнительные сведения о поддержке Oracle стандарта Unicode см. в документе Oracle Database Globalization Support Guide lOg Release 2 (10.2).

Как используются кодировки?

NLS_LANG задает схему кодирования символов для терминала клиента. Разные клиенты могут использовать различные кодировки. Если кодировки клиента и сервера отличаются, то при передаче данных между ними происходит автоматическая перекодировка.

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

Когда кодировки базы данных и клиента совпадают, Oracle считает, что информация принимается и передается в той же схеме кодирования и не выполняет никаких проверок и преобразований.

Преобразование из одной кодировки в другую может потребоваться в среде клиент-сервер, когда клиентское приложение размещается на платформе, отличной от серверной, и не использует такую же схему кодирования. Символьные данные, передаваемые между клиентом и сервером, должны быть преобразованы из одной схемы кодирования в другую. Символьное преобразование происходит автоматически и прозрачно с помощью Oracle Net.

Такие проблемы следует избегать

Недостоверные данные вносятся в базу данных, когда на клиенте неверно установлена переменная среды NLS_LANG. Значение NLS_LANG должно отражать схему кодирования поступающих на сервер данных.

Если переменная среды NLS_LANG установлена правильно, тогда база данных может автоматически преобразовывать данные, поступающие из клиентской операционной системы.
Если переменная среды NLS LANG установлена неправильно, тогда база данных неверно преобразует поступающие данные.

Например, предположим кодировка базы данных AL32UTF8, на клиенте установлена русская версия операционной системы Windows (кодовая страница: CL8MSWIN1251) и на клиенте же в переменной среды NLS_LANG указана кодировка AL32UTF8. Данные поступают в БД в кодировке CLE8MSWIN1251 и не преобразуются в AL32UTF8, поскольку заданная в NLS_LANG установка соответствует кодировке базы данных.
Поэтому база данных Oracle полагает, что преобразования не нужны и неверные данные вносятся в базу данных.

Пример еще одной проблемы

Выбор кодировки

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

Для правильного выбора кодировки базы данных оцените ваши текущие и будущие бизнес-требования, а также технические требования (например, в соответствие с стандартами XML и Java требуется использовать Unicode). В общем случае Oracle рекомендует использовать Unicode для всех новых баз данных, поскольку это наиболее гибкая кодировка, которая также позволит избежать преобразований в будущем.

Для указания кодировки используется команда CREATE DATABASE. В ней в предложении CHARACTER SET объявляется кодировка базы данных и в предложении NATIONAL CHARACTER SET - национальная кодировка. Если NATIONAL CHARACTER SET не указывается, тогда по умолчанию задается национальная кодировка AL16UTF16.

После создания базы данных может потребоваться изменить кодировку БД. Это может быть вызвано появлением непредусмотренных заранее требований, например, необходимостью поддержки новых источников данных (ХА, хранилище данных и т.д.). Часто такое изменение может привести к значительным временным затратам и оказаться дорогостоящим процессом. В большинстве случаев понадобится выполнить полный экспорт/импорт, чтобы соответствующим образом преобразовать данные из старой кодировки в новую.

Кодировки базы данных и национальные кодировки

Поскольку кодировка базы данных используется для идентификации и хранения исходного кода SQL и PL/SQL, она должна в зависимости от платформы включать в себя 7-битную кодировку ASCII или EBCDIC. Поэтому многобайтная кодировка фиксированной ширины не может использоваться в качестве кодировки базы данных, а может использоваться только в качестве национальной кодировки.

Национальная кодировка - это альтернативная кодировка, позволяющая хранить символьные данные в кодировке Unicode, если в качестве кодировки базы данных не определена Unicode. Для хранения типов данных SQL NCHAR, NVARCHAR2 и NCLOB используется только кодировка Unicode. Можно выбрать одну из двух таких кодировок:
UTF8 илиAL16UTF16.

Читайте также: