Смена кодировки postgresql ubuntu

Обновлено: 02.07.2024

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

23.3.1. Поддерживаемые кодировки

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

Таблица 23.1. Кодировки PostgreSQL

Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII , сервер интерпретирует значения от 0 до 127 байт согласно кодировке ASCII, тогда как значения от 128 до 255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII . Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII , так как PostgreSQL не сможет преобразовать или проверить символы, отличные от ASCII.

23.3.2. Настройка кодировки

initdb определяет кодировку по умолчанию для кластера PostgreSQL . Например,

настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать --encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или --encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали.

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

Это создаст базу данных с именем korean , которая использует кодировку EUC_KR и локаль ko_KR . Также, получить желаемый результат можно с помощью данной SQL-команды:

Заметьте, что приведённые выше команды задают копирование базы данных template0 . При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 22.3.

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

Важно

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

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

23.3.3. Автоматическая перекодировка между сервером и клиентом

PostgreSQL поддерживает автоматическую перекодировку между сервером и клиентом для определённых комбинаций кодировок. Информация, касающаяся перекодировки, хранится в системном каталоге pg_conversion . PostgreSQL включает в себя некоторые предопределённые кодировки, как показано в Таблице 23.2. Есть возможность создать новую перекодировку при помощи SQL-команды CREATE CONVERSION .

Таблица 23.2. Клиент-серверные перекодировки наборов символов

Серверная кодировкаДоступные клиентские кодировки
BIG5 не поддерживается как серверная кодировка
EUC_CN EUC_CN , MULE_INTERNAL , UTF8
EUC_JP EUC_JP , MULE_INTERNAL , SJIS , UTF8
EUC_JIS_2004 EUC_JIS_2004 , SHIFT_JIS_2004 , UTF8
EUC_KR EUC_KR , MULE_INTERNAL , UTF8
EUC_TW EUC_TW , BIG5 , MULE_INTERNAL , UTF8
GB18030 не поддерживается как серверная кодировка
GBK не поддерживается как серверная кодировка
ISO_8859_5 ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
ISO_8859_6 ISO_8859_6 , UTF8
ISO_8859_7 ISO_8859_7 , UTF8
ISO_8859_8 ISO_8859_8 , UTF8
JOHAB не поддерживается как серверная кодировка
KOI8R KOI8R , ISO_8859_5 , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
KOI8U KOI8U , UTF8
LATIN1 LATIN1 , MULE_INTERNAL , UTF8
LATIN2 LATIN2 , MULE_INTERNAL , UTF8 , WIN1250
LATIN3 LATIN3 , MULE_INTERNAL , UTF8
LATIN4 LATIN4 , MULE_INTERNAL , UTF8
LATIN5 LATIN5 , UTF8
LATIN6 LATIN6 , UTF8
LATIN7 LATIN7 , UTF8
LATIN8 LATIN8 , UTF8
LATIN9 LATIN9 , UTF8
LATIN10 LATIN10 , UTF8
MULE_INTERNAL MULE_INTERNAL , BIG5 , EUC_CN , EUC_JP , EUC_KR , EUC_TW , ISO_8859_5 , KOI8R , LATIN1 to LATIN4 , SJIS , WIN866 , WIN1250 , WIN1251
SJIS не поддерживается как серверная кодировка
SHIFT_JIS_2004 не поддерживается как серверная кодировка
SQL_ASCII любая (перекодировка не будет выполнена)
UHC не поддерживается как серверная кодировка
UTF8 все поддерживаемые кодировки
WIN866 WIN866 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN1251
WIN874 WIN874 , UTF8
WIN1250 WIN1250 , LATIN2 , MULE_INTERNAL , UTF8
WIN1251 WIN1251 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866
WIN1252 WIN1252 , UTF8
WIN1253 WIN1253 , UTF8
WIN1254 WIN1254 , UTF8
WIN1255 WIN1255 , UTF8
WIN1256 WIN1256 , UTF8
WIN1257 WIN1257 , UTF8
WIN1258 WIN1258 , UTF8

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

Использование команды \encoding в psql . \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS , введите:

libpq (Раздел 33.10) имеет функции, для управления клиентской кодировкой.

Использование SET client_encoding TO . Клиентская кодировка устанавливается следующей SQL-командой:

Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES :

Получить текущую клиентскую кодировку:

Вернуть кодировку по умолчанию:

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

Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1 ), возникает ошибка.

Если клиентская кодировка определена как SQL_ASCII , перекодировка отключается вне зависимости от кодировки сервера. Что же касается сервера, не стоит использовать SQL_ASCII , если только вы не работаете с данными, которые полностью соответствуют ASCII.

23.3.4. Дополнительные источники информации

Рекомендуемые источники для начала изучения различных видов систем кодирования.

I'm trying to change the default value for the client_encoding configuration variable for a PostgreSQL database I'm running. I want it to be UTF8 , but currently it's getting set to LATIN1 .

The database is already set to use UTF8 encoding:

Which according to the docs should already result in the client using UTF8 as its default client_encoding (emphasis mine):

client_encoding (string)

Sets the client-side encoding (character set). The default is to use the database encoding.

I even tried using ALTER USER <user> SET . to change the default config for the user I'm logging in as:

But that also had no effect:

There's nothing in any of the PSQL files on my system:

I'm running PosgreSQL 9.1:

4,321 11 11 gold badges 50 50 silver badges 73 73 bronze badges 38.8k 19 19 gold badges 121 121 silver badges 161 161 bronze badges

2 Answers 2

Okay, so first things first: why isn't setting the user or database encoding having any effect?

Turns out it's because of this line from the psql documentation:

If at least one of standard input or standard output are a terminal, then psql sets the client encoding to "auto", which will detect the appropriate client encoding from the locale settings (LC_CTYPE environment variable on Unix systems). If this doesn't work out as expected, the client encoding can be overridden using the environment variable PGCLIENTENCODING.

So, in fact, your previous configuration changes actually have been working, just not in the interactive psql console. Try the following command:

You should see that the client encoding is actually UTF8:

Now run the command again, but without piping it to cat :

You should get the result:

So basically, psql is only using LATIN1 encoding for commands involving the terminal.

How can you fix this? Well, there are a few possible ways.

One would be to do as the docs suggest and set the PGCLIENTENCODING environment variable to UTF8 somewhere persistent, such as

/.bashrc to affect only your user, or /etc/environment to affect the whole system (see How to permanently set environmental variables).

Another option would be to configure your system locale settings to use en_US.utf8 instead of en_US (or equivalent). The method for doing this may vary depending on your system, but usually you can do it by modifying

/.config/locale.conf (your user only) or /etc/default/locale or /etc/locale.conf (system-wide). This will affect more than just postgres, and I believe more closely addresses the root of the problem. You can check your current locale settings by running locale .

One other solution would be to update your psqlrc file to include SET client_encoding=UTF8; . That file is located at

/.psqlrc (your user only) or /etc/psqlrc (system-wide). Note that this method won't affect the result of the command we were using to the client encoding earlier, since the docs state (emphasis mine):

--command=command

