Кракозябры при выводе текста из БД Oracle с кодировкой win1251 с помощью PHP
Есть БД Oracle с кодировкой CL8MSWIN1251. При выводе данных из базы с помощью PHP получаю кракозябры. Соответственно, необходимо сменить кодировку на UTF8. Собственно, сам код:
"; // отрисовка шапки таблицы for ($i = 1; $i-1 < oci_num_fields($res); $i++) < echo ""; echo oci_field_name($res,$i); echo " "; > // отрисовка и заполнение самой таблицы while ($row = oci_fetch_row($res)) < echo ""; for ($i = 0; $i < $fields=count($row); $i++) < echo "".$row[$i]." "; > echo " "; > echo ""; oci_close($dbconnect) ?> Пробовал несколько вариантов:
$dbconnect = oci_connect ($dbusername, $dbpass,$dbhost, 'UTF8'); select convert(d01_f3, \'UTF8\', \'CL8MSWIN1251\'); В последнем варианте сменить кодировку получилось, но так нужно на каждое поле отдельно прописывать. При этом не могу понять, как конвертировать шапку и заголовки — они так и остаются кракозябрами.
не помогает - словно этого условия и нет в коде. Как правильно задать необходимую кодировку для всей таблицы, включая шапку и заголовки?!
Al32utf8 что за кодировка
Есть база, созданная давно с поддержкой однобайтовой CL8MSWIN1251. Возникла потребность заюзать всю мошь XMLDB и напихать в нее документов в UTF-8. Экспериментирую с XMLType:
insert into XMLDBTEST values(XMLType(BFILENAME('XML_DIR', 'utf8.xml'), NLS_CHARSET_ID('AL32UTF8'));Дальше по-всякому экспериментруя с XMLType.getBlobVal увидел, что русские символы отображаются нормально, а например всякие äå преобразовались в однобайтовый «a», т.е. имеем утерю данных.
Тщательно погуглив пришел к выводу, что XMLType таки является зависимым от NLS_CHARACTERSET, чем и объясняется утеря.
Обходные маневры пока нашел такие:
1) Хранить XML как BLOB. Это плохо по причине снижения производительности и неудобного способа работы с XML. Кроме того, мне нужна XSD-валидация, обеспечиваемая СУБД.
2) Создать вторую базу с поддержкой AL32UTF8. Это еще хуже
А вопросы такие:
1) Не упустил ли я чего или недопонял?
2) Что будет, если сделать alter database на AL32UTF8? Как после смены кодировки базы данных поведут себя клиентские приложения (доступ в основном через ODAC)?
Re: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | Softwarer | http://softwarer.ru |
| Дата: | 11.12.13 06:39 | |
| Оценка: |
Здравствуйте, baranovda, Вы писали:
Клиентам в целом пофиг, для них в любом случае идёт конвертация в клиентскую кодировку. Могут возникнуть некоторые проблемы на сервере из-за изменившегося размера varchar строк, скажем, данные перестанут влезать в отведённое им место.
Re: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | wildwind | |
| Дата: | 11.12.13 06:52 | |
| Оценка: | 4 (1) | |
Здравствуйте, baranovda, Вы писали:
B>2) Создать вторую базу с поддержкой AL32UTF8. Это еще хуже 🙂
Рано или поздно придется мигрировать. Как правило, чем раньше, тем проще.
B>А вопросы такие:
B>1) Не упустил ли я чего или недопонял?
Для начала, укажи версию и планируете ли апгрейд. В десятке, эта «вся мощь XMLDB» местами бывает довольно глючной. В 11 и 12 плотно не щупал, но говорят, получше.
Дальше, обработка XML кушает ресурсы (CPU в основном). Запас по железу есть? И вообще, подумайте, точно ли вы хотите заюзать для этого сервер БД с дорогими (как правило) ресурсами, а не дешевые апп. сервера.
B>2) Что будет, если сделать alter database на AL32UTF8? Как после смены кодировки базы данных поведут себя клиентские приложения (доступ в основном через ODAC)?
Миграция на другой charset — процесс сложный и многоступенчатый , ему посвящен специальный раздел в Globalisation Support Guide.
Re[2]: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | baranovda |
| Дата: | 11.12.13 20:34 |
| Оценка: |
Здравствуйте, wildwind, Вы писали:
B>>1) Не упустил ли я чего или недопонял?
W>Для начала, укажи версию и планируете ли апгрейд. В десятке, эта «вся мощь XMLDB» местами бывает довольно глючной. В 11 и 12 плотно не щупал, но говорят, получше.
10g2. Уже напоролся. Например при помощи стандартных пакетов (DMBS_XSLPROCESSOR) просто невозможно выполнить XSL-трансформацию в указанной в xsl:output кодировке. Она просто игнорируется, а выходной файл всегда создается в кодировке БД (в моем случае однобайтовой) какой способ не используй, хоть XMLType.transform, хоть DMBS_XSLPROCESSOR c выводом в DOM.
W>Дальше, обработка XML кушает ресурсы (CPU в основном). Запас по железу есть? И вообще, подумайте, точно ли вы хотите заюзать для этого сервер БД с дорогими (как правило) ресурсами, а не дешевые апп. сервера.
Не, там нагрузка на обработку небольшая, в основном валидация, сохранение документов, реже однократная их трансформация из одного формата в несколько других, очень редко — консолидирование документов и совсем редко — пакетная выгрузка в OLAP (за два ночных часа успевает).
Аппсервер присобачить невозможно, это ERP-двузвенка.
B>>2) Что будет, если сделать alter database на AL32UTF8? Как после смены кодировки базы данных поведут себя клиентские приложения (доступ в основном через ODAC)?
W>Миграция на другой charset — процесс сложный и многоступенчатый , ему посвящен специальный раздел в Globalisation Support Guide.
спасибо. Шашку отложил. Самая очевидная потенциальная проблема это varchar2(x) и varchar2(char x).
Re[3]: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | wildwind |
| Дата: | 12.12.13 06:06 |
| Оценка: |
Здравствуйте, baranovda, Вы писали:
B>Аппсервер присобачить невозможно, это ERP-двузвенка.
Строго говоря, это не непреодолимое препятствие. Есть веб-сервисы, есть Java, HTTP, и другие способы взаимодействия. Можно организовать выполнение некоторых операций другим сервисом. Если очень постараться, даже транзакционно. 🙂
Если нагрузка будет действительно небольшая и есть аппаратные ресурсы, создание отдельной БД то же вполне себе вариант.
W>>Миграция на другой charset — процесс сложный и многоступенчатый , ему посвящен специальный раздел в Globalisation Support Guide.
B>спасибо. Шашку отложил.
Во-во. Поэтому еще раз напомню: чем раньше — тем проще.
Re[3]: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | hrensgory |
| Дата: | 12.12.13 07:34 |
| Оценка: |
On 12.12.2013 00:34, baranovda wrote:
> 10g2. Уже напоролся. Например при помощи стандартных пакетов
> (DMBS_XSLPROCESSOR) просто невозможно выполнить XSL-трансформацию в
> указанной в xsl:output кодировке. Она просто игнорируется, а выходной
> файл всегда создается в кодировке БД (в моем случае однобайтовой) какой
> способ не используй, хоть XMLType.transform, хоть DMBS_XSLPROCESSOR c
> выводом в DOM.
Напишите хранимку на яве, там с xml/xslt и кодировками всё ок.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Oracle, XML в UTF-8 в базе с поддержкой однобайтовой кодировки
| От: | baranovda |
| Дата: | 12.12.13 11:04 |
| Оценка: |
Здравствуйте, hrensgory, Вы писали:
H>Напишите хранимку на яве, там с xml/xslt и кодировками всё ок.
Al32utf8 что за кодировка
При инсталляции, редакция Oracle Database 11g Express Edition ставит базу данных с набором символов по умолчанию AL32UTF8. Это конечно сильно сокращает максимальный размер и так небольшого лимитируемого табличного пространства в 11 Гб. В данном NLS наборе для кодировки русских символов используется два байта:
SQL> SELECT DUMP('Я', 1017) FROM dual; DUMP('Я',1017) ----------------------------------------- Typ=96 Len=2 CharacterSet=AL32UTF8: d0,af
Приходится увеличивать вдвое размер символьных столбцов. Это в свою очередь ведёт к увеличению занятого табличного пространства и создаёт сложности в использовании утилит экспорта импорта при перекачке данных.
Если применять набор символов Unicode не планируется, то можно попробовать пересоздать базу данных в необходимой нам однобайтной кодировке. Посмотрим на примере, как это делается. Считаем, что Oracle Database 11g Express Edition у нас проинсталлирована по умолчанию.
Для начала установим переменную ORACLE_HOME и подключимся к экземпляру как sys:
C:\oraclexe\app\oracle>SET ORACLE_HOME=c:\oraclexe\app\oracle\product\11.2.0\server C:\oraclexe\app\oracle>c:\oraclexe\app\oracle\product\11.2.0\server\bin\sqlplus /nolog SQL*Plus: Release 11.2.0.2.0 Production on ?э ?рЁ 26 22:03:46 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. SQL> connect sys as sysdba Enter password: Connected.
Остановим базу данных и снова её запустим, но уже в смонтированном монопольном режиме и с ограничением по подключению:
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup restrict mount exclusive; ORACLE instance started. Total System Global Area 535662592 bytes Fixed Size 1384760 bytes Variable Size 226496200 bytes Database Buffers 301989888 bytes Redo Buffers 5791744 bytes Database mounted.
Теперь удалим базу данных:
SQL> drop database; Database dropped. Disconnected from Oracle Database 11g Express Edition Release 11.2.0.2.0 – Production
Старая база данных у нас удалена, можно приступать к созданию новой. Но прежде чем это сделать, проделаем два небольших действия.
Первое, это создадим или скопируем файл инициализационных параметров 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:
SQL> connect sys as sysdba Enter password: Connected to an idle instance. SQL> startup nomount pfile=c:\oraclexe\app\oracle\product\11.2.0\server\database\initXE.ora ORACLE instance started. Total System Global Area 535662592 bytes Fixed Size 1384760 bytes Variable Size 226496200 bytes Database Buffers 301989888 bytes Redo Buffers 5791744 bytes
Создаём базу данных следующей командой, указав в ней необходимый нам набор символов (строка character set cl8mswin1251):
SQL> create database 2 maxinstances 1 3 maxloghistory 2 4 maxlogfiles 16 5 maxlogmembers 2 6 maxdatafiles 30 7 datafile 'c:\oraclexe\app\oracle\oradata\XE\system.dbf' 8 size 200M reuse autoextend on next 10M maxsize 600M 9 extent management local 10 sysaux datafile 'c:\oraclexe\app\oracle\oradata\XE\sysaux.dbf' 11 size 10M reuse autoextend on next 10M 12 default temporary tablespace temp tempfile 'c:\oraclexe\app\oracle\oradata\XE\temp.dbf' 13 size 20M reuse autoextend on next 10M maxsize 500M 14 undo tablespace undotbs1 datafile 'c:\oraclexe\app\oracle\oradata\XE\undotbs1.dbf' 15 size 50M reuse autoextend on next 5M maxsize 500M 16 character set cl8mswin1251 17 national character set al16utf16 18 set time_zone='00:00' 19 controlfile reuse 20 logfile 'c:\oraclexe\app\oracle\oradata\XE\log1.dbf' size 50m reuse 21 , 'c:\oraclexe\app\oracle\oradata\XE\log2.dbf' size 50m reuse 22 , 'c:\oraclexe\app\oracle\oradata\XE\log3.dbf' size 50m reuse 23 user system identified by oracle 24 user sys identified by oracle 25 / Database created.
База данных в нужной нам кодировке создана. Добавим к ней табличное пространство USERS:
SQL> create tablespace users 2 datafile 'c:\oraclexe\app\oracle\oradata\XE\users.dbf' 3 size 100M reuse autoextend on next 10M maxsize 11G 4 extent management local 5 / Tablespace created.
Запускаем на выполнение следующие скрипты:
-- Создаёт словарь базы данных SQL>@c:\oraclexe\app\oracle\product\11.2.0\server\rdbms\admin\catalog.sql -- Создаёт дополнительные представления по блокировкам Oracle SQL>@c:\oraclexe\app\oracle\product\11.2.0\server\rdbms\admin\catblock -- Создаёт дополнительные типы, таблицы, представления, процедуры, пакеты SQL>@c:\oraclexe\app\oracle\product\11.2.0\server\rdbms\admin\catproc -- Создаёт объекты для поддержки криптографии SQL>@c:\oraclexe\app\oracle\product\11.2.0\server\rdbms\admin\catoctk -- Создаёт таблицу PRODUCT_USER_PROFILE для SQL*Plus SQL>@c:\oraclexe\app\oracle\product\11.2.0\server\sqlplus\admin\pupbld
Перезапускаем базу данных:
SQL> connect sys as sysdba Enter password: Connected. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup; ORACLE instance started. Total System Global Area 535662592 bytes Fixed Size 1384760 bytes Variable Size 226496200 bytes Database Buffers 301989888 bytes Redo Buffers 5791744 bytes Database mounted. Database opened.
Смотрим значения параметров NLS базы данных:
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS PARAMETER VALUE ----------------------- ---------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET CL8MSWIN1251 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 AL16UTF16 NLS_RDBMS_VERSION 11.2.0.2.0
Как видим, созданная вновь база данных имеет однобайтовый набор символов (NLS_CHARACTERSET CL8MSWIN1251). Что нам и надо было получить.
SQL> SELECT DUMP('Я', 1017) FROM dual; DUMP('Я',1017) ------------------------------------------ Typ=96 Len=1 CharacterSet=CL8MSWIN1251: df
Напоследок хочется сказать о том, зачем надо было распаковывать файлы из архива xsl.rar в каталог C:\oraclexe\app\oracle\product\11.2.0\server\rdbms\xml. Если это не сделать до выполнения скрипта catproc, то потом окажется, что утилита Oracle Data Pump Export (expdp) отказывается работать, выдавая ошибку:
Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production ORA-39006: internal error ORA-39213: Metadata processing is not available
Если вы забыли скопировать файлы архива до выполнения скрипта, то ничего страшного, это можно сделать и позже. Единственное, надо не забыть выполнить после этого процедуру LOD_STYLESHEETS пакета DBMS_METADATA_UTIL:
SQL> exec dbms_metadata_util.load_stylesheets; PL/SQL procedure successfully completed.
Самое популярное
- Практическое администрирование Oracle — Аудит. Часть1.
- RMAN в примерах — Быстрый старт. Глава 1.
- RMAN В ПРИМЕРАХ — Использование RMAN. Глава 3. Часть 2
- RMAN В ПРИМЕРАХ — Конфигурирование окружения RMAN. Глава 4. Часть 1.
- Дублирование базы данных с помощью RMAN. Часть 1.
Al32utf8 что за кодировка
Делаю пакет SSIS для преобразования MDB (Access) с юникод. полями
в Оракл 11 в котором поля VARCHAR2
Поля в оракле будут VARCHAR2 (NVARCHAR нельзя юзать)
В моей тестовой системе у оракла NLS_CHARACTERSET WE8MS1252 (америк.)
В целевой системе оказалось AL32UTF8 (не могу поставтиь к сожалению оракл. сервер с такой бд)
и мой пакет перестал работать — стал разбираться
в SSIS есть 2 типа строковых полей DTS_STR обычные, DT_WSTR — юникодные
оказалось чтобы записать в оракл. VARCHAR2 поля считанные из аксесса (юникод.) мне надо было
1 когда NLS_CHARACTERSET WE8MS1252
преобразовать их из юникода в строки (- иначе ругалось can’t convert between unicode and non-unicode data)
и писать строковые поля туда
2 когда NLS_CHARACTERSET AL32UTF8
не трогать — т.е писать напрямую юникодные поля в VARCHAR2
понимаю что это дела SSIS и все таки
?1 чем отличается NLS_CHARACTERSET WE8MS1252 vs AL32UTF8
?2 когда AL32UTF8 — оно возвращает из VARCHAR юникод. значения или нет ?
и как это можно проверить
Igor Korolyov
05.01.11 16:11:05
Кодировка базы определяет в каком виде ХРАНЯТСЯ строки — наподобиии фоксового CPDBF() — если данные хранятся в одной из однобайтных кодировок (WE8MS1252 равно как и CL8MSWIN1251 являются однобайтными) то в них НИКАК не сохранить юникодные данные. Более того, поскольку кодировка определяет набор допустимых символов, то в общем случае в базу с кодировкой WE8MS1252 невозможно будет записать кириллицу, а в базу с кодировкой CL8MSWIN1251 — западноевропейские спец-буковки и символы.
Однако это ещё пол-дела. Самое интересное наступает тогда, когда с базой начинает работать клиент (SSIS такой же клиент как и прочие) дело в том, что у клиента НЕЗАВИСИМО настраивается кодировка (при помощи переменной окружения NLS_LANG или одноименного ключа в реестре). Тогда клиентское ПО Oracle (или сам сервер) дополнительно проводит конвертацию из одной кодировки в другую. Конечно же преобразовать без потерь 1251 в 1252 невозможно — равно как и unicode в любую из однобайтных кодировок.
AL32UTF8 — это как раз юникодная кодировка (со внутренним представлением данных в кодировке UTF8).
К сожалению поставленные вопросы не совсем корректны чтобы можно было на них дать точный ответ. Просто мысли.
1) Записать в базу с основной кодировкой (договооримся сразу что N*CHAR поля и соответственно NLS_NCHAR_CHARACTERSET кодировку мы не рассматриваем) WE8MS1252 юникодные данные невозможно без потерь. «Потеряно» будет как минимум всё что не укладывается в рамки западноевропейских буковок (в т.ч. кириллица) — как максимум, ещё и сами западноевропейские буковки исказатся.
2) Записать в базу с основной кодировкой AL32UTF8 юникод МОЖНО — но опять же всё сильнейшим образом зависит от настроек клиента — в идеале он тоже должен быть настроен на AL32UTF8 или хотя-бы на другой юникод (например AL16UTF16).
3) Настройку NLS_LANG клиента крайне желательно делать такой-же как и настройку NLS_CHARACTERSET сервера — дабы избежать перекодировки пре передаче строковых данных.
4) Отмазка «не могу поставить» не канает. Как минимум есть Oracle 10gXE Universal, который именно юникодный и есть. Его без проблем можно локально себе установить и тестировать что надо.
КРАЙНЕ рекомендую если не внимательно прочесть, то хотя-бы ознакомится с вот этим документом (его положения в принципе и к предыдущим версиям СУБД относятся).
download.oracle.com
Гулин Федор
05.01.11 18:02:34
Игорь СПАСИБО
(вообщем то и расчитывал что ты ответишь
1 про конвертацию чего то слышал — но
3 да выставлял NLS_LANG AMERICAN_AMERICA.AL32UTF8 на удалленом ПК (точнее на удаленной виртуальной машине) — пл-скл девелопер ругался
4 поставить действительно не могу — причин масса и не только технических
— всё сильнейшим образом зависит от настроек клиента
2 ССИС это вещь в себе — но вроде пишет юникод в varchar2 — по крайней мере с пл-скл девелопера
выглядит это похоже
Гулин Федор
09.08.13 18:12:52
Игорь появлися еще один подвопрос
Оракл 11
NLS_CHARACTERSET = AL32UTF8
с win ты все объяснил
счас оракл. сервер на линуксе
я загонял скл-лоадером данные с винды ( лок. ПК)
— все ок с NLS_LANG = AMERICAN_AMERICA.AL32UTF8
потом пробую с юинкса тоже через слк-лоадер
и смотрю что данные с западными символами ок записались
даже без установки перемненной NLS_LANG
в CTL : CHARACTERSET WE8ISO8859P1
csv файлы в ANSI кодировке
в юниксе
locale :
LANG=en_US.UTF-8
LC_CTYPE=»en_US.UTF-8″
LC_NUMERIC=»en_US.UTF-8″
LC_TIME=»en_US.UTF-8″
LC_COLLATE=»en_US.UTF-8″
LC_MONETARY=»en_US.UTF-8″
LC_MESSAGES=»en_US.UTF-8″
LC_PAPER=»en_US.UTF-8″
LC_NAME=»en_US.UTF-8″
LC_ADDRESS=»en_US.UTF-8″
LC_TELEPHONE=»en_US.UTF-8″
LC_MEASUREMENT=»en_US.UTF-8″
LC_IDENTIFICATION=»en_US.UTF-8″
LC_ALL=
Bürvenich , HÖFLER Все загналось Ок
правильно ли я понял что
берется установка LANG=en_US.UTF-8
и так как она совпадает с оракл. — то промежуточных преобразований не происходит
и все ок
Igor Korolyov
10.08.13 00:09:49
Гулин Федор
правильно ли я понял что
берется установка LANG=en_US.UTF-8
и так как она совпадает с оракл. — то промежуточных преобразований не происходит
и все ок
Да. Преобразования, очевидно, делает либо сам лоадер (скорее всего), либо клиент по его указанию — ну когда из WE8ISO8859P1 делает юникод, который уже далее без преобразований поступает в БД.
Но мне кажется что есть моменты, когда всё-же лучше явно иметь переменную NLS_LANG Что-то при экспорте/импорте кажись «коротило».