×
Мы обрабатываем cookies, чтобы сделать наш сайт удобнее и персонализированнее для вас. Подробнее: политика использования «cookies» и «политики конфиденциальности».

Для самостоятельной настройки ознакомьтесь с инструкцией

Дополнительные настройки cookies в браузерах

Файлы cookie автоматически загружаются в ваш браузер при посещении веб-сайта. У вас есть возможность управлять этими файлами. Если Вы не согласны с использованием файлов cookies, запретите их сохранение на своём устройстве, удалите уже имеющиеся файлы cookies через настройки браузера или прекратите использование сайта.

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

Инструкция по отключению cookies
Принять
Настроить
Отклонить

ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.
Техподдержка
Документация
Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"
Скачать всю документацию:

3.8.1. Поддержка локали

3.8.1.1. Обзор
3.8.1.2. Поведение
3.8.1.3. Выбор локалей
3.8.1.4. Провайдеры локалей
3.8.1.5. Локали ICU
3.8.1.6. Проблемы

Локаль Поддержка локали означает соблюдение приложением культурных предпочтений в отношении алфавитов, сортировки, форматирования чисел и т. д. Digital Q.DataBase использует стандартные функции ISO C и POSIX для работы с локалями, предоставляемые операционной системой сервера. Для получения дополнительной информации обратитесь к документации вашей операционной системы.

3.8.1.1. Обзор #

Поддержка локали автоматически инициализируется при создании кластера баз данных с помощью initdb. initdb по умолчанию инициализирует кластер баз данных с настройками локали текущей среды выполнения. Таким образом, если система уже настроена на использование необходимой локали, никаких дополнительных действий не требуется. Если требуется использовать другую локаль (или вы не уверены, какая локаль установлена в системе), можно указать initdb конкретную локаль, используя --locale параметр. Например:

initdb --locale=sv_SE

В данном примере для систем Unix устанавливается шведская локаль (sv), используемая в Швеции (SE). К другим возможным вариантам относятся en_US (американский английский) и fr_CA (канадский французский). Если для одной локали может использоваться несколько кодировок, спецификация может иметь вид language_territory.codeset. Например, fr_BE.UTF-8 представляет французский язык (fr) для Бельгии (BE) с использованием UTF-8 кодировка.

Список доступных в системе локалей и их наименования зависят от поставщика операционной системы и набора установленных компонентов. В большинстве систем Unix команда locale -a выводит список доступных локалей. В ОС Windows используются более развернутые имена локалей, такие как German_Germany или Swedish_Sweden.1252, однако общие принципы их работы идентичны.

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

LC_COLLATEПорядок сортировки строк
LC_CTYPEКлассификация символов (определение букв и их эквивалентов в верхнем регистре)
LC_MESSAGESЯзык системных сообщений
LC_MONETARYФорматирование денежных величин
LC_NUMERICФорматирование чисел
LC_TIMEФорматирование дат и времени

Названия категорий соответствуют именам initdb параметры для переопределения выбора локали для конкретной категории. Например, чтобы установить франко-канадскую локаль, но использовать правила США для форматирования валюты, используйте initdb --locale=fr_CA --lc-monetary=en_US.

Если требуется, чтобы система работала без поддержки локали, используйте специальное имя локали C, или эквивалентное POSIX.

Значения некоторых категорий локали должны быть зафиксированы при создании базы данных. Можно использовать различные настройки для разных баз данных, но после создания базы данных изменить их для этой базы данных невозможно. LC_COLLATE и LC_CTYPE относятся к таким категориям. Они влияют на порядок сортировки в индексах, поэтому должны оставаться неизменными, иначе индексы в текстовых столбцах будут повреждены. (Однако это ограничение можно смягчить, используя правила сортировки, как описано в Раздел 3.8.2.) Значения по умолчанию для этих категорий определяются при выполнении initdb , и эти значения используются при создании новых баз данных, если иное не указано в команде CREATE DATABASE command.