Specifies that psql is to execute one command string, command, and then exit. This is useful in shell scripts. Start-up files ( psqlrc and

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

23.3.1. Поддерживаемые кодировки

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

Таблица 23.1. Кодировки PostgreSQL

Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII , сервер интерпретирует значения от 0 до 127 байт согласно кодировке ASCII, тогда как значения от 128 до 255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII . Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII , так как PostgreSQL не сможет преобразовать или проверить символы, отличные от ASCII.

23.3.2. Настройка кодировки

initdb определяет кодировку по умолчанию для кластера PostgreSQL . Например,

настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать --encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или --encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали.

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

Это создаст базу данных с именем korean , которая использует кодировку EUC_KR и локаль ko_KR . Также, получить желаемый результат можно с помощью данной SQL-команды:

Заметьте, что приведённые выше команды задают копирование базы данных template0 . При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 22.3.

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

Важно

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

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

23.3.3. Автоматическая перекодировка между сервером и клиентом

PostgreSQL поддерживает автоматическую перекодировку между сервером и клиентом для определённых комбинаций кодировок. Информация, касающаяся перекодировки, хранится в системном каталоге pg_conversion . PostgreSQL включает в себя некоторые предопределённые кодировки, как показано в Таблице 23.2. Есть возможность создать новую перекодировку при помощи SQL-команды CREATE CONVERSION .

Таблица 23.2. Клиент-серверные перекодировки наборов символов

Серверная кодировкаДоступные клиентские кодировки
BIG5 не поддерживается как серверная кодировка
EUC_CN EUC_CN , MULE_INTERNAL , UTF8
EUC_JP EUC_JP , MULE_INTERNAL , SJIS , UTF8
EUC_JIS_2004 EUC_JIS_2004 , SHIFT_JIS_2004 , UTF8
EUC_KR EUC_KR , MULE_INTERNAL , UTF8
EUC_TW EUC_TW , BIG5 , MULE_INTERNAL , UTF8
GB18030 не поддерживается как серверная кодировка
GBK не поддерживается как серверная кодировка
ISO_8859_5 ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
ISO_8859_6 ISO_8859_6 , UTF8
ISO_8859_7 ISO_8859_7 , UTF8
ISO_8859_8 ISO_8859_8 , UTF8
JOHAB не поддерживается как серверная кодировка
KOI8R KOI8R , ISO_8859_5 , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
KOI8U KOI8U , UTF8
LATIN1 LATIN1 , MULE_INTERNAL , UTF8
LATIN2 LATIN2 , MULE_INTERNAL , UTF8 , WIN1250
LATIN3 LATIN3 , MULE_INTERNAL , UTF8
LATIN4 LATIN4 , MULE_INTERNAL , UTF8
LATIN5 LATIN5 , UTF8
LATIN6 LATIN6 , UTF8
LATIN7 LATIN7 , UTF8
LATIN8 LATIN8 , UTF8
LATIN9 LATIN9 , UTF8
LATIN10 LATIN10 , UTF8
MULE_INTERNAL MULE_INTERNAL , BIG5 , EUC_CN , EUC_JP , EUC_KR , EUC_TW , ISO_8859_5 , KOI8R , LATIN1 to LATIN4 , SJIS , WIN866 , WIN1250 , WIN1251
SJIS не поддерживается как серверная кодировка
SHIFT_JIS_2004 не поддерживается как серверная кодировка
SQL_ASCII любая (перекодировка не будет выполнена)
UHC не поддерживается как серверная кодировка
UTF8 все поддерживаемые кодировки
WIN866 WIN866 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN1251
WIN874 WIN874 , UTF8
WIN1250 WIN1250 , LATIN2 , MULE_INTERNAL , UTF8
WIN1251 WIN1251 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866
WIN1252 WIN1252 , UTF8
WIN1253 WIN1253 , UTF8
WIN1254 WIN1254 , UTF8
WIN1255 WIN1255 , UTF8
WIN1256 WIN1256 , UTF8
WIN1257 WIN1257 , UTF8
WIN1258 WIN1258 , UTF8

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

Использование команды \encoding в psql . \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS , введите:

libpq (Раздел 32.10) имеет функции, для управления клиентской кодировкой.

Использование SET client_encoding TO . Клиентская кодировка устанавливается следующей SQL-командой:

Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES :

Получить текущую клиентскую кодировку:

Вернуть кодировку по умолчанию:

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

Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1 ), возникает ошибка.

Если клиентская кодировка определена как SQL_ASCII , перекодировка отключается вне зависимости от кодировки сервера. Что же касается сервера, не стоит использовать SQL_ASCII , если только вы не работаете с данными, которые полностью соответствуют ASCII.

23.3.4. Дополнительные источники информации

Рекомендуемые источники для начала изучения различных видов систем кодирования.

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

23.3.1. Поддерживаемые кодировки

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

Таблица 23.1. Кодировки PostgreSQL

Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII , сервер интерпретирует байтовые значения 0–127 согласно кодировке ASCII, тогда как значения 128–255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII . Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII , так как PostgreSQL не сможет преобразовать или проверить символы, отличные от ASCII.

23.3.2. Настройка кодировки

initdb определяет кодировку по умолчанию для кластера PostgreSQL . Например,

настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать --encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или --encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали.

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

Это создаст базу данных с именем korean , которая использует кодировку EUC_KR и локаль ko_KR . Также, получить желаемый результат можно с помощью данной SQL-команды:

Заметьте, что приведённые выше команды задают копирование базы данных template0 . При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 22.3.

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

Важно

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

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

23.3.3. Автоматическая перекодировка между сервером и клиентом

PostgreSQL поддерживает автоматическое перекодирование символов между сервером и клиентов для многих сочетаний кодировок (они перечисляются в Подразделе 23.3.4).

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

Использование команды \encoding в psql . \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS , введите:

libpq (Раздел 33.10) имеет функции, для управления клиентской кодировкой.

Использование SET client_encoding TO . Клиентская кодировка устанавливается следующей SQL-командой:

Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES :

Получить текущую клиентскую кодировку:

Вернуть кодировку по умолчанию:

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

Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1 ), возникает ошибка.

