Поддержка кодировок#

Поддержка наборов символов в PostgreSQL позволяет хранить текст в различных кодировках, включая однобайтовые (например, серии ISO 8859) и многобайтовые (EUC, UTF-8, внутренний код Mule). Все поддерживаемые кодировки прозрачно работают с клиентами, но не все подходят для внутреннего использования на сервере. Кодировка по умолчанию задается при инициализации кластера PostgreSQL с помощью initdb, но ее можно переопределить при создании базы данных, позволяя иметь несколько баз с разной кодировкой.

Важное ограничение: кодировка каждой базы данных должна быть совместима с локалью LC_CTYPE (классификация символов) и LC_COLLATE (сортировка строк). Для локалей C или POSIX подходит любая кодировка, но для других локалей libc подходит только одна конкретная кодировка. В Windows кодировка UTF-8 совместима с любой локалью. Если включена поддержка ICU, локали ICU совместимы с большинством, но не со всеми кодировками сервера.

Поддерживаемые наборы символов#

В таблице ниже показаны наборы символов, доступные для использования в PostgreSQL.

Наборы символов PostgreSQL:

Не все клиентские API поддерживают полный перечень заявленных кодировок. Например, драйвер PostgreSQL JDBC не поддерживает кодировки MULE_INTERNAL, LATIN6, LATIN8 и LATIN10.

Особенностью кодировки SQL_ASCII является ее особое поведение. При выборе серверной кодировки SQL_ASCII сервер интерпретирует байты от 0 до 127 как символы ASCII, а байты от 128 до 255 не интерпретирует вовсе. При использовании SQL_ASCII преобразование кодировок не выполняется. Фактически, эта настройка означает, что реальная кодировка неизвестна, а не задает конкретную кодировку. Чаще всего, если в данных содержатся символы, отличные от ASCII, использовать SQL_ASCII неэффективно, так как PostgreSQL не сможет оказывать помощь в преобразовании или проверке не-ASCII-символов.

Установка набора символов#

Инструмент initdb устанавливает набор символов (кодировку) по умолчанию для кластера PostgreSQL. Например:

initdb -E EUC_JP

определяет набор символов по умолчанию как EUC_JP (расширенный юникод-код для японского языка). Альтернативно можно использовать длинную форму параметра --encoding.

Если не указаны параметры -E или --encoding, initdb автоматически выберет подходящую кодировку на основе текущей локали.

При создании базы данных можно указать другую кодировку, если она совместима с выбранной локалью:

createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean

Или эквивалентная команда SQL:

CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;

Эти команды создают базу данных с именем korean, использующую кодировку EUC_KR и локаль ko_KR. Обратите внимание, что здесь указано копирование из базы данных template0. При копировании любой другой базы данных параметры кодировки и локали должны совпадать с оригиналом, иначе это приведет к повреждению данных.

Кодировка базы данных хранится в системном каталоге pg_database. Просмотреть ее можно с помощью команды psql -l или метакоманды \l.

$ psql -l
                                         List of databases
   Name    |  Owner   | Encoding  |  Collation  |    Ctype    |          Access Privileges
-----------+----------+-----------+-------------+-------------+-------------------------------------
 clocaledb | hlinnaka | SQL_ASCII | C           | C           |
 englishdb | hlinnaka | UTF8      | en_GB.UTF8  | en_GB.UTF8  |
 japanese  | hlinnaka | UTF8      | ja_JP.UTF8  | ja_JP.UTF8  |
 korean    | hlinnaka | EUC_KR    | ko_KR.euckr | ko_KR.euckr |
 postgres  | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  |
 template0 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
 template1 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)

Важно#

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

PostgreSQL позволяет суперпользователям создавать базы данных с кодировкой SQL_ASCII, даже если локаль LC_CTYPE не равна C или POSIX. Как уже говорилось, SQL_ASCII не гарантирует соблюдение конкретной кодировки хранимых данных, что увеличивает вероятность возникновения проблем, связанных с локализацией. Использование такого сочетания считается устаревшим и в будущем может быть запрещено.

Автоматическое преобразование набора символов между сервером и клиентом#

PostgreSQL поддерживает автоматическое преобразование наборов символов между сервером и клиентом для многих комбинаций кодировок (см. раздел Доступные преобразования набора символов для списка поддерживаемых преобразований).

Чтобы активировать автоматическое преобразование кодировок, необходимо указать PostgreSQL желаемую кодировку клиентского приложения. Это можно сделать несколькими способами:

• Через команду \encoding в интерактивной оболочке psql. Например, для изменения кодировки на SJIS выполните:

  \encoding SJIS
  

• С помощью функций библиотеки libpq (см. раздел Функции управления) для управления кодировкой клиента.

• Путем использования команды SQL SET client_encoding TO. Например, для установки кодировки клиента на UTF8 выполните:

  SET client_encoding TO 'UTF8';
  

  SET CLIENT_ENCODING TO 'value';
  

  Можно использовать стандартную синтаксис SQL SET NAMES для этой цели:

  SET NAMES 'value';
  

  Чтобы запросить текущую кодировку клиента:

  SHOW client_encoding;
  

  Чтобы вернуться к кодировке по умолчанию:

  RESET client_encoding;
  

• Использование переменной окружения PGCLIENTENCODING. Если переменная окружения PGCLIENTENCODING задана в клиентской среде, то при подключении к серверу автоматически выбирается соответствующая клиентская кодировка. (Позже это можно переопределить другими способами, описанными выше.)

• Использование переменной конфигурации client_encoding. Если переменная client_encoding задана, то при подключении автоматически выбирается нужная клиентская кодировка. (Она также может быть переопределена другими методами, упомянутыми выше.)

Если невозможно преобразовать определенный символ — например, при использовании кодировки сервера EUC_JP и клиентской кодировки LATIN1, где некоторые японские символы не имеют аналогов в LATIN1 — выдается ошибка.

Если клиентская кодировка задана как SQL_ASCII, то преобразование кодировок отключается независимо от серверной кодировки. (Впрочем, если серверная кодировка не SQL_ASCII, сервер все равно проверяет, корректны ли поступающие данные для данной кодировки, поэтому общий эффект аналогичен случаю, когда клиентская и серверная кодировки совпадают.) Использование SQL_ASCII не оправдано, если работа ведется исключительно с данными в формате ASCII.

Доступные преобразования набора символов#

PostgreSQL позволяет выполнять преобразование между любыми двумя наборами символов, для которых существует соответствующая функция в системном каталоге pg_conversion. Postgres поставляется с некоторым количеством предопределенных преобразований, кратко описанных в таблице «Встроенные преобразования набора символов клиент/сервер» и подробно представленных в таблице «Все встроенные преобразования наборов символов». Добавить новое преобразование можно с помощью команды SQL CREATE CONVERSION. (Чтобы использовать преобразование автоматически при обмене данными между клиентом и сервером, оно должно быть отмечено как «по умолчанию» для данной пары наборов символов.)

Встроенные преобразования набора символов клиент/сервер:

Все встроенные преобразования наборов символов:

Имена преобразования следуют стандартной схеме именования: официальное название исходной кодировки со всеми неалфавитно-цифровыми символами, замененными подчеркиваниями, за которыми следует _to_, а затем аналогично обработанное имя целевой кодировки. Поэтому эти имена иногда отклоняются от обычных имен кодировок, показанных в таблице «Наборы символов PostgreSQL».

Дополнительная литература#

Эти материалы помогут разобраться в различных системах кодирования:

• Обработка информации CJKV: вычисления на китайском, японском, корейском и вьетнамском языках

  Книга подробно объясняет стандарты кодирования EUC_JP, EUC_CN, EUC_KR, EUC_TW.

• Веб-сайт консорциума Юникод

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

• RFC 3629

  Документ, определяющий формат UTF-8 (8-битное представление Юникода).