Другие категории локали можно изменить в любое время путем настройки параметров конфигурации сервера, имена которых совпадают с названиями категорий локали (см. Раздел 3.4.11.2 для получения подробных сведений). Значения, выбранные initdb , фактически записываются только в файл конфигурации postgresql.conf для использования в качестве значений по умолчанию при запуске сервера. Если удалить эти назначения из postgresql.conf , то сервер унаследует настройки из своей среды выполнения.

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

Примечание

Под наследованием локали из среды выполнения в большинстве операционных систем понимается следующее: для определенной категории локали (например, для правил сортировки) проверяются указанные ниже переменные окружения в порядке их следования до обнаружения первого установленного значения: LC_ALL, LC_COLLATE (или переменная, соответствующая конкретной категории), LANG. Если ни одна из этих переменных окружения не задана, для локали используется значение по умолчанию C.

Некоторые библиотеки локализации сообщений также учитывают переменную окружения LANGUAGE который переопределяет все остальные параметры локали для установки языка сообщений. В случае сомнений обратитесь к документации по используемой операционной системе, в частности к разделам о gettext.

Для обеспечения перевода сообщений на предпочтительный язык пользователя NLS должен быть выбран на этапе сборки (configure --enable-nls). Вся остальная поддержка локалей встроена автоматически.

3.8.1.2. Поведение #

Настройки локали влияют на следующие функции SQL:

  • Порядок сортировки в запросах с использованием предложения ORDER BY или стандартных операторов сравнения текстовых данных

  • Функции upper, lowerи initcap

  • Операторы сопоставления с образцом (LIKE, SIMILAR TO, и регулярные выражения в стиле POSIX); локали влияют как на поиск без учета регистра, так и на классификацию символов по регулярные выражения с классами символов

  • Функции to_char семейство функций

  • Возможность использования индексов с LIKE предложениями

Недостатком использования локалей, отличных от C или POSIX в Digital Q.DataBase является влияние на производительность. Это замедляет обработку символов и препятствует использованию обычных индексов LIKE. По этой причине используйте локали только в том случае, если они действительно необходимы.

В качестве обходного решения, позволяющего Digital Q.DataBase использовать индексы с LIKE предложениями в локалях, отличных от C, существует несколько специальных классов операторов. Они позволяют создавать индекс, выполняющий строгое посимвольное сравнение и игнорирующий правила сортировки локали. Обратитесь к Раздел 2.8.10 за дополнительной информацией. Другой подход заключается в создании индексов с использованием C правил сортировки, как описано в Раздел 3.8.2.

3.8.1.3. Выбор локалей #

Локали могут быть выбраны в различных областях действия в зависимости от требований. В представленном выше обзоре было показано, как локали указываются с помощью initdb для установки значений по умолчанию для всего кластера баз данных. В следующем списке указано, на каких уровнях могут быть выбраны локали. Каждый элемент предоставляет значения по умолчанию для последующих элементов, а каждый нижестоящий элемент позволяет переопределять эти значения с более тонкой степенью детализации.

  1. Как было пояснено выше, среда операционной системы предоставляет значения по умолчанию для локалей вновь инициализированного кластера баз данных. Во многих случаях этого достаточно: если операционная система настроена на нужный язык и регион, то по умолчанию Digital Q.DataBase также будет функционировать в соответствии с этой локалью.

  2. Как показано выше, параметры командной строки для initdb определяют настройки локали для вновь инициализированного кластера баз данных. Используйте этот вариант, если в операционной системе не настроена локаль, необходимая для вашей системы баз данных.

  3. Локаль может быть выбрана отдельно для каждой базы данных. SQL-команда CREATE DATABASE и его эквивалент для командной строки createdb имеют для этого соответствующие параметры. Используйте этот вариант, например, если кластер баз данных содержит базы данных для нескольких арендаторов с различными требованиями.

  4. Настройки локали могут быть заданы для отдельных столбцов таблицы. Для этого используется объект SQL под названием collations и это описано в Раздел 3.8.2. Используйте эту возможность, например, для сортировки данных на разных языках или для настройки порядка сортировки в конкретной таблице.

  5. Наконец, локаль можно выбрать для отдельного запроса. Здесь также используются объекты правил сортировки SQL. Это может применяться для изменения порядка сортировки на основе выбора во время выполнения или для разовых экспериментов.

