Локаль Поддержка локали означает соблюдение приложением культурных предпочтений в отношении алфавитов, сортировки, форматирования чисел и т. д. Digital Q.DataBase использует стандартные функции ISO C и POSIX для работы с локалями, предоставляемые операционной системой сервера. Для получения дополнительной информации обратитесь к документации вашей операционной системы.
Поддержка локали автоматически инициализируется при создании кластера баз данных с помощью 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). Вся остальная поддержка локалей встроена автоматически.
Настройки локали влияют на следующие функции SQL:
Порядок сортировки в запросах с использованием предложения ORDER BY или стандартных
операторов сравнения текстовых данных
Операторы сопоставления с образцом (LIKE, SIMILAR TO,
и регулярные выражения в стиле POSIX); локали влияют как на поиск без учета регистра,
так и на классификацию символов по
регулярные выражения с классами символов
Возможность использования индексов с LIKE предложениями
Недостатком использования локалей, отличных от C или
POSIX в Digital Q.DataBase является влияние на производительность. Это замедляет обработку символов и препятствует использованию обычных индексов LIKE. По этой причине используйте локали только в том случае, если они действительно необходимы.
В качестве обходного решения, позволяющего Digital Q.DataBase использовать индексы с LIKE предложениями в локалях, отличных от C, существует несколько специальных классов операторов. Они позволяют создавать индекс, выполняющий строгое посимвольное сравнение и игнорирующий правила сортировки локали. Обратитесь к Раздел 2.8.10
за дополнительной информацией. Другой подход заключается в создании индексов с использованием C правил сортировки, как описано в
Раздел 3.8.2.
Локали могут быть выбраны в различных областях действия в зависимости от требований.
В представленном выше обзоре было показано, как локали указываются с помощью
initdb для установки значений по умолчанию для всего кластера баз данных. В следующем списке указано, на каких уровнях могут быть выбраны локали. Каждый элемент предоставляет значения по умолчанию для последующих элементов, а каждый нижестоящий элемент позволяет переопределять эти значения с более тонкой степенью детализации.
Как было пояснено выше, среда операционной системы предоставляет значения по умолчанию для локалей вновь инициализированного кластера баз данных. Во многих случаях этого достаточно: если операционная система настроена на нужный язык и регион, то по умолчанию Digital Q.DataBase также будет функционировать в соответствии с этой локалью.
Как показано выше, параметры командной строки для initdb
определяют настройки локали для вновь инициализированного кластера баз данных.
Используйте этот вариант, если в операционной системе не настроена локаль,
необходимая для вашей системы баз данных.
Локаль может быть выбрана отдельно для каждой базы данных. SQL-команда
CREATE DATABASE и его эквивалент для командной строки
createdb имеют для этого соответствующие параметры. Используйте этот вариант, например, если кластер баз данных содержит базы данных для нескольких арендаторов с различными требованиями.
Настройки локали могут быть заданы для отдельных столбцов таблицы. Для этого используется объект SQL под названием collations и это описано в Раздел 3.8.2. Используйте эту возможность, например, для сортировки данных на разных языках или для настройки порядка сортировки в конкретной таблице.
Наконец, локаль можно выбрать для отдельного запроса. Здесь также используются объекты правил сортировки SQL. Это может применяться для изменения порядка сортировки на основе выбора во время выполнения или для разовых экспериментов.
Провайдер локали определяет библиотеку, задающую поведение локали для правил сортировки и классификации символов.
Команды и инструменты для выбора настроек локали, описанные выше, имеют параметр для выбора провайдера локали. Ниже приведен пример инициализации кластера баз данных с использованием провайдера 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.
Формат ICU для имени локали — это языковой тег.
CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP'); CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');
При определении нового объекта правил сортировки 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, правила сортировки все равно будут созданы, однако их поведение может не соответствовать ожидаемому.
Языковой тег, согласно определению в 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 для получения подробных сведений и дополнительных примеров использования языковых тегов с настраиваемыми правилами сортировки для локали.
Если поддержка локали работает не так, как описано выше,
убедитесь, что поддержка локалей в вашей операционной системе
настроена корректно. Чтобы проверить, какие локали установлены в системе, можно использовать команду 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 или напишите в список рассылки разработчиков.