Многоязыковость
Leonid Vorontsov
Поделитесь мыслями/знаниями, кто что знает.
Что-то я всё-таки не догоняю. Ситуация такова,
что в базе нужно хранить (искать, сортирвать) названия
на всех европейских языках (русский и греческий, к примеру,
включительно). В Informixе вообще такое возможно?
Если да, то как? С какой локалью должна быть
база, какая локаль на клиенте, на чём разрабатывать
клиентское приложение?
С нетерпением,
Леонид.
Igor Zavgorodny
/usr/informix/release/en_us/0333/GLSDOC.html
(Documentation Notes For
Informix Guide to GLS Functionality)
V. Unicode Universal Code Set (UCS) and Informix GLS
To store data from more than one non-English language in one database,
you can either use the GLS implementation of the UTF-8 UCS GLS locale
and code set conversion files, or use the Unicode UCS in your database.
To use Unicode with Informix GLS, you must be using Informix Dynamic
Server with Universal Data Option (IDS/UD) Version 9.1x or above, and
the Informix Unicode DataBlade module. The Unicode DataBlade module
enables users to store data in native Unicode format in a database and
to access and manipulate that data. For more information, see the
Informix Unicode DataBlade Module User's Guide.
Таким образом,
два варианта.
1. UTF-8 UCS GLS locale and code set conversion files
2. Unicode
2.1. 9-ка.
2.2. Объем хранимых в тексте данных в 2 раза больше.
2.3. Работа через Unicode DataBlade.
Regards, Igor.
Leonid Vorontsov
значение нужно присвоить переменным
DB_LOCALE и CLIENT_LOCALE?
> 2. Unicode
> 2.1. 9-ка.
Пока мимо.
yurik shestakov
LV> "Igor Zavgorodny" <dau...@ukr.net> wrote:
>> 1. UTF-8 UCS GLS locale and code set conversion files
LV> значение нужно присвоить переменным
LV> DB_LOCALE и CLIENT_LOCALE?
$ grep -i UTF $INFORMIXDIR/gls/cm3/registry
utf8 57372 # 0xe01c
Получается: DB_LOCALE=utf8; CLIENT_LOCALE=utf8; export CLIENT_LOCALE DB_LOCALE
--
// yurik shestakov
Vasyl Shulzhenko
"yurik shestakov" <yu4...@frigate.kiev.ua> wrote in message
news:20031013143...@frigate.kiev.ua...
Думаю, что так не получится. Ведь utf8 указывает только кодовую таблицу, а
локаль (задавать все правила, относящиеся к стране и языку) все равно нужно.
Интересно, что таблицы перекодировки на/с utf8 существуют (в 9.30.ТС1 -
всего 8 кодировок, а вот в 9.40.ТС1 - уже 44 кодировки!, причем это только в
одну сторону, а ведь есть еще и в обратную). С utf8 на СР1251 и обратно
таблицы есть в 9.40 (gls\cv9\e01c04e3.cvo , gls\cv9\04e3e01c.cvo )
Описание самой локали есть только для американцев (кто бы сомневался :)
(gls\lc11\en_us\e01c.lco) и создать базу (загрузить туда данные) и работать
можно, используя установки DB_LOCALE=en_us.utf8; CLIENT_LOCALE=en_us.utf8.
yurik shestakov
>> $ grep -i UTF $INFORMIXDIR/gls/cm3/registry
>> utf8 57372 # 0xe01c
>>
>> Получается: DB_LOCALE=utf8; CLIENT_LOCALE=utf8; export CLIENT_LOCALE
VS> Думаю, что так не получится. Ведь utf8 указывает только кодовую таблицу, а
VS> локаль (задавать все правила, относящиеся к стране и языку) все равно нужно.
VS> Интересно, что таблицы перекодировки на/с utf8 существуют (в 9.30.ТС1 -
VS> всего 8 кодировок, а вот в 9.40.ТС1 - уже 44 кодировки!, причем это только в
VS> одну сторону, а ведь есть еще и в обратную). С utf8 на СР1251 и обратно
VS> таблицы есть в 9.40 (gls\cv9\e01c04e3.cvo , gls\cv9\04e3e01c.cvo )
VS> Описание самой локали есть только для американцев (кто бы сомневался :)
VS> (gls\lc11\en_us\e01c.lco) и создать базу (загрузить туда данные) и работать
VS> можно, используя установки DB_LOCALE=en_us.utf8; CLIENT_LOCALE=en_us.utf8.
Да, я забыл, что нужно еще и имя локали (языка_страны) дописывать к codepage.
Но, по идее, языкозависимые вещи -- это только представление дат (название
месяцев и дней недели) и представление чисел (что есть разделитель
дробной части от целой, и тысяч в целой части числа).
Думаю, что DBDATE имеет более высокий приоритет, чем *_LOCALE, потому
представление даты ("DMT4.", например) можно "побороть". Ну и DBMONEY
так же поможет для случае *_LOCALE=en_us.utf8.
Кстати, помнится мне, что пару лет назад ктото из Улисса делился опытом
написания программ на Java с использованием Informix-а в качестве СУБД.
Вот там что-то было про поддержку Unicode в Informix. Хотя с тех
пор кое-что поменялось.
--
// yurik shestakov
Leonid Vorontsov
> LV> Какое значение нужно присвоить переменным
> LV> DB_LOCALE и CLIENT_LOCALE?
> Получается: DB_LOCALE=utf8; CLIENT_LOCALE=utf8; export CLIENT_LOCALE
DB_LOCALE
-23101 Unable to load locale categories.
Leonid Vorontsov
> > DB_LOCALE=en_us.utf8; CLIENT_LOCALE=en_us.utf8.
> ОК, будем пробовать.
Всё равно не всекаюсь. Допустим базу я создал.
Получается, что работать с ней можно только если
CLIENT_LOCALE=en_us.utf8. Приконнектиться с
CLIENT_LOCALE=lv_lv.1257 не удаётся:
23115: Code sets of the locale categories are not the same.
Тогда спрашивается, для чего нужны файлы перекодировок
04e9e01c.cvo и e01c04e9.cvo?
"Ничего не понимаю." (c)
Vasyl Shulzhenko
"Leonid Vorontsov" <Leonids....@dati.lv> wrote in message
news:bmg9dd$8hq$1...@news.lucky.net...
> "Leonid Vorontsov" <Leonids....@dati.lv> wrote:
> > > DB_LOCALE=en_us.utf8; CLIENT_LOCALE=en_us.utf8.
> > ОК, будем пробовать.
> Всё равно не всекаюсь. Допустим базу я создал.
> Получается, что работать с ней можно только если
> CLIENT_LOCALE=en_us.utf8. Приконнектиться с
Почему же, можно с en_us.<любая доступная кодовая таблица для этого языка>
Например, en_us.CP1252
> CLIENT_LOCALE=lv_lv.1257 не удаётся:
> 23115: Code sets of the locale categories are not the same.
> Тогда спрашивается, для чего нужны файлы перекодировок
> 04e9e01c.cvo и e01c04e9.cvo?
Таблицы перекодировок нужны (и могут использоваться) только в пределах одной
локали (т.е. внутри EN_US и т.д.)
> "Ничего не понимаю." (c)
Я тоже очень многого :)
Вот посмотри для информации, что я увидел в CSDK. Может чем поможет...
-----------------------------------------------------------
2. Support for Unicode
The Client SDK now supports Unicode 3.1.1 code points for multilingual data
via the environment variable GL_USEGLU.
By default, that is without setting GL_USEGLU, Unicode and GB18030-2000 are
supported using Informix locales. In Client SDK version 2.81, Unicode and
GB18030-2000 can also be supported through ICU (International Components for
Unicode) by setting the GL_USEGLU environment variable to 1. Using Unicode
and GB18030-2000 from ICU have at least the following benefits:
- Unicode 3.1.1 support instead of Unicode 3.01 supported traditional
Informix locales
- Better Unicode collation support instead of only codepoints ordering in
traditional Informix locales
For more information about ICU, refer to the ICU website at:
http://oss.software.ibm.com/icu/.
On Windows, GL_USEGLU can also be set in setnet32 for client applications,
including the IBM-Informix ODBC driver.
Note: When the database locale codeset is UTF8, the database and client
applications must have GL_USEGLU set to the same value. Otherwise, the
client cannot connect.
The use of GLU is turned off, by default and GLS will use the locale files
for Unicode and GB18030-2000. The primary reason for this is that C++
linker is required in order to use ICU. This will have a wide impact on the
existing and new applications. Every existing application will have to be
re-linked using C++ and all new applications will require a C++ linker.
Turning GLU off by default mitigates this condition.
3. Support for Unicode Collation
The GLS library now supports the Unicode Collation Algorithm that was
developed by the Unicode consortium. This de facto standard for
multinational applications incorporates ICU technology.
Vasyl Shulzhenko
> "Vasyl Shulzhenko" <nospam_...@mail.ru> wrote:
> > > Получается: DB_LOCALE=utf8; CLIENT_LOCALE=utf8; export...
> > Думаю, что так не получится.
>
> > Ведь utf8 указывает только кодовую таблицу, а
> > локаль (задавать все правила, относящиеся к стране и языку) все равно
> нужно.
> много языков, то на фига указывать язык?
Так ведь в понятие локали входит много чего, например, в каком формате
выдавать тебе даты, десятичные числа, названия месяцев и дней недели ?
То, что оно хранится в базе в независимом формате, это хорошо, но ведь тебе
нужно выдать только в одном представлении для твоего языка и места.
> Интересно, что таблицы перекодировки на/с utf8 существуют (в 9.30.ТС1 -
> > всего 8 кодировок, а вот в 9.40.ТС1 - уже 44 кодировки!, причем это
только
> в
> > одну сторону, а ведь есть еще и в обратную).
> Перекодировка нужна если CLIENT_LOCALE отличается от DB_LOCALE.
> > Описание самой локали есть только для американцев (кто бы сомневался :)
> > (gls\lc11\en_us\e01c.lco)
> Вот блин! Если бы у меня было так же, я бы и не сомневался. Дело в том,
что
> у меня не так (см. attach). Вот я сижу и думаю, что же ставить ar_ae или
> lv_lv.
> Правда, такая ситуация (почему-то?) только на одном сервере.
Старые какие то файлы, я бы в них особо не верил.
Думаю, что это кто то установил продукт типа
I_International_Language_Suplement_v Х.Х
который был у информикса именно для многонациональной поддержки (в том числе
и переведенные файлы сообщений сервера и утилит).
> Кто и когда залил туда эти файлы, понятия не имею. Что бросается в глаза,
> размер файла в директории en_us на порядок больше всех остальных. Что
А в 9.40 всего 82К, хотя в 9.30 за 300К.
> бы это могло означать? Что в локалях других стран/языков описаны только
> символы конкретного языка, а не всех, как в en_us?
Вполне может быть
> > и создать базу (загрузить туда данные) и работать
> > можно, используя установки DB_LOCALE=en_us.utf8;
CLIENT_LOCALE=en_us.utf8.
> ОК, будем пробовать.
Только таким путем и сможешь проверить и разобраться, так как похоже, что
живого опыта больше ни у кого нет.
Не забудь поделиться опытом :))
Nikolay Kulikov
в IDS 9.4. есть SET CURRENT LOCALE=....
смотри what's new для 9.4