3.8.1.4. Провайдеры локалей #

Провайдер локали определяет библиотеку, задающую поведение локали для правил сортировки и классификации символов.

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

initdb --locale-provider=icu --icu-locale=en

Подробную информацию см. в описании соответствующих команд и программ. Обратите внимание, что допускается комбинирование провайдеров локали на различных уровнях детализации. Например, можно использовать libc по умолчанию для кластера, но создать отдельную базу данных с провайдером icu провайдера, после чего объекты правил сортировки могут использовать любой провайдер внутри этих баз данных.

Независимо от выбранного провайдера локали, операционная система по-прежнему используется для обеспечения определенных аспектов локализации, таких как системные сообщения (см. lc_messages).

Ниже перечислены доступные провайдеры локали:

builtin

Функции builtin Этот провайдер использует встроенные операции. Данным провайдером поддерживаются только C C и C.UTF-8 локали.

Функции C Поведение локали идентично поведению локали C в провайдере libc. При использовании данного локаль, поведение может зависеть от кодировки базы данных.

Функции C.UTF-8 локаль доступна только в том случае, когда кодировка базы данных — UTF-8, а само поведение основано на Юникоде. Правила сортировки используют только значения кодовых точек. Классы символов в регулярных выражениях основаны на семантике «POSIX совместимый», а преобразование регистров выполняется в «простом» варианте.

icu

Функции icu провайдер использует внешнюю ICU библиотеку. Digital Q.DataBase должен быть сконфигурирован с соответствующей поддержкой.

ICU обеспечивает поведение правил сортировки и классификации символов, которое не зависит от операционной системы и кодировки базы данных, что предпочтительно при необходимости перехода на другие платформы без каких-либо изменений в результатах. LC_COLLATE и LC_CTYPE могут быть установлены независимо от ICU локаль.

Примечание

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

libc

Функции libc провайдер использует локаль C операционной системы библиотеку. Поведение правил сортировки и классификации символов определяется настройками LC_COLLATE и LC_CTYPE, поэтому их нельзя задать независимо.

Примечание

Одно и то же имя локали может иметь различное поведение на разных платформах при использовании провайдера libc.

3.8.1.5. Локали ICU #

3.8.1.5.1. Имена локалей ICU #

Формат ICU для имени локали — это языковой тег.

CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP');
CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');

3.8.1.5.2. Канонизация и проверка локали #

При определении нового объекта правил сортировки ICU или базы данных с провайдером ICU указанное имя локали преобразуется («канонизируется») в языковой тег, если оно еще не представлено в этой форме. Например,

CREATE COLLATION mycollation3 (provider = icu, locale = 'en-US-u-kn-true');
NOTICE:  используется стандартная форма "en-US-u-kn" для локали "en-US-u-kn-true"
CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8');
NOTICE:  используется стандартная форма "de-DE" для локали "de_DE.utf8"

Если отображается данное уведомление, убедитесь, что параметр provider и локаль соответствуют ожидаемому результату. Для обеспечения согласованности результатов при использовании провайдера ICU следует указывать канонический языковой тег вместо использования автоматического преобразования.

Локаль без указания названия языка или со специальным именем rootпреобразуется в значение языка und ("undefined").

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

Если при интерпретации имени локали возникает ошибка или если имя локали представляет язык или регион, не поддерживаемый ICU, будет выведено следующее предупреждение:

