Поддержка языковых стандартов

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

Обзор

Поддержка локализации автоматически инициализируется при создании кластера баз данных с помощью 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 --locale=fr_CA --lc-monetary=en_US.

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

Некоторые категории локалей требуют фиксированных значений на этапе создания базы данных. Разные настройки могут применяться к разным базам данных, но после их создания изменить эти значения невозможно. К таким категориям относятся LC_COLLATE и LC_CTYPE. Они определяют порядок сортировки индексов, поэтому их изменение после создания может привести к повреждению индексов по текстовым столбцам. Это ограничение можно частично обойти с помощью сопоставлений (collations), как описано в разделе Поддержка упорядочивания.

Значения по умолчанию для этих категорий задаются при запуске initdb. При создании новых баз данных используются именно эти значения, если они не переопределены в команде CREATE DATABASE.

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

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

Примечание

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

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

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

Поведение

Параметры локализации влияют на следующие функции SQL:

• Порядок сортировки в запросах, использующих ORDER BY или стандартные операторы сравнения для текстовых данных

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

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

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

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

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

В качестве обходного пути для того, чтобы позволить PostgreSQL использовать индексы с условиями LIKE под нелокалью С, существует несколько пользовательских классов операторов. Они позволяют создать индекс, который выполняет строгое посимвольное сравнение, игнорируя правила сравнения локалей. Обратитесь к разделу Классы операторов и семейства операторов за дополнительной информацией. Другой подход заключается в создании индексов с использованием упорядочения C, как описано в разделе Поддержка упорядочивания.

Выбор локалей

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

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

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

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

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

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

Поставщики локалей

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

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

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

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

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

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

builtin

: Провайдер builtin использует встроенные операции. Только локали C и C.UTF-8 поддерживаются этим поставщиком.

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

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

icu

: Провайдер icu использует внешнюю библиотеку ICU. PostgreSQL должен был быть сконфигурирован с поддержкой.

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

(ru-ru.locale.примечание-1)=

Примечание

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

libc

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

(ru-ru.locale.примечание-2)=

Примечание

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

Локали ICU

Имена локалей ICU

Форматом имени локали для 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:  using standard form "en-US-u-kn" for locale "en-US-u-kn-true"
CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8');
NOTICE:  using standard form "de-DE" for locale "de_DE.utf8"

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

Локаль без указания языка или со специальным именем языка root преобразуется так, чтобы иметь язык und («неопределенный»).

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, представляет собой стандартизированный идентификатор, используемый для обозначения языков, регионов и другой информации о локали.

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

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

Чтобы включить эту дополнительную информацию о параметрах сортировки в языковой тег, добавьте -u, указывая наличие дополнительных параметров сортировки, за которым следует один или более пар вида -key-value. В этой паре key --- ключ для параметра сортировки, а value --- допустимое значение данного параметра. Для логических настроек можно указать -key без соответствующего -value, что подразумевает значение 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)

Смотрите раздел Пользовательские сортировки ICU для подробностей и дополнительных примеров использования языковых тегов с пользовательской информацией о сортировке для локали.

Проблемы

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

Следует убедиться, что сервер PostgreSQL использует ожидаемую локаль. Параметры LC_COLLATE и LC_CTYPE устанавливаются при создании базы данных и не могут быть изменены, за исключением случая пересоздания базы данных. Остальные параметры локализации, такие как LC_MESSAGES и LC_MONETARY, изначально определяются средой выполнения сервера, но допускают динамическое изменение.

Для проверки текущих активных параметров локали можно использовать команду SHOW.

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

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

Сохранение каталогов переводов сообщений требует регулярных усилий со стороны добровольцев, стремящихся сделать PostgreSQL доступной на родном языке. В случае, если переводы на определенный язык отсутствуют или неполны, участие в их разработке и улучшении может оказаться полезным. Если хотите помочь, обратитесь к разделу «Поддержка родного языка».