23.1. Поддержка языковых стандартов #
Поддержка языковых стандартов в приложениях относится к культурным предпочтениям, которые касаются алфавита, порядка сортировки, форматирования чисел и т. п. PostgreSQL использует соответствующие стандартам ISO C и POSIX возможности локали, предоставляемые операционной системой сервера. За дополнительной информацией обращайтесь к документации вашей системы.
23.1.1. Обзор #
Поддержка локали автоматически инициализируется, когда кластер базы данных создаётся при помощи initdb. initdb инициализирует кластер баз данных по умолчанию с локалью из окружения выполнения. Поэтому, если ваша система уже использует локаль, которую вы хотите выбрать для вашего кластера баз данных, вам не требуется дополнительно совершать никаких действий. Если вы хотите использовать другую локаль (или вы точно не знаете, какая локаль используется в вашей системе), вы можете указать для initdb, какую именно локаль использовать, задав параметр --locale. Например:
initdb --locale=ru_RU
Данный пример для Unix-систем задаёт русский язык (ru), на котором говорят в России (RU). Другими вариантами могут быть en_US (американский английский) и fr_CA (канадский французский). Если в языковом окружении может использоваться более одного набора символов, значение может принимать вид language_territory.codeset. Например, fr_BE.UTF-8 обозначает французский язык (fr), на котором говорят в Бельгии (BE), с кодировкой UTF-8.
То, какие локали и под какими именами доступны на вашей системе, зависит от того, что было включено в операционную систему производителем и что из этого было установлено. В большинстве Unix-систем команда locale -a выведет список доступных локалей. Windows использует более развёрнутые имена локалей, такие как German_Germany или Russian_Russia.1251, но принципы остаются теми же.
Иногда целесообразно объединить правила из различных локалей, например, использовать английские правила сравнения и испанские сообщения. Для этой цели существует набор категорий локали, каждая из которых управляет только определёнными аспектами правил локализации:
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или стандартных операторах сравнения текстовых данныхОператоры поиска по шаблону (
LIKE,SIMILAR TO, и регулярные выражения в стиле POSIX); локаль влияет как на поиск без учёта регистра, так и на классификацию знаков по классам символов регулярных выраженийВозможность использовать индексы с предложениями
LIKE
Недостатком использования отличающихся от C или POSIX локалей в PostgreSQL является влияние на производительность. Это замедляет обработку символов и мешает LIKE использовать обычные индексы. По этой причине используйте локали только в том случае, если они действительно вам нужны.
В качестве обходного решения, которое позволит PostgreSQL пользоваться индексами с предложениями LIKE с использованием локали, отличной от С, существует несколько классов пользовательских операторов. Они позволяют создать индекс, который выполняет строгое посимвольное сравнение, игнорируя правила сравнения, соответствующие локали. За дополнительными сведениями обратитесь к Разделу 11.10. Ещё один подход заключается в создании индексов с помощью правил сортировки C, как было сказано в Разделе 23.2.
23.1.3. Выбор локалей #
Локали могут выбираться на разных уровнях в зависимости от требований. В обзоре выше показано, как выбрать локаль при вызове initdb, чтобы на уровне кластера установить для параметров локали значения, которые будут использоваться по умолчанию. В следующем списке показано, где ещё можно выбирать локали. В каждом пункте устанавливаются значения по умолчанию для последующих пунктов, и в каждом последующем пункте можно переопределить заданные выше значения на более низком уровне.
Как объяснялось выше, по умолчанию значения языковых параметров в инициализируемом кластере БД определяются переменными среды ОС. Во многих случаях этого достаточно: если операционная система настроена для нужного языка/региона, то PostgreSQL по умолчанию также будет вести себя в соответствии с этой локалью.
Как показано выше, значения параметров локали для инициализируемого кластера также можно указать в аргументах командой строки
initdb. Используйте эту возможность, если вы хотите выбрать для вашей СУБД локаль, отличную от текущей локали операционной системы.Локаль можно выбрать для отдельной базы данных. Предназначенные для этого параметры имеются у SQL-команды
CREATE DATABASEи соответствующей ей внешней командыcreatedb. Это полезно, например, когда в одном кластере содержатся базы данных, принадлежащие различным клиентам с разными потребностями.Параметры локали можно задать для отдельных столбцов таблицы. Для этого используются объекты SQL, которые называются правила сортировки и описаны в Разделе 23.2. Это полезно для сортировки данных на разных языках или для изменения порядка сортировки конкретной таблицы.
Наконец, локали можно выбирать на уровне запросов. При этом также используются объекты правил сортировки 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 . PostgreSQL должен быть настроен с поддержкой этой библиотеки.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"
Получив такое уведомление, проверьте, что provider и locale соответствуют ожидаемому результату. Для согласованных результатов при использовании провайдера ICU укажите стандартную метку языка вместо того, чтобы полагаться на преобразование.
Локаль без имени языка или со специальным именем языка root преобразуется в язык und (undefined, неопределённый).
Для более лёгкого перехода на ICU большинство имён локалей libc и из некоторых других форматов можно преобразовывать в языковые метки. Имя локали 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, представляет собой стандартизированный идентификатор, используемый для определения языков, регионов и другой информации о локали.
Основные языковые метки — это язык-регион или даже только язык. Здесь язык — это код языка (например, fr для французского), а регион — код региона (например, CA для Канады). Примеры: ja-JP, de или fr-CA.
Параметры правил сортировки могут быть включены в языковую метку для настройки поведения этих правил. ICU предоставляет широкие возможности для настройки: чувствительность (или нечувствительность) к диакритическим знакам, регистру и пунктуации, обработка цифр в тексте, и многие другие варианты для различных целей.
Чтобы включить эту дополнительную информацию о правилах сортировки в языковую метку, добавьте параметр -u, указывающий на наличие дополнительных параметров правил сортировки, за которым следует одна или несколько пар -ключ-значение, где ключ — это ключ для параметра правил сортировки, а значение — допустимое значение для этого параметра. Для логических параметров -ключ может быть указан без соответствующего -значения, что подразумевает значение true.
Например, языковая метка en-US-u-kn-ks-level2 означает локаль с английским языком в регионе США с параметрами правил сортировки kn и ks, имеющими значения true и 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, если ваша операционная система поддерживает это.
Проверьте, действительно ли PostgreSQL использует локаль, которую вы подразумеваете. Параметры LC_COLLATE и LC_CTYPE определяются при создании базы данных, и не могут быть изменены, за исключением случаев, когда создаётся новая база данных. Прочие параметры локали, включая LC_MESSAGES и LC_MONETARY первоначально определены средой, в которой запускается сервер, но могут быть оперативно изменены. Вы можете проверить текущие параметры локали с помощью команды SHOW.
Каталог src/test/locale в комплекте файлов исходного кода содержит пакет тестов для поддержки локализации PostgreSQL.
Клиентские приложения, которые обрабатывают ошибки сервера, разбирая текст сообщения об ошибке, очевидно, столкнутся с проблемами, когда сообщения сервера будут на другом языке. Авторам таких приложений рекомендуется пользоваться системой кодов ошибок в качестве альтернативы.
Для поддержки наборов переводов сообщений требуется постоянная работа большого числа волонтёров, которые хотят, чтобы в PostgreSQL правильно использовался предпочитаемый ими язык. Если в настоящее время сообщения на вашем языке недоступны или переведены не полностью, будем благодарны вам за содействие. Если вы хотите помочь, обратитесь к Главе 55 или напишите на адрес рассылки разработчиков.