Если клиентская кодировка определена как SQL_ASCII , перекодировка отключается вне зависимости от кодировки сервера. (Однако если серверная кодировка отлична от SQL_ASCII , сервер будет тем не менее проверять, что входящие данные являются допустимыми для его кодировки; поэтому итоговый результат будет тем же, что и при совпадении клиентской кодировки с серверной.) На сервере же использовать кодировку SQL_ASCII неразумно, кроме случаев, когда все ваши данные полностью вписываются в ASCII.

23.3.4. Возможные перекодировки наборов символов

PostgreSQL поддерживает перекодирование между любыми двумя наборами символов, для которых в системном каталоге pg_conversion присутствует функция перекодирования. PostgreSQL включает несколько предопределённых перекодировок, сведённых в Таблице 23.2 и описанных подробнее в Таблице 23.3. Кроме этого, есть возможность создать новую перекодировку, используя SQL-команду CREATE CONVERSION . (Чтобы она использовалась для автоматического перекодирования текста между сервером и клиентом, она должна быть помечена как перекодировка « по умолчанию » для своей пары кодировок.)

Таблица 23.2. Встроенные клиент-серверные перекодировки наборов символов

Серверная кодировкаДоступные клиентские кодировки
BIG5 не поддерживается как серверная кодировка
EUC_CN EUC_CN , MULE_INTERNAL , UTF8
EUC_JP EUC_JP , MULE_INTERNAL , SJIS , UTF8
EUC_JIS_2004 EUC_JIS_2004 , SHIFT_JIS_2004 , UTF8
EUC_KR EUC_KR , MULE_INTERNAL , UTF8
EUC_TW EUC_TW , BIG5 , MULE_INTERNAL , UTF8
GB18030 не поддерживается как серверная кодировка
GBK не поддерживается как серверная кодировка
ISO_8859_5 ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
ISO_8859_6 ISO_8859_6 , UTF8
ISO_8859_7 ISO_8859_7 , UTF8
ISO_8859_8 ISO_8859_8 , UTF8
JOHAB не поддерживается как серверная кодировка
KOI8R KOI8R , ISO_8859_5 , MULE_INTERNAL , UTF8 , WIN866 , WIN1251
KOI8U KOI8U , UTF8
LATIN1 LATIN1 , MULE_INTERNAL , UTF8
LATIN2 LATIN2 , MULE_INTERNAL , UTF8 , WIN1250
LATIN3 LATIN3 , MULE_INTERNAL , UTF8
LATIN4 LATIN4 , MULE_INTERNAL , UTF8
LATIN5 LATIN5 , UTF8
LATIN6 LATIN6 , UTF8
LATIN7 LATIN7 , UTF8
LATIN8 LATIN8 , UTF8
LATIN9 LATIN9 , UTF8
LATIN10 LATIN10 , UTF8
MULE_INTERNAL MULE_INTERNAL , BIG5 , EUC_CN , EUC_JP , EUC_KR , EUC_TW , ISO_8859_5 , KOI8R , LATIN1 to LATIN4 , SJIS , WIN866 , WIN1250 , WIN1251
SJIS не поддерживается как серверная кодировка
SHIFT_JIS_2004 не поддерживается как серверная кодировка
SQL_ASCII любая (перекодировка не будет выполнена)
UHC не поддерживается как серверная кодировка
UTF8 все поддерживаемые кодировки
WIN866 WIN866 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN1251
WIN874 WIN874 , UTF8
WIN1250 WIN1250 , LATIN2 , MULE_INTERNAL , UTF8
WIN1251 WIN1251 , ISO_8859_5 , KOI8R , MULE_INTERNAL , UTF8 , WIN866
WIN1252 WIN1252 , UTF8
WIN1253 WIN1253 , UTF8
WIN1254 WIN1254 , UTF8
WIN1255 WIN1255 , UTF8
WIN1256 WIN1256 , UTF8
WIN1257 WIN1257 , UTF8
WIN1258 WIN1258 , UTF8

Таблица 23.3. Все встроенные перекодировки наборов символов

[a] Имена преобразований следуют стандартной схеме именования. К официальному названию исходной кодировки, в котором все не алфавитно-цифровые символы заменяются подчёркиваниями, добавляется _to_ , а за ним аналогично подготовленное имя целевой кодировки. Таким образом, эти имена иногда не совпадают буквально с общепринятыми названиями, показанными в Таблице 23.1.

23.3.5. Дополнительные источники информации

Рекомендуемые источники для начала изучения различных видов систем кодирования.

Читайте также: