Смена кодировки postgresql ubuntu
Важным ограничением, однако, является то, что кодировка каждой базы данных должна быть совместима с параметрами локали базы данных 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 badges2 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. Дополнительные источники информации
Рекомендуемые источники для начала изучения различных видов систем кодирования.
Читайте также: