Oracle изменить кодировку строки
Apache : перекодировка windows-1251-> unicode/utf-8
Проблема такого плана, необходимо средствами сервера заставить перекодировать 'на лету' файлы.
Перекодировка из utf в windows-1251. Удаление спец. символов.
Необходимо сформировать xml файл в кодировке windows-1251. Даные для этого xml поступают из БД в.
Перекодировка строки win-1251 в кодировку utf-8
Помогите пожалуйста! есть проблема перекодировки строки win-1251 в кодировку utf-8. Может есть.
Как создать рабочий XML в UTF-8? У меня исправно создаётся Windows-1251, но с UTF-8 проблема
Доброго дня, форумчане. Подскажите, что делать, чтобы создавался и открывался без ошибок.
Слишком расплывчатая задача.
Исходные данные у вас в каком виде?
Столбец в таблице, файл на диске, бинарный BLOB, а может CLOB ?
Какой объем данных для конвертации? Для строки одни способы годятся, для CLOB - другие.
Кодировка самой базы какая ?
В простейшем случае, если база в windows-1251, то вообще уже готовая функция канает:
Перекодировка строки в Windows-1251
Формирую QR-код через dll которую 1С используют в типовых решениях (БГУ и проч). Загоняю строку в.
Перекодировка из КОИ-8 в Windows 1251
Разработать программу перекодировки текстовых файлов из кодового набора КОИ-8 в кодовый набор.
UTF-16 -> cp-1251(windows-1251)
У меня есть кириллическая строка UTF-16, которая выглядит как Хотелось бы конвертнуть её в.
Перекодировка из OEM-866 в Windows-1251
написан батник, результат каждой команды он выводит в лог так: 1>>%~dp0\log.txt 2>>&1 понятно.
UTF-8 to WINDOWS-1251
Здравствуйте! Надо вот чего. Есть строка в UTF-8. После перекодировки функцией `UTF8ToString`.
из UTF-8 в Windows-1251
Как строку в формате UTF-8 перекодировать в Windows-1251? Добавлено через 16 минут Существуют.
CONVERT converts a character string from one character set to another.
The char argument is the value to be converted. It can be any of the data types CHAR , VARCHAR2 , NCHAR , NVARCHAR2 , CLOB , or NCLOB .
The dest_char_set argument is the name of the character set to which char is converted.
The source_char_set argument is the name of the character set in which char is stored in the database. The default value is the database character set.
The return value for CHAR and VARCHAR2 is VARCHAR2 . For NCHAR and NVARCHAR2 , it is NVARCHAR2 . For CLOB , it is CLOB , and for NCLOB , it is NCLOB .
Both the destination and source character set arguments can be either literals or columns containing the name of the character set.
For complete correspondence in character conversion, it is essential that the destination character set contains a representation of all the characters defined in the source character set. Where a character does not exist in the destination character set, a replacement character appears. Replacement characters can be defined as part of a character set definition.
Oracle discourages the use of the CONVERT function in the current Oracle Database release. The return value of CONVERT has a character data type, so it should be either in the database character set or in the national character set, depending on the data type. Any dest_char_set that is not one of these two character sets is unsupported. The char argument and the source_char_set have the same requirements. Therefore, the only practical use of the function is to correct data that has been stored in a wrong character set.
Appendix C in Oracle Database Globalization Support Guide for the collation derivation rules, which define the collation assigned to the character return value of CONVERT
The following example illustrates character set conversion by converting a Latin-1 string to ASCII. The result is the same as importing the same string from a WE8ISO8859P1 database to a US7ASCII database.
You can query the V$NLS_VALID_VALUES view to get a listing of valid character sets, as follows:
Oracle Database Globalization Support Guide for the list of character sets that Oracle Database supports and Oracle Database Reference for information on the V$NLS_VALID_VALUES view
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Information in this document applies to any platform.
Purpose
The purpose of this note is to provide the exact steps to change the current NLS_CHARACTERSET to AL32UTF8 / UTF8 or an other multibyte characterset.
The majority of SR's logged about "csalter not working" or "characterset change does not work" are simply due the steps in this note NOT been followed.
The note is rather long but this is to check for all known issues and to explain what objects need action so a correct conversion is possible.
Please DO follow the note and do not "skip" sections and use , when provided , the selects to have a clear idea what objects need action.
This note are "the exact steps".
In 10g and 11g you NEED to use Csalter (or the DMU tool).
In 12c you NEED to use the DMU tool.
Do NOT use "Alter database character set" in 10g, 11g or 12c to go to AL32UTF8 or UTF8.
Using "Alter database character set" to go to UTF8 or AL32UTF8 is NOT supported in 10g, 11g or 12c and WILL corrupt at least (!) Data Dictionary objects and most likely also User data.
If "Alter database character set" is used in 10g , 11g or 12c to go to AL32UTF8 or UTF8 the only action possible is back to backup.
From Oracle 12c onwards the DMU will be the only tool available to migrate to Unicode see
This note will only deal with the database (server side) change itself.
In 8i (8.1.7 and lower) you cannot use AL32UTF8 since this is not known, use UTF8 instead.
Note that in order to use an Unicode (AL32UTF8 / UTF8) database you need to make sure your application supports using an Unicode database. This is not something Oracle database support can "check" or "confirm".
Please consult the application documentation or ask the application vendor / support team if your application is certified to work with AL32UTF8 or UTF8 as NLS_CHARACTERSET.
For further implications on clients and application level when going to AL32UTF8 please see AL32UTF8 / UTF8 (Unicode) Database Character Set Implications.
It's strongly recommended to:
- do a complete "testdrive" of the WHOLE change upfront
- read AL32UTF8 / UTF8 (Unicode) Database Character Set Implications first and to make sure your application and clients are checked and ready for the change on database level.
The note can be used to go from any NLS_CHARACTERSET to AL32UTF8 / UTF8. ( which also means it can be used to go from UTF8 to AL32UTF8 (or inverse) ).
The note is written using AL32UTF8, to use this note to go to an other characterset (for example UTF8) simply replace "AL32UTF8" with "UTF8" in the CSSCAN TOCHAR and for 9i and lower in the alter database character set command.
This "flow" can also be used to go from any single byte characterset (like US7ASCII, WE8DEC) to any other Multi byte characterset (ZHS16GBK, ZHT16MSWIN950, ZHT16HKSCS, ZHT16HKSCS31,KO16MSWIN949, JA16SJIS . ), simply substitute AL32UTF8 with the xx16xxxx target characterset. But in that case going to AL32UTF8 would be simply be a far better idea. Choosing a database character set means choosing Unicode.
Scope
Changing the current NLS_CHARACTERSET to AL32UTF8 / UTF8 or an other multibyte characterset.
In this note AL32UTF8 will be used, but it's applicable to UTF8 (like to be used in 8i instead of AL32UTF8) or other multibyte charactersets also.
The current NLS_CHARACTERSET is seen in NLS_DATABASE_PARAMETERS.
The NLS_CHARACTERSET is defining the characterset of the CHAR, VARCHAR2, LONG and CLOB datatypes.
Details
Функции юникода
Поддержка Юникода в 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 :
Символьная функция получает в качестве параметра одно или несколько символьных значений и возвращает символьное и числовое значение. Если символьная функция возвращает символьное значение, оно всегда имеет тип VARCHAR2 (переменная длина) — кроме функций UPPER и LOWER . Эти функции преобразуют заданную строку к верхнему или нижнему регистру соответственно и возвращают значение фиксированной длины типа CHAR , если переданные в аргументах строки имели тип CHAR .
To view full details, sign in with your My Oracle Support account.
To view full details, sign in with your My Oracle Support account.
Параметры Globalization Support (NLS)
Поведение Oracle по умолчанию определяется параметрами Globalization Support (NLS) . Значения параметров, задаваемые при создании базы данных, определяют многие аспекты ее работы — от наборов символов до используемых по умолчанию денежных единиц. В табл. 1 перечислены параметры, которые вы можете изменить в ходе сеанса, с примерами значений и пояснениями. За текущими значениями параметров в вашей системе обращайтесь к представлению NLS_SESSI0N_PARAMETERS .
Таблица 1. Сеансовые параметры NLS
Don't have a My Oracle Support account? Click to get started!
In this Document
Purpose |
Scope |
Details |
1) General remarks on going to AL32UTF8 |
1.a) Prerequisites: |
1.b) When changing an Oracle Applications Database or Peoplesoft database: |
1.c) When to use (full) export / import and when to use Alter Database Character Set / Csalter? |
1.d) When using Expdp/Impdp (DataPump) |
1.e) Using Alter Database Character Set on 9i |
1.f) What about Physical / Logical Standby databases? |
1.G) How to test the steps in this note upfront? |
2) Check the source database for unneeded or problematic objects: |
2.a) Invalid objects. |
2.b) Orphaned Datapump primary tables (10g and up) |
2.c) Unneeded sample schema/users. |
2.d) Make sure your database is in good health. |
3) Check the Source database for "Lossy" (invalid code points in the current source character set). |
3.a) How to "rescue" lossy data? |
3.b) Can I solve "lossy" user/application data in an other way? |
4) Check for "Convertible" and "Truncation" data when going to AL32UTF8 |
5) Dealing with "Truncation" data. |
5a) or shorten the data before export |
5b) or adapt the columns to fit the expansion of the data |
6) Dealing with "Convertible" data. |
6.a) "Convertible" Application Data: |
6.b) "Convertible" data in Data Dictionary objects: |
7) Before using Csalter / Alter Database Character Set check the database for: |
7.a) Partitions using CHAR semantics - ORA-14265: data type or length of a table subpartitioning column may not be changed" or " ORA-14060: data type or length of a table partitioning column may not be changed" during the change to AL32UTF8 |
7.b) Function , Domain or Joined indexes on CHAR semantics columns. |
7.b.1) Functional or domain indexes on columns using CHAR semantics - "ORA-30556: functional index is defined on the column to be modified" or with "ORA-02262: ORA-904 occurs while type-checking column default value expression" during the change to AL32UTF8 |
7.b.2) Join indexes on columns using CHAR semantics - "ORA-54028: cannot change the HIDDEN/VISIBLE property of a virtual column" during the change to AL32UTF8 |
7.c) SYSTIMESTAMP in the DEFAULT value clause for tables using CHAR semantics - " ORA-604 error occurred at recursive SQL level %s , ORA-1866 the datetime class is invalid" during the change to AL32UTF8 . |
7.d) Clusters using CHAR semantics - "ORA-01447: ALTER TABLE does not operate on clustered columns" during the change to AL32UTF8 |
7.e) Unused columns using CHAR semantics - "ORA-00604: error occurred at recursive SQL level 1" together with an "ORA-00904: "SYS_C00002_09031813:50:03$": invalid identifier" during the change to AL32UTF8 |
7.f) Check that you have enough room to run Csalter or to import the "Convertible" data again afterwards. |
7.g) (10g and 11g) Objects in the recyclebin - "ORA-38301 can not perform DDL/DML over objects in Recycle Bin" during the change to AL32UTF8 |
7.h) Check if the compatible parameter is set to your base version |
7.i) for Oracle 11.2.0.3 , 11.2.0.2, 11.2.0.1 , 11.1.0.7 and 11.1.0.6 : check for SQL plan baselines and profiles |
7.j) Leftover Temporary tables using CHAR semantics - " ORA-14450: attempt to access a transactional temp table already in use" during the change to AL32UTF8 |
8) After any "Lossy" is solved, "Truncation" data is planned to be addressed and/or "Convertible" exported / truncated / addressed and point 7) is ok run Csscan again as final check. |
8.a) For 8i/9i the Csscan output needs to be "Changeless" for all CHAR, VARCHAR2, CLOB and LONG data (Data Dictionary and User/Application data) ( = BEFORE going to point 10.a) ). |
8.b) For 10g and 11g the Csscan output needs to be ( = BEFORE going to point 10.b) ) |
9) Summary of steps needed to use Alter Database Character Set / Csalter: |
9.a) For 9i and lower: |
9.b) For 10g and 11g: |
10) Running Csalter ( 10g and 11g) or Alter Database Character Set (8i and 9i) |
10.a) The steps for 8i and 9i ONLY - do NOT use these in 10g or 11g |
10.b) The steps for version 10g and 11g |
10.c) Check the Csalter/alter database output and the alert.log for errors, some Csalter messages do NOT have an ORA- number. |
11) (10g and 11g ) Reload the data pump packages after a change to AL32UTF8 in 10g and up. |
12) Import the exported data back into the database. |
12.a) When using Csalter/Alter database to go to AL32UTF8 and there was "Truncation" data in the csscan done in point 4: |
12.b) When using (Full) export/import to go to a new/other AL32UTF8 database and there was "Truncation" data in the csscan done in point 4: |
12.c) When using Csalter/Alter database to go to AL32UTF8 and there was NO "Truncation" data, only "Convertible" and "Changeless" in the csscan done in point 4: |
12.d) When using (full) export/import to go to a new/other AL32UTF8 database and there was NO "Truncation" data, only "Convertible" and "Changeless" in the csscan done in point 4: |
13) Check your data and final things: |
References |
My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.
До разработки стандарта Юникод существовало множество схем кодировки, которые обладали ограниченными возможностями, а порой и конфликтовали друг с другом. Разработка глобальных приложений по единым правилам была практически невозможна, потому что ни одна кодировка не поддерживала все символы.
Стандарт Юникод решает все эти проблемы. Он разрабатывается и сопровождается Консорциумом Юникода. Содержимое каждой версии определяется Стандартом Юникода и Базой данных символов Юникода, или 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 соответствующая кодовая точка хранится некорректно.
Краткая сводка строковых функций
Как упоминалось ранее, PL/SQL предоставляет в распоряжение программиста широкий набор мощных, высокоуровневых строковых функций для получения информации о строках и модификации их содержимого. Следующий список дает представление об их возможностях и синтаксисе. За полной информацией о конкретных функциях обращайтесь к справочнику Oracle SQL Reference.
- ASCII(символ ) Возвращает числовой код (NUMBER) представления заданного символа в наборе символов базы данных.
- ASCIISTR(строка1) Получает строку в любом наборе символов и преобразует ее в строку ASCII-символов. Все символы, отсутствующие в кодировке ASCII, представляются в форме \XXXX, где XXXX — код символа в Юникоде.
- CHR(код)
Возвращает символ типа VARCHAR2 (длина 1), соответствующий заданному коду. Функция является обратной по отношению к функции ASCII. У нее имеется разновидность, удобная при работе с данными в национальных наборах символов:
Возвращает символ типа NVARCHAR2 из национального набора символов.
- COMPOSE(строка1)
Получает строку символов в формате Юникода и возвращает ее в нормализованном виде. Например, ненормализованное представление 'a\0303' определяет символ ' a ' с тильдой cверху (то есть a). Вызов COMPOSE('a\0303') возвращает значение ' \00E3' — шестнадцатеричный код символа a в Юникоде.
В Oracle9i Release 1 функция COMPOSE могла вызываться только из SQL-команд; в программах PL/SQL она использоваться не могла. Начиная с Oracle9i Release2, функция COMPOSE также может использоваться в выражениях PL/SQL.
- CONCAT(строка1, строка2)
Присоединяет строку2 в конец строки1. Аналогичного результата можно добиться при помощи выражения строка1 || строка2. Оператор || намного удобнее, поэтому функция CONCAT используется относительно редко. - CONVERT(строка1, набор_символов)
Преобразует строку из набора символов базы данных в заданный набор символов. При вызове также можно задать исходный набор символов:
CONVERT(строка1, конечный_набор, исходный_набор)
- DECOMPOSE(строка1)
Получает строку в Юникоде и возвращает строку, в которой все составные символы разложены на элементы. Функция является обратной по отношению к COMPOSE . Например, вызов DECOMPOSE ('a') возвращает строку ' a ~' (см. описание COMPOSE ).
Существует две разновидности этой функции:
- DECOMPOSE(строка1 CANONICAL)
Выполняет каноническую декомпозицию; полученный результат может быть восстановлен вызовом COMPOSE . Используется по умолчанию. - DECOMPOSE(строка1)
Декомпозиция выполняется в так называемом режиме совместимости. Восстановление вызовом COMPOSE может оказаться невозможным.
Функция DECOMPOSE , как и COMPOSE , не может напрямую вызываться в выражениях PL/SQL в Oracle9i Release 1; ее необходимо вызывать из инструкций SQL. Начиная с Oracle9i Release 2, это ограничение было снято.
Существует несколько разновидностей этой функции:
- INSTR(строка1, строка2, начальная_позиция)
Поиск строки2 в строке1 начинается с позиции, заданной последним параметром. По умолчанию поиск начинается с позиции 1, так что вызов INSTR(string1, string2, 1 ) эквивалентен вызову INSTR(string1, string2) . - INSTR(строка1, строка2, отрицательная_начальная_позиция)
Смещение начальной позиции задается не от начала, а от конца строки1. - INSTR(строка1, строка2, начальная_позиция, n )
Находит n-е вхождение строки2, начиная с заданной начальной позиции. - INSTR(строка1, строка2, отрицательная_начальная_позиция, n)
Находит n-е вхождение строки2, начиная с заданной начальной позиции от конца строки1.
Функция INSTR рассматривает строку как последовательность символов. Ее разновидности INSTRB, INSTR2 и INSTR4 рассматривают строку как последовательность байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность INSTRC рассматривает строку как последовательность полных символов Юникода. Например, строка 'a\0303' , которая представляет собой разложенный эквивалент '\00E3', или a , рассматривается как один символ. Напротив, функция INSTR рассматривает 'a\0303 ' как последовательность из двух символов.
- LEAST(строка1, строка2, . )
Получает одну или несколько строк и возвращает строку, которая оказалась бы первой (то есть наименьшей) при сортировке входных строк по возрастанию. Также см. описание функции GREATEST , обратной по отношению к LEAST . - LENGTH(строка1)
Возвращает количество символов в строке. Разновидности LENGTHB, LENGTH2 и LENGTH4 возвращают количество байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность LENGTHC возвращает количество полных символов Юникода, нормализованных по мере возможности (то есть с преобразованием 'a\0303 ' в '\00E3' ).
Функция LENGTH обычно не возвращает нуль. Вспомните, что Oracle рассматривает пустую строку ('') как NULL , поэтому вызов LENGTH ('') фактически эквивалентен попытке получить длину NULL ; ее результат тоже будет равен NULL . Единственное исключение встречается при применении LENGTH к типу CLOB . Тип CLOB может содержать 0 байт и при этом быть отличным от NULL . В этом единственном случае LENGTH возвращает 0.
- LOWER(строка1)
Преобразует все буквы заданной строки в нижний регистр. Функция является обратной по отношению к UPPER . Тип возвращаемого значения соответствует типу входных данных ( CHAR ,VARCHAR2, CLOB ). Также см. NLS_LOWER . - LPAD(строка1, итоговая_длина)
Возвращает значение строки1, дополненное слева пробелами до итоговой_длины . У функции существует следующая разновидность: - LPAD(строка1, итоговая_длина, заполнитель)
Присоединяет достаточное количество полных или частичных вхождений заполнителя, чтобы общая длина строки достигла заданной итоговой_длины . Например, вызов LPAD ( 'Merry Christmas!', 25, 'Ho! ') вернет результат ' Ho! Ho! HMerry Christmas!'.
- ?LTRIM(строка1)
Удаляет пробелы с левого края строки1. Также см. описания функций TRIM (стандарт ISO) и RTRIM . У функции существует следующая разновидность: - LTRIM(строка1, удаляемый_набор)
Удаляет любые символы, входящие в строку удаляемый_набор , от левого края строки1. - NCHR(код)
Возвращает символ типа NVARCHAR2 (длина 1) , соответствующий заданному коду. Функция CHR с условием USING NCHAR_CS реализует ту же функциональность, что и NCHR . - NLS_INITCAP (строка1)
Возвращает версию строки1, которая должна относиться к типу NVARCHAR2 или NCHAR , в которой первая буква каждого слова переводится в верхний регистр, а остальные буквы — в нижний. Функция возвращает значение типа VARCHAR2 . «Словом» считается последовательность символов, отделенная от остальных символов пробелом или символом, не являющимся буквенно-цифровым.
Вы можете задать порядок сортировки, влияющий на определение «первой буквы»:
- NLS_INITCAP(строка1, 'NLS_SORT=правило_сортировки')
В этой форме синтаксиса правило_сортировки представляет собой одно из допустимых названий правил сортировки, перечисленных в руководстве Oracle Database Globalization Support Guide, Appendix A, раздел «Linguistic Sorts».
Следующий пример показывает, чем функция INITCAP отличается от NLS_INITCAP :
В нидерландском языке последовательность символов « ? » рассматривается как один символ. Функция NLS_INITCAP распознает это обстоятельство при задании правила NLS_SORT и правильно преобразует символы слова « ?zer » («железо» по-нидерландски).
- NLS_LOWER(строка1) и NLS_LOWER(строка1, 'NLS_SORT=правило_сортировки ') Возвращает строку1, преобразованную в нижний регистр по правилам заданного языка. О том, как NLS_SORT может повлиять на результат преобразования, рассказано в описании функции NLS_INITCAP .
- NLS_UPPER(строка1) и NLS_UPPER(строка1, 'NLS_SORT=правило_сортировки') Возвращает строку1, преобразованную в верхний регистр по правилам заданного языка. О том, как NLS_SORT может повлиять на результат преобразования, рассказано в описании функции NLS_INITCAP .
- NLSSORT(строка1) и NLSSORT(строка1, 'NLS_SORT=правило_сортировки ') Возвращает строку байтов, которая может использоваться для сортировки строкового значения по правилам заданного языка. Строка возвращается в формате RAW . Например, сравнение двух строк по правилам французского языка выполняется так: IF NLSSORT(x, 'NLS_SORT=XFRENCH') > NLSSORT(y, 'NLS_SORT=XFRENCH') THEN. Если второй параметр не указан, функция использует порядок сортировки по умолчанию, назначенный для сеанса. Полный список правил приведен в руководстве Oracle Database Globalization Support Guide, Appendix A, раздел «Linguistic Sorts».
- REGEXP_COUNT, REGEXP_INSTR, REGEXP_LIKE, REGEXP_REPLACE, REGEXP_SUBSTR За описаниями этих функций, предназначенных для работы с регулярными выражениями, можно изучить эту статью.
- REPLACE(строка1, искомая_строка, замена) Возвращает строку, полученную в результате замены всех вхождений искомой_строки в строке1 строкой замена. Функция REPLACE может использоваться для замены всех вхождений определенной подстроки в одной инструкции.
- REPLACE(строка1, искомая_строка)
Возвращает строку, полученную в результате удаления всех вхождений искомой_строки из строки1. - RPAD(строка1, итоговая_длина)
Возвращает значение строки1, дополненное справа пробелами до итоговой_длины . У функции существует следующая разновидность: - RPAD(строка1, итоговая_длина, заполнитель)
Присоединяет достаточное количество полных или частичных вхождений заполнителя, чтобы общая длина строки достигла заданной итоговой_длины . Вызов RPAD('Merry Christmas!', 25, 'Ho! ') вернет результат 'Merry Christmas! Ho! Ho!'.
Функция RPAD дополняет строку справа, а парная ей функция LPAD — слева.
- RTRIM(строка1)
Удаляет пробелы с правого края строки1. Также см. описания функций TRIM (стандарт ISO) и LTRIM . У функции существует следующая разновидность: - RTRIM(строка1, удаляемый_набор)
Удаляет любые символы, входящие в строку удаляемый_набор , с правого края строки1. - SOUNDEX(строка1)
Возвращает строку с «фонетическим представлением» аргумента.
Пример:
При использовании функции SOUNDEX следует помнить несколько правил:
- Значение SOUNDEX всегда начинается с первой буквы входной строки.
- Возвращаемое значение генерируется только по первым пяти согласным в строке.
- Для вычисления цифровой части SOUNDEX используются только согласные. Все гласные в строке, кроме начальных, игнорируются.
- Функция SOUNDEX игнорирует регистр символов; для букв верхнего и нижнего регистра генерируются одинаковые значения SOUNDEX .
Функция SOUNDEX полезна для запросов, при которых точное написание значения в базе данных неизвестно или не может быть легко определенно.
Алгоритм SOUNDEX ориентирован на английский язык; в других языках он может работать плохо (или не работать вообще).
- SUBSTR(строка1, начальная_позиция, длина)
Возвращает подстроку из строки1, которая начинается с начальной_позиции и имеет заданную длину. Если количество символов до конца строки1 окажется меньше длины, возвращаются все символы от начальной позиции до конца строки. У функции существуют следующие разновидности: - SUBSTR(строка1, начальная_позиция)
Возвращает все символы от начальной_позиции до конца строки1. - SUBSTR(строка1, отрицательная_начальная_позиция, длина)
Начальная позиция подстроки отсчитывается от конца строки1. - SUBSTR(строка1, отрицательная_начальная_позиция)
Возвращает последние ABS( отрицательная_начальная_позиция ) строки.
Функция SUBSTR рассматривает строку как последовательность символов. Ее разновидности SUBSTRB, SUBSTR2 и SUBSTR4 рассматривают строку как последовательность байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность SUBSTRC рассматривает строку как последовательность полных символов Юникода. Например, строка 'a\0303' , которая представляет собой разложенный эквивалент '\00E3' , или a , рассматривается как один символ. Напротив, функция SUBSTR рассматривает 'a\0303' как последовательность из двух символов.
- TO_CHAR(национальные_символьные_данные)
Преобразует данные из национального набора символов в эквивалентное представление в наборе символов базы данных. Также см. TO_NCHAR .
Функция TO_CHAR также может использоваться для преобразования даты/ времени и чисел в удобочитаемую форму.
- TO_MULTI_BYTE(строка1)
Преобразует однобайтовые символы в их многобайтовые эквиваленты. В некоторых многобайтовых кодировках, и прежде всего UTF-8, может существовать несколько вариантов представления одного символа. Скажем, в UTF-8 представление буквы 'G' может содержать от 1 до 4 байт. Для перехода от однобайтового представления к многобайтовому используется функция TO_MULTI_BYTE . Данная функция является обратной по отношению к TO_SINGLE_BYTE . - TO_NCHAR(символы_в_наборе_базы_данных)
Преобразует данные из набора символов базы данных в эквивалентное представление в национальном наборе символов. Также см. TO_CHAR и TRANSLATE. USING.
Функция TO_NCHAR также может использоваться для преобразования даты/времени и чисел в удобочитаемую форму.
- TO_SINGLE_BYTE(строка1)
Преобразует многобайтовые символы в их однобайтовые эквиваленты. Функция является обратной по отношению к TO_MULTI_BYTE . - TRANSLATE(строка1, искомый_набор, набор_замены)
Заменяет в строке1 каждое вхождение символа из искомого_набора соответствующим символом набора_замены . Пример:
Если искомый_набор содержит больше символов, чем набор_замены , «лишние» символы, не имеющие соответствия в наборе_замены , не включаются в результат. Пример:
Буква « d » удалена, потому что она присутствует в искомом_наборе , но не имеет эквивалента в наборе_замены . Функция TRANSLATE заменяет отдельные символы, а функция REPLACE — целые строки.
- TRANSLATE(текст USING CHAR_CS) и TRANSLATE(текст USING NCHAR_CS)
Преобразует символьные данные в набор символов базы данных ( CHAR_CS ) или в национальный набор символов ( NCHAR_CS ). Выходным типом данных будет VARCHAR2 или NVARCHAR2 в зависимости от того, выполняется ли преобразование к набору символов базы данных или национальному набору символов соответственно.
Функция TRANSLATE. USING входит в число функций SQL по стандарту ISO. Начиная с Oracle9i Release 1, можно просто присвоить значение VARCHAR2 переменной типа NVARCHAR2 , и наоборот — система неявно выполнит нужное преобразование. Если же вы хотите выполнить преобразование явно, используйте функции TO_CHAR и TO_NCHAR для преобразования текста в набор символов базы данных и национальный набор символов соответственно. Oracle рекомендует пользоваться указанными функциями вместо TRANSLATE. USING , потому что они поддерживают более широкий набор входных типов данных.
- TRIM(FROM строка1)
Возвращает строку, полученную в результате удаления из строки1 всех начальных и конечных пробелов. У функции существуют следующие разновидности: - TRIM(LEADING FROM . )
Удаление только начальных пробелов. - TRIM(TRAILING FROM . )
Удаление только конечных пробелов. - TRIM(BOTH FROM . )
Удаление как начальных, так и конечных пробелов (используется по умолчанию). - TRIM (. удаляемый_символ FROM строка1)
Удаление вхождений одного удаляемого_символа на выбор программиста.
Функция TRIM была включена в Oracle8i для обеспечения более полной совместимости со стандартом ISO SQL. Она сочетает в себе функциональность LTRIM и RTRIM , но отличается от них тем, что TRIM позволяет задать только один удаляемый символ, тогда как при использовании LTRIM и RTRIM можно задать набор удаляемых символов.
- UNISTR(строка1)
Возвращает строку1, преобразованную в Юникод; таким образом, функция является обратной по отношению к ASCIISTR . Для представления непечатаемых символов во входной строке можно использовать запись \XXXX, где XXXX — кодовый индекс символа в Юникоде. Пример:
Функция предоставляет удобный доступ ко всему набору символов Юникода, в том числе и к тем, которые не могут вводиться непосредственно с клавиатуры.
Читайте также: