- Призрак Басенджи
- 27 августа 2018 г.
- PostgreSQL. Кириллица в psql под Windows
- Описание проблемы
- Решение проблемы
- Конкретные действия
- Очень быстро и просто
- Быстро и просто
- Посложнее и подольше
- PostgreSQL — Кириллица в psql под Windows
- Содержание
- Описание проблемы
- Решение проблемы
- Конкретные действия
- Супер быстро и просто
- Быстро и просто
- Посложнее и подольше
- Кодовая страница консоли 866 отличается от основной страницы windows 1251 postgresql
- Кодовая страница консоли 866 отличается от основной страницы windows 1251 postgresql
- 22.3.1. Поддерживаемые кодировки
- 22.3.2. Настройка кодировки
- Важно
- 22.3.3. Автоматическая перекодировка между сервером и клиентом
- 22.3.4. Дополнительные источники информации
Призрак Басенджи
Записки начинающего программиста.
27 августа 2018 г.
PostgreSQL. Кириллица в psql под Windows
В статье речь идет о том, как добиться корректного вывода кириллицы в консоли Windows – cmd.exe.
Описание проблемы
Решение проблемы
Конкретные действия
Очень быстро и просто
psql -d ТвояБД -U ТвойЛогин
psql \! chcp 1251
Быстро и просто
Запускаем cmd.exe, оттуда psql:
psql -d ТвояБД -U ТвойЛогин
Вводим пароль (если установлен) и выполняем следующую команду:
И все. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Посложнее и подольше
В ответ выведет:
Текущая кодовая страница: 1251
psql -d ТвояБД -U ТвойЛогин
Кстати, обратим внимание – теперь предупреждения о несовпадении кодировок нет.
Вот и все, теперь кириллица будет нормально отображаться.
Проверяем:
PostgreSQL — Кириллица в psql под Windows
В статье пойдёт речь о том, как добиться корректного вывода кириллицы в «консоли» Windows ( cmd.exe ).
Содержание
Описание проблемы
В дистрибутив PostgreSQL, помимо всего прочего, для работы с СУБД входит:
- приложение с графическим интерфейсом pgAdmin ;
- консольная утилита psql .
При работе с psql в среде Windows пользователи всегда довольно часто сталкиваются с проблемой вывода кириллицы. Например, при отображении результатов запроса к таблице, в полях которых хранятся строковые данные на русском языке.
Ну и зачем тогда работать с psql , кому нужно долбить клавиатурой в консольке, когда можно всё сделать красиво и быстро в pgAdmin ? Ну, не всегда pgAdmin доступен, особенно если речь идёт об удалённой машине. Кроме того, выполнение SQL-запросов в текстовом режиме консоли — это +10 к хакирству.
Решение проблемы
- MS Windows 7 SP1 x64;
- PostgreSQL 8.4.12 x32.
На сервере имеется БД, созданная в кодировке UTF8.
Суть проблемы в том, что cmd.exe работает (и так будет до скончания времён) в кодировке CP866 , а сама Windows — в WIN1251 , о чём psql предупреждает при начале работы:
Значит, надо как-то добиться, чтобы кодировка была одна.
В разных источниках встречаются разные рецепты, включая правку реестра и подмену файлов в системных папках Windows. Ничего этого делать не нужно, достаточно всего трёх шагов:
- сменить шрифт у cmd.exe ;
- сменить текущую кодовую страницу cmd.exe ;
- сменить кодировку на стороне клиента в psql .
Конкретные действия
Супер быстро и просто
Запускаете cmd.exe , оттуда psql :
Быстро и просто
Запускаете cmd.exe , оттуда psql :
Вводите пароль (если установлен) и выполняете команду:
И всё. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Потому предлагаем ещё способ, который этого недостатка лишён.
Посложнее и подольше
Запустить cmd.exe , нажать мышью в правом левом верхнем углу окна, там Свойства — Шрифт — выбрать Lucida Console. Нажать ОК.
В ответ выведет:
Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.
Всё, теперь кириллица будет нормально отображаться.
Кодовая страница консоли 866 отличается от основной страницы windows 1251 postgresql
lc_collate: ru1251
lc_ctype: ru1251
lc_messages: ru1251
lc_monetary: ru1251
lc_numeric: ru1251
lc_time: ru1251
server_encoding: utf8
�� ����� pgsql ���� �������:
https://www.postgresql.org/docs/9.6/static/multibyte.html
An important restriction, however, is that each database’s character set must be compatible with the database’s LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings. For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. (On Windows, however, UTF-8 encoding can be used with any locale.)
�������!
 Re: ������� Windows — Linix, �������� � ���������� cp1251-utf8 [new] | |