CREATE COLLATION nonsense (provider = icu, locale = 'nonsense');
WARNING:  ICU locale "nonsense" has unknown language "nonsense"
HINT:  To disable ICU locale validation, set parameter icu_validation_level to DISABLED.
CREATE COLLATION

icu_validation_level управляет способом вывода сообщения. Если не задан параметр ERROR, правила сортировки все равно будут созданы, однако их поведение может не соответствовать ожидаемому.

3.8.1.5.3. языковой тег #

Языковой тег, согласно определению в BCP 47, представляет собой стандартизированный идентификатор, используемый для обозначения языков, регионов и других характеристик локали.

Базовые языковые теги состоят из элементов язык-регион; или даже только язык. Элемент язык представляет собой код языка (например, fr для французского языка) и регион является кодом региона (например, CA для Канады). Примеры: ja-JP, de, или fr-CA.

Параметры правил сортировки могут быть включены в языковой тег для настройки их поведения. ICU обеспечивает широкие возможности настройки, такие как чувствительность (или нечувствительность) к диакритическим знакам, регистру и пунктуации; обработка цифр внутри текста; а также множество других опций для обеспечения различных вариантов использования.

Чтобы включить эту дополнительную информацию о правилах сортировки в языковой тег, добавьте -u, что указывает на наличие дополнительных настроек правил сортировки, за которыми следуют одна или несколько -пар-«ключ-значение» . Элемент пар является ключом для параметра правил сортировки и «ключ-значение» является допустимым значением для этого параметра. Для логических параметров -пар может быть указан без соответствующего -«ключ-значение», что подразумевает значение true.

Например, языковой тег en-US-u-kn-ks-level2 означает локаль для английского языка в регионе США с параметрами правил сортировки kn установленным в true и ks установленным в level2. Эти параметры означают, что правила сортировки будут нечувствительны к регистру и будут обрабатывать последовательность цифр как единое число:

CREATE COLLATION mycollation5 (provider = icu, deterministic = false, locale = 'en-US-u-kn-ks-level2');
SELECT 'aB' = 'Ab' COLLATE mycollation5 as result;
 result
--------
 t
(1 row)

SELECT 'N-45' < 'N-123' COLLATE mycollation5 as result;
 result
--------
 t
(1 row)

См. Раздел 3.8.2.3 для получения подробных сведений и дополнительных примеров использования языковых тегов с настраиваемыми правилами сортировки для локали.

3.8.1.6. Проблемы #

Если поддержка локали работает не так, как описано выше, убедитесь, что поддержка локалей в вашей операционной системе настроена корректно. Чтобы проверить, какие локали установлены в системе, можно использовать команду locale -a если ваша операционная система ее поддерживает.

Проверьте, что Digital Q.DataBase действительно использует ту локаль, которая предполагается. Параметры LC_COLLATE и LC_CTYPE определяются при создании базы данных и не могут быть изменены без создания новой базы данных. Другие параметры локали, включая LC_MESSAGES и LC_MONETARY изначально определяются средой, в которой запущен сервер, но могут быть изменены динамически. Текущие настройки локали можно проверить с помощью команды SHOW command.

Каталог src/test/locale в дистрибутиве исходных кодов содержит набор тестов для Digital Q.DataBaseподдержка локалей.

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

Поддержка каталогов перевода сообщений требует постоянных усилий многих добровольцев, желающих, чтобы Digital Q.DataBase корректно поддерживался их предпочтительный язык. Если переводы сообщений на ваш язык отсутствуют или выполнены не полностью, ваша помощь будет принята с благодарностью. Если вы хотите помочь, обратитесь к Глава 7.5 или напишите в список рассылки разработчиков.

Наверх
свяжитесь
с нами
контакты
Для прямой связи с нами вы можете использовать контакты ниже, либо оставить заявку через форму обратной связи, и мы обязательно свяжемся с вами

*поля обязательные к заполнению