23.1. Поддержка локали#

23.1. Поддержка локали
23.1. Поддержка локали
Назад НаверхГлава 23. ЛокализацияНачало Далее

23.1. Поддержка локали #

23.1.1. Обзор
23.1.2. Поведение
23.1.3. Выбор локалей
23.1.4. Поставщики локализации
23.1.5. Локали ICU
23.1.6. Проблемы

Поддержка локали означает, что приложение учитывает культурные предпочтения, касающиеся алфавитов, сортировки, форматирования чисел и т. д. Tantor SE использует стандартные средства локали ISO C и POSIX, предоставляемые операционной системой сервера. Дополнительную информацию см. в документации вашей системы.

23.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 - это такие категории. Они влияют на порядок отображения индексов, поэтому они должны быть зафиксированы, иначе индексы на текстовых столбцах могут быть повреждены. (Но вы можете смягчить это ограничение, используя правила сортировки, как описано в разделе Раздел 23.2). Значения по умолчанию для этих категорий определяются при запуске команды initdb, и эти значения используются при создании новых баз данных, если они не указаны иначе в команде CREATE DATABASE.

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

В качестве обходного решения, чтобы Tantor SE мог использовать индексы с предложениями LIKE вне локали C, существуют несколько пользовательских классов операторов. Они позволяют создавать индекс, выполняющий строгое сравнение символа за символом, игнорируя правила сравнения локали. Дополнительную информацию см. в разделе Раздел 11.10. Другой подход - создание индексов с использованием правила сортировки C, описанной в разделе Раздел 23.2.

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

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

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

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

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

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

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

23.1.4. Поставщики локализации #

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

Команды и инструменты, которые выбирают настройки локали, как описано выше, каждый из них имеет опцию для выбора поставщика локали. Вот пример инициализации кластера базы данных с использованием поставщика 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, и поведение основано на Unicode. Сортировка использует только значения кодовых точек. Классы символов регулярных выражений основаны на семантике "Совместимо с POSIX", а отображение регистра является вариантом "простое".

icu

Поставщик icu использует внешний ICU library. Tantor SE должен быть настроен с поддержкой.

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

Примечание

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

libc

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

Примечание

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

23.1.5. Локали ICU #

23.1.5.1. Названия локалей ICU #

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

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

23.1.5.2. Канонизация и валидация локали #

При определении нового правила сортировки 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"

Если вы видите это уведомление, убедитесь, что поставщик и локаль соответствуют ожидаемому результату. Для получения стабильных результатов при использовании поставщика 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, то правило сортировки все равно будет создано, но поведение может не соответствовать ожиданиям пользователя.

23.1.5.3. Языковой Тег #

Языковой тег, определенный в 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)

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

23.1.6. Проблемы #

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

Проверьте, что Tantor SE действительно использует локаль, которую вы думаете. Настройки LC_COLLATE и LC_CTYPE определяются при создании базы данных и не могут быть изменены, кроме как путем создания новой базы данных. Другие настройки локали, включая LC_MESSAGES и LC_MONETARY, изначально определяются окружением, в котором запущен сервер, но могут быть изменены "на лету". Вы можете проверить активные настройки локали с помощью команды SHOW.

Каталог src/test/locale в исходном дистрибутиве содержит набор тестов для поддержки локализации Tantor SE.

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

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

Назад Наверх Далее
Глава 23. Локализация Начало 23.2. Поддержка правил сортировки