| Melkij Member server_encoding ������ ��������, ��� �������-�� � ������������ utf8. �� � ���������� ���� ��������� � linux �����. | |
| 26 ��� 18, 20:50����[21606109] �������� | ���������� �������� ���������� | |
| Re: ������� Windows — Linix, �������� � ���������� cp1251-utf8 [new] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ����� ������� Member ������: | Melkij, select datname, datcollate, datctype from pg_database ; SELECT name, setting FROM pg_settings WHERE category Кодовая страница консоли 866 отличается от основной страницы windows 1251 postgresqlВажным ограничением, однако, является то, что кодировка каждой базы данных должна быть совместима с параметрами локали базы данных LC_CTYPE (классификация символов) и LC_COLLATE (порядок сортировки строк). Для локали C или POSIX подойдёт любой набор символов, но для других локалей есть только одна кодировка, которая будет работать правильно. (Однако, в среде Windows кодировка UTF-8 может использоваться с любой локалью.) 22.3.1. Поддерживаемые кодировкиТаблица 22.1 показывает кодировки, доступные для использования в Postgres Pro . Таблица 22.1. Кодировки Postgres Pro
Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII , сервер интерпретирует значения от 0 до 127 байт согласно кодировке ASCII, тогда как значения от 128 до 255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII . Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII , так как Postgres Pro не сможет преобразовать или проверить символы, отличные от ASCII. 22.3.2. Настройка кодировкиinitdb определяет кодировку по умолчанию для кластера Postgres Pro . Например, настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать —encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или —encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали. При создании базы данных можно указать кодировку, отличную от заданной по умолчанию, если эта кодировка совместима с выбранной локалью: Это создаст базу данных с именем korean , которая использует кодировку EUC_KR и локаль ko_KR . Также, получить желаемый результат можно с помощью данной SQL-команды: Заметьте, что приведённые выше команды задают копирование базы данных template0 . При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 21.3. Кодировка базы данных хранится в системном каталоге pg_database . Её можно увидеть при помощи параметра psql -l или команды \l . ВажноНа большинстве современных операционных систем Postgres Pro может определить, какая кодировка подразумевается параметром LC_CTYPE , что обеспечит использование только соответствующей кодировки базы данных. На более старых системах необходимо самостоятельно следить за тем, чтобы использовалась кодировка, соответствующая выбранной языковой среде. Ошибка в этой области, скорее всего, приведёт к странному поведению зависимых от локали операций, таких как сортировка. Postgres Pro позволит суперпользователям создавать базы данных с кодировкой SQL_ASCII , даже когда значение LC_CTYPE не установлено в C или POSIX . Как было сказано выше, SQL_ASCII не гарантирует, что данные, хранящиеся в базе, имеют определённую кодировку, и таким образом, этот выбор чреват сбоями, связанными с локалью. Использование данной комбинации устарело и, возможно, будет полностью запрещено. 22.3.3. Автоматическая перекодировка между сервером и клиентомPostgres Pro поддерживает автоматическую перекодировку между сервером и клиентом для определённых комбинаций кодировок. Информация, касающаяся перекодировки, хранится в системном каталоге pg_conversion . Postgres Pro включает в себя некоторые предопределённые кодировки, как показано в Таблице 22.2. Есть возможность создать новую перекодировку при помощи SQL-команды CREATE CONVERSION . Таблица 22.2. Клиент-серверные перекодировки наборов символов
Чтобы включить автоматическую перекодировку символов, необходимо сообщить Postgres Pro кодировку, которую вы хотели бы использовать на стороне клиента. Это можно выполнить несколькими способами: Использование команды \encoding в psql . \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS , введите: libpq (Раздел 31.10) имеет функции, для управления клиентской кодировкой. Использование SET client_encoding TO . Клиентская кодировка устанавливается следующей SQL-командой: Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES : Получить текущую клиентскую кодировку: Вернуть кодировку по умолчанию: Использование PGCLIENTENCODING . Если установлена переменная окружения PGCLIENTENCODING , то эта клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.) Использование переменной конфигурации client_encoding. Если задана переменная client_encoding , указанная клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.) Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1 ), возникает ошибка. Если клиентская кодировка определена как SQL_ASCII , перекодировка отключается вне зависимости от кодировки сервера. Что же касается сервера, не стоит использовать SQL_ASCII , если только вы не работаете с данными, которые полностью соответствуют ASCII. 22.3.4. Дополнительные источники информацииРекомендуемые источники для начала изучения различных видов систем кодирования.  концепция памяти в linux. дефрагментация памяти. здравствуйте все! detector | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
