Материал из Кафедра ИУ5 МГТУ им. Н.Э.Баумана — студенческое сообщество
В статье пойдёт речь о том, как добиться корректного вывода кириллицы в «консоли» Windows (cmd.exe
).
Содержание
- 1 Описание проблемы
- 2 Решение проблемы
- 2.1 Суть
- 2.2 Конкретные действия
- 2.2.1 Супер быстро и просто
- 2.2.2 Быстро и просто
- 2.2.3 Посложнее и подольше
Описание проблемы
В дистрибутив 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
предупреждает при начале работы:
WARNING: Console code page (866) differs from Windows code page (1251) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details.
Значит, надо как-то добиться, чтобы кодировка была одна.
В разных источниках встречаются разные рецепты, включая правку реестра и подмену файлов в системных папках Windows. Ничего этого делать не нужно, достаточно всего трёх шагов:
- сменить шрифт у
cmd.exe
; - сменить текущую кодовую страницу
cmd.exe
; - сменить кодировку на стороне клиента в
psql
.
Конкретные действия
Супер быстро и просто
Запускаете cmd.exe
, оттуда psql
:
psql -d ВАШАБАЗА -U ВАШЛОГИН
Далее:
psql \! chcp 1251
Быстро и просто
Запускаете cmd.exe
, оттуда psql
:
psql -d ВАШАБАЗА -U ВАШЛОГИН
Вводите пароль (если установлен) и выполняете команду:
set client_encoding='WIN866';
И всё. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Потому предлагаем ещё способ, который этого недостатка лишён.
Посложнее и подольше
Запустить cmd.exe
, нажать мышью в правом левом верхнем углу окна, там Свойства — Шрифт — выбрать Lucida Console. Нажать ОК.
Выполнить команду:
chcp 1251
В ответ выведет:
Текущая кодовая страница: 1251
Запустить psql
;
psql -d ВАШАБАЗА -U ВАШЛОГИН
Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.
Выполнить:
set client_encoding='win1251';
Он выведет:
SET
Всё, теперь кириллица будет нормально отображаться.
Проверяем:
Материал из Кафедра ИУ5 МГТУ им. Н.Э.Баумана — студенческое сообщество
В статье пойдёт речь о том, как добиться корректного вывода кириллицы в «консоли» Windows (cmd.exe
).
Содержание
- 1 Описание проблемы
- 2 Решение проблемы
- 2.1 Суть
- 2.2 Конкретные действия
- 2.2.1 Супер быстро и просто
- 2.2.2 Быстро и просто
- 2.2.3 Посложнее и подольше
Описание проблемы
В дистрибутив 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
предупреждает при начале работы:
WARNING: Console code page (866) differs from Windows code page (1251) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details.
Значит, надо как-то добиться, чтобы кодировка была одна.
В разных источниках встречаются разные рецепты, включая правку реестра и подмену файлов в системных папках Windows. Ничего этого делать не нужно, достаточно всего трёх шагов:
- сменить шрифт у
cmd.exe
; - сменить текущую кодовую страницу
cmd.exe
; - сменить кодировку на стороне клиента в
psql
.
Конкретные действия
Супер быстро и просто
Запускаете cmd.exe
, оттуда psql
:
psql -d ВАШАБАЗА -U ВАШЛОГИН
Далее:
psql ! chcp 1251
Быстро и просто
Запускаете cmd.exe
, оттуда psql
:
psql -d ВАШАБАЗА -U ВАШЛОГИН
Вводите пароль (если установлен) и выполняете команду:
set client_encoding='WIN866';
И всё. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Потому предлагаем ещё способ, который этого недостатка лишён.
Посложнее и подольше
Запустить cmd.exe
, нажать мышью в правом левом верхнем углу окна, там Свойства — Шрифт — выбрать Lucida Console. Нажать ОК.
Выполнить команду:
chcp 1251
В ответ выведет:
Текущая кодовая страница: 1251
Запустить psql
;
psql -d ВАШАБАЗА -U ВАШЛОГИН
Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.
Выполнить:
set client_encoding='win1251';
Он выведет:
SET
Всё, теперь кириллица будет нормально отображаться.
Проверяем:
Ошибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:
Столь же скупа и информация для технической поддержки:
Обычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.
К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас — может скачать ее по ссылке с Инфостарта)
1:Tools (Зеркало на Инфостарте)
MD5: 448277422B59EFA426CC51E4F3A52F53
В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С — это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД — это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.
Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.
В зависимости от того, какая именно часть конфигурации ИБ оказалась повреждена база может не загружаться в обычном режиме, но загружаться в Конфигуратор, либо вообще не загружаться никак. Если доступен режим конфигуратора, то можно попробовать снять базу с поддержки и загрузить в нее исправную конфигурацию из файла, в некоторых случаях это приведет к успеху, в других может потребоваться сначала выявить и удалить сбойный элемент метаданных.
Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.
Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:
sudo -s
su postgres
Если утилита sudo не установлена (такой вариант может быть в Debian), то:
su -
su postgres
В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором — от учетной записи суперпользователя (root).
Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:
psql -l
В Windows вам потребуется ввести пароль пользователя postgres.
Выяснив имя необходимой базы данных выгрузим ее дамп командой:
#Linux
pg_dump basename > ~/basename.psql#Windows
pg_dump basename > D:backupbasename.psql
Где basename — имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.
Для дальнейших действий нам потребуется развернуть на этом же сервере СУБД еще одну базу с точно такой же конфигурацией информационной базы, это может быть как старый бекап поврежденной базы, так и другая база такой же конфигурации, чистая установка или демо база. Главное, чтобы конфигурация новой базы с точностью до релиза совпадала с конфигурацией поврежденной.
После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:
psql
В Windows вы можете получить сообщение:
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
В этом случае выполните:
! chcp 1251
Теперь подключимся к исправной базе:
с newbasename
где newbasename — имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.
Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.
#Linux
COPY config TO '/var/lib/postgresql/config_OK.txt';#Windows
COPY config TO 'D:/backup/config_OK.txt';
Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.
Переподключимся к поврежденной базе:
с basename
На всякий случай, также сохраним содержимое таблицы config:
#Linux
COPY config TO '/var/lib/postgresql/config_ERR.txt';#Windows
COPY config TO 'D:/backup/config_ERR.txt';
После чего очистим сбойную таблицу:
DELETE FROM config;
И загрузим в нее данные из исправной информационной базы:
#Linux
COPY config FROM '/var/lib/postgresql/config_OK.txt';#Windows
COPY config FROM 'D:/backup/config_OK.txt';
Для выхода из терминала PostgreSQL введите:
q
Если все сделано правильно, то поврежденная конфигурация информационной базы будет заменена на исправную и ее работоспособность будет восстановлена.
В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:
DELETE FROM configsave;
Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Содержание
- PostgreSQL: Warning: Console code page (437) differs from Windows code page (1252)
- 13 Answers 13
- Содержание
- Описание проблемы
- Решение проблемы
- Конкретные действия
- Супер быстро и просто
- Быстро и просто
- Посложнее и подольше
- Призрак Басенджи
- 27 августа 2018 г.
- PostgreSQL. Кириллица в psql под Windows
- Описание проблемы
- Решение проблемы
- Конкретные действия
- Очень быстро и просто
- Быстро и просто
- Посложнее и подольше
- Warning console code page 866 differs from windows code page 1251
- Warning console code page 866 differs from windows code page 1251
- Можно: SET CLIENT_ENCODING TO
- Спасибо, но не помогло, это
- Не ту кодировку выбрали вот и
- Дело в том, что она не
- Так в psql надо команду
- Странно, может это все руки,
- Простите, а вы что не в
- Чтобы не создавать новую тему, добавлю вопрос сюда
- SET CLIENT_ENCODING
- Воспользуйтесь рекомендацией
PostgreSQL: Warning: Console code page (437) differs from Windows code page (1252)
Using PostgreSQL when I connect to a db using c testdb inside PostgreSQL Database SQL Prompt. I successfully connect to the db but getting the following warning:
What does this warning mean? How to resolve it?
13 Answers 13
psql is built as a «console application». Since the Windows console windows use a different encoding than the rest of the system, you must take special care when using 8-bit characters within psql. If psql detects a problematic console code page, it will warn you at startup.
To change the console code page, two things are necessary: Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code page that is appropriate for German; replace it with your value.) If you are using Cygwin, you can put this command in /etc/profile.
The default codepage for CMD.exe is different than the default for postgres. To change for CMD.exe using the REGISTRY try this:
Then reopen CMD.exe
To make it even more obvious, the file to which @user3423801 is adding the line
is in the scripts directory where you installed Postgre.
For example, in my case it is
Go to ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftCommand Processor
New a string value named: Autorun and change the value to be chcp 1252
Or you can simply type cmd.exe /c chcp 1252 in the Command Prompt window.
The answer of dvdgsng is correct but with code example is more obviously.
you just go to the power-shell or cmd.exe and type the command chcp 1252 or whatever the page number it wants «the one that is the windows code page». If the problem still persists, just open the console properties ‘By clicking the power shell icon on the top left of the console window and choosing properties from the drop-down menu’ and change the font to «Lucida Console». It worked for me, But you have to open power-shell as an Administrator.
Please don’t assume that Unix fixes work for Windows Users. For Windows 10, and PostgreSQL 12, combining the answers by «user3423801» and «numbers longer» worked for me. (The Windows Registry hack would not work. I did not try rebooting yet.) It is better to fix it in the PSQL startup script anyway.
After much digging for an answer that made sense to me, I found this help email chain at the PostgreSQL site which basically says to run chcp 1252 from inside an open command window. I was then able to run my PostgreSQL commands without the code warning.
NOTE: this change does not persist so you have to run it every time you open a new command window where you plan to use PostgreSQL commands.
I couldn’t figure out how to set it for Cygwin globally. This seemed to work though in my bash script
The answers above are okay, but don’t mention anywhere that Windows 1252 encoding is good for English language versions of Windows AND the other Western European Languages. This completes the answer for those people who may get confused about the aforementioned application to German language encoding. Yes it works for English without umlauts and other special characters needed for German, Spanish, French, Italian, Romanian, Hungarian, etc.
What is Windows 1252 encoding?
Windows-1252 or CP-1252 (code page 1252) is a single-byte character encoding of the Latin alphabet, used by default in the legacy components of Microsoft Windows for English and some other Western languages (other languages use different default encodings).
Источник
В статье пойдёт речь о том, как добиться корректного вывода кириллицы в «консоли» Windows ( cmd.exe ).
Содержание
Описание проблемы
В дистрибутив PostgreSQL, помимо всего прочего, для работы с СУБД входит:
При работе с psql в среде Windows пользователи всегда довольно часто сталкиваются с проблемой вывода кириллицы. Например, при отображении результатов запроса к таблице, в полях которых хранятся строковые данные на русском языке.
Решение проблемы
На сервере имеется БД, созданная в кодировке UTF8.
Значит, надо как-то добиться, чтобы кодировка была одна.
В разных источниках встречаются разные рецепты, включая правку реестра и подмену файлов в системных папках Windows. Ничего этого делать не нужно, достаточно всего трёх шагов:
Конкретные действия
Супер быстро и просто
Быстро и просто
Вводите пароль (если установлен) и выполняете команду:
И всё. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Потому предлагаем ещё способ, который этого недостатка лишён.
Посложнее и подольше
Всё, теперь кириллица будет нормально отображаться.
Источник
Призрак Басенджи
Записки начинающего программиста.
27 августа 2018 г.
PostgreSQL. Кириллица в psql под Windows
В статье речь идет о том, как добиться корректного вывода кириллицы в консоли Windows – cmd.exe.
Описание проблемы
Решение проблемы
Конкретные действия
Очень быстро и просто
Быстро и просто
Запускаем cmd.exe, оттуда psql:
Вводим пароль (если установлен) и выполняем следующую команду:
И все. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:
Посложнее и подольше
Текущая кодовая страница: 1251
Кстати, обратим внимание – теперь предупреждения о несовпадении кодировок нет.
Вот и все, теперь кириллица будет нормально отображаться.
Проверяем:
Источник
Warning console code page 866 differs from windows code page 1251
C:Program FilesPostgreSQL9.0bin>chcp 1251
������� ������� ��������: 1251
postgres=# select * from «Test»;
name
———-
РямчикЦЙ
John
(2 rows)
��� ������? 27 ��� 11, 18:05����[10576400] �������� | ���������� �������� ����������
Re: psql cmd Windows 7 select ������� ����� �� ����� ������������ [new] |
eye-cutter Member encoding win-1251 |
27 ��� 11, 18:26����[10576522] �������� | ���������� �������� ���������� |
Re: psql cmd Windows 7 select ������� ����� �� ����� ������������ [new] |
������� Member SET client_encoding=win866; |
28 ��� 11, 00:19����[10577825] �������� | ���������� �������� ���������� |
Re: psql cmd Windows 7 select ������� ����� �� ����� ������������ [new] |
Judo Member postgres=# encoding win-1251 postgres=# SET client_encoding=win866; Источник Warning console code page 866 differs from windows code page 1251Можно-ли как-нибудь поменять кодировку консоли ну или как-то это исправить, если причина в другом? Можно: SET CLIENT_ENCODING TOСпасибо, но не помогло, этоСпасибо, но не помогло, это уже пробовал) Все равно иероглифы вместо русских букв. Не ту кодировку выбрали вот иНе ту кодировку выбрали вот и всё. Всем помогает, вам нет? Дело в том, что она неДело в том, что она не меняется, как была 866, так и остается, может я куда-то не туда ввожу команду? (пробовал в саму консоль и в граф. интерфейсе, команда выполняется (за Так в psql надо командуТак в psql надо команду вводить, при чём здесь консоль? Странно, может это все руки,Странно, может это все руки, поступаю так: Запускаем PSQL Shell (psql), после ввода названия сервера, порта, БД, пользователя и пароля.. music1=# SET CLIENT_ENCODING TO ‘WIN1251’; Еще пробовал и менять строку #client_encoding = sql_ascii (в postgresql.conf) на #client_encoding = win1251 Простите, а вы что не вПростите, а вы что не в курсе, что консоль Windows работает в кодировке CP866? (кодировке DOS, а не Windows. Это из-за русских имён файлов сложилось по исторической причине) Чтобы не создавать новую тему, добавлю вопрос сюдаТак все таки, как сделать, чтобы в консоли psql были русские буквы? У мене не получается. По порядку рассказываю, что я делаю. 1. Система Windows XP. Кодирока консоли 866. 2. Во время инсталяции на вопрос про «Locale» я оставил [Default locale]. 3. Пробую войти в консоль psql. После ввода server, database, port, username, пароль я получаю: 4. Нашел этот «Notes for Windows users» (здесь), там вообще написано то, что вводить нужно не в консоль psql, а в виндовскую cmd: Set the code page by entering cmd.exe /c chcp 1252. Команда cmd.exe /c chcp 1252 явно не для консоли psql. Значит ответ из официального мануала в данном случае не решает проблему. 5. Прочитав эту ветку пробую сначала посмотреть какая кодировка стотит в psql изначально (я еще ничего не менял): Пробовал обратно ставить WIN1251, пробовал UTF8. Ничего не помогает, кракозябры и все. Что я делаю не так? Как его «русифицировать»? SET CLIENT_ENCODINGSET CLIENT_ENCODING устанавливает кодировку для вывода значений из БД, а не хелпа. Воспользуйтесь рекомендациейВоспользуйтесь рекомендацией «Set the code page by entering cmd.exe /c chcp 1252.» После этого запускаете psql. Источник Adblock |
����� �������
Member
������:
���������: 5
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
Имя | Описание | Язык | Поддержка на сервере | Байтов на символ | Псевдонимы |
---|---|---|---|---|---|
BIG5 | Big Five | Традиционные китайские иероглифы | Нет | 1-2 | WIN950 , Windows950 |
EUC_CN | Extended UNIX Code-CN | Упрощённые китайские иероглифы | Да | 1-3 | |
EUC_JP | Extended UNIX Code-JP | Японский | Да | 1-3 | |
EUC_JIS_2004 | Extended UNIX Code-JP, JIS X 0213 | Японский | Да | 1-3 | |
EUC_KR | Extended UNIX Code-KR | Корейский | Да | 1-3 | |
EUC_TW | Extended UNIX Code-TW | Традиционные китайские иероглифы, тайваньский | Да | 1-3 | |
GB18030 | Национальный стандарт | Китайский | Нет | 1-4 | |
GBK | Расширенный национальный стандарт | Упрощённые китайские иероглифы | Нет | 1-2 | WIN936 , Windows936 |
ISO_8859_5 | ISO 8859-5, ECMA 113 | Латинский/Кириллица | Да | 1 | |
ISO_8859_6 | ISO 8859-6, ECMA 114 | Латинский/Арабский | Да | 1 | |
ISO_8859_7 | ISO 8859-7, ECMA 118 | Латинский/Греческий | Да | 1 | |
ISO_8859_8 | ISO 8859-8, ECMA 121 | Латинский/Иврит | Да | 1 | |
JOHAB | JOHAB | Корейский (Хангыль) | Нет | 1-3 | |
KOI8R | KOI 8-R | Кириллица (Русский) | Да | 1 | KOI8 |
KOI8U | KOI 8-U | Кириллица (Украинский) | Да | 1 | |
LATIN1 | ISO 8859-1, ECMA 94 | Западноевропейские | Да | 1 | ISO88591 |
LATIN2 | ISO 8859-2, ECMA 94 | Центральноевропейские | Да | 1 | ISO88592 |
LATIN3 | ISO 8859-3, ECMA 94 | Южноевропейские | Да | 1 | ISO88593 |
LATIN4 | ISO 8859-4, ECMA 94 | Североевропейские | Да | 1 | ISO88594 |
LATIN5 | ISO 8859-9, ECMA 128 | Турецкий | Да | 1 | ISO88599 |
LATIN6 | ISO 8859-10, ECMA 144 | Скандинавские | Да | 1 | ISO885910 |
LATIN7 | ISO 8859-13 | Балтийские | Да | 1 | ISO885913 |
LATIN8 | ISO 8859-14 | Кельтские | Да | 1 | ISO885914 |
LATIN9 | ISO 8859-15 | LATIN1 c европейскими языками и диалектами | Да | 1 | ISO885915 |
LATIN10 | ISO 8859-16, ASRO SR 14111 | Румынский | Да | 1 | ISO885916 |
MULE_INTERNAL | Внутренний код Mule | Мультиязычный редактор Emacs | Да | 1-4 | |
SJIS | Shift JIS | Японский | Нет | 1-2 | Mskanji , ShiftJIS , WIN932 , Windows932 |
SHIFT_JIS_2004 | Shift JIS, JIS X 0213 | Японский | Нет | 1-2 | |
SQL_ASCII | не указан (см. текст) | any | Да | 1 | |
UHC | Унифицированный код Хангыль | Корейский | Нет | 1-2 | WIN949 , Windows949 |
UTF8 | Unicode, 8-bit | все | Да | 1-4 | Unicode |
WIN866 | Windows CP866 | Кириллица | Да | 1 | ALT |
WIN874 | Windows CP874 | Тайский | Да | 1 | |
WIN1250 | Windows CP1250 | Центральноевропейские | Да | 1 | |
WIN1251 | Windows CP1251 | Кириллица | Да | 1 | WIN |
WIN1252 | Windows CP1252 | Западноевропейские | Да | 1 | |
WIN1253 | Windows CP1253 | Греческий | Да | 1 | |
WIN1254 | Windows CP1254 | Турецкий | Да | 1 | |
WIN1255 | Windows CP1255 | Иврит | Да | 1 | |
WIN1256 | Windows CP1256 | Арабский | Да | 1 | |
WIN1257 | Windows CP1257 | Балтийские | Да | 1 | |
WIN1258 | Windows CP1258 | Вьетнамский | Да | 1 | ABC , TCVN , TCVN5712 , VSCII |
Поведение кодировки 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. Клиент-серверные перекодировки наборов символов
Серверная кодировка | Доступные клиентские кодировки |
---|---|
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 |
Чтобы включить автоматическую перекодировку символов, необходимо сообщить 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. Дополнительные источники информации
Рекомендуемые источники для начала изучения различных видов систем кодирования.
Adblock
detector
C:Program FilesPostgreSQL9.0bin>psql -U postgres
psql (9.0.3)
WARNING: Console code page (866) differs from Windows code page (1251)
8-bit characters might not work correctly. See psql reference
page «Notes for Windows users» for details.
Type «help» for help.
postgres=# encoding win-1251
postgres=# select * from «Test»;
name
———-
╨�����╓╔
John
postgres=# SET client_encoding=win866;
SET
postgres=# select * from «Test»;
name
———-
���������
Rom
Источник
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. Нажать ОК.
Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.
Всё, теперь кириллица будет нормально отображаться.
Источник
warning about console code page on starting psql
warning about console code page on starting psql
SUMMARY OF PROBLEM: Postgres notes no errors upon installation, but upon startup of psql there’s a warning; documentation fix doesn’t eliminate the warning message.
1. psql says this when I log in:
Password for user postgres:
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page «Notes for Windows users» for details.
Type «help» for help.
2. psql ref. pg. says this:
Notes for Windows Users
psql is built as a «console application». Since the Windows console windows use a different encoding than the rest of the system, you must take special care when using 8-bit characters within psql. If psql detects a problematic console code page, it will warn you at startup. To change the console code page, two things are necessary:
- Set the code page by entering cmd.exe /c chcp 1252 . (1252 is a code page that is appropriate for German; replace it with your value.) If you are using Cygwin, you can put this command in /etc/profile .
Set the console font to Lucida Console , because the raster font does not work with the ANSI code page.
3. When I enter «cmd.exe /c chcp 1252» into the command prompt, it says this:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:Userszzzzzz>cmd.exe /c chcp 1252
Active code page: 1252
4. Am I supposed to type this at the command prompt: «cmd.exe /c chcp 437»? Because that’s what I did, and now the command prompt says this.
C:Userszzzzzz>cmd.exe /c chcp 437
Active code page: 437
. but I quit and reopened psql, the error message isn’t gone or changed.
5. The instructions to set console font mean nothing to me: «Set the console font to Lucida Console , because the raster font does not work with the ANSI code page». Googled it and found nothing that made sense to me. Set whose console font? PG or Windows? Where and how to set it? What is a console, anyway? Googled again and again, finally discovered that the console being referred to is apparently psql itself. By clicking on the little rectangular icon at the top left of the title bar of the command prompt (psql), Properties, Font. there it is. «Raster Fonts» had been selected. I changed this to Lucida Console. Quit psql and restarted it.
6. psql startup warning has now changed to a different font, no other change.
7. I changed the console page back to 1252 in the command prompt:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:>cmd.exe /c chcp 1252
Active code page: 1252
8. Quit and restarted psql (twice). The warning message has not changed. Is it possible that pg is wrongly detecting code page 437, and does it matter? I have a lot of work to do and want a sparkling clean foundation to start from so I don’t have problems later.
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: warning about console code page on starting psql
Set the code page by entering cmd.exe /c chcp 1252 . (1252 is a code page that is appropriate for German; replace it with your value.) If you are using Cygwin, you can put this command in /etc/profile .
Do not type the «cmd.exe /c» part. This will run a new instance of «cmd» (the Windows command-line console); «c» means «run the following command». So you are basically starting a new console, changing the code page within that new console, and exiting back to your original console.
Instead, once you have a command prompt, use «chcp 1252» to change the code page of the Windows console to match the code page «psql» expects from Windows. Then you can run «psql» without the warning. You will have to do this each time you open a new command line console, before running «psql», as far as I can tell.
Re: warning about console code page on starting psql
Going from memory here but.
The window is which the command prompt appears is called the console. When you type psql at the command prompt you are now running a console application in that same console. You can have more than one running console and each one is independent. Any changes to the console, e.g. via the «cmd.exe /c chcp 1252» command, only persist as long as that console window remains open. Going into and out of a console application should not make a difference, only closing the actual window. Same goes for the font — it is a property of the console and not psql directly.
Since the database server uses the Windows code page you want your console to match. So given said warning you want to supply the current Windows value to the chcp command.
The message and documentation could probably be improved though I’m not positive what I am saying is 100% correct as I have never encountered this problem — because I’ve never used psql on Windows.
Re: warning about console code page on starting psql
On 12/16/2014 11:10 PM, Scott Robertson wrote:
> Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
> page that is appropriate for German; replace it with your value.) If
> you are using Cygwin, you can put this command in /etc/profile.
Do not type the «cmd.exe /c» part. This will run a new instance of «cmd»
(the Windows command-line console); «c» means «run the following
command». So you are basically starting a new console, changing the
code page within that new console, and exiting back to your original
console.
Instead, once you have a command prompt, use «chcp 1252» to change the
code page of the Windows console to match the code page «psql» expects
from Windows. Then you can run «psql» without the warning. You will have
to do this each time you open a new command line console, before running
«psql», as far as I can tell.
So basically the documented fix is useless. At least a «/k» would keep the new console with altered code page around for interactive use but the /c switch simply kills the console after running a single command whose sole purpose is to change the to-be-killed console’s codepage.
It is implied that since you are chasing the console codepage that the target value would be whatever Window’s is using. but that could be made more clear as well.
Encodings are confusing and this doesn’t even mention using windows psql against Linux or how Unicode would fit in — though external notes indicate that the font change suggestion also solves Unicode characters as well as dealing with ANSI.
Fwd: warning about console code page on starting psql
———- Forwarded message ———-
From: David G Johnston [via PostgreSQL]
Date: Tuesday, December 16, 2014
Subject: Re: warning about console code page on starting psql
To: David G Johnston
On 12/16/2014 11:10 PM, Scott Robertson wrote:
> Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
> page that is appropriate for German; replace it with your value.) If
> you are using Cygwin, you can put this command in /etc/profile.
Do not type the «cmd.exe /c» part. This will run a new instance of «cmd»
(the Windows command-line console); «c» means «run the following
command». So you are basically starting a new console, changing the
code page within that new console, and exiting back to your original
console.
Instead, once you have a command prompt, use «chcp 1252» to change the
code page of the Windows console to match the code page «psql» expects
from Windows. Then you can run «psql» without the warning. You will have
to do this each time you open a new command line console, before running
«psql», as far as I can tell.
So basically the documented fix is useless. At least a «/k» would keep the new console with altered code page around for interactive use but the /c switch simply kills the console after running a single command whose sole purpose is to change the to-be-killed console’s codepage.
It is implied that since you are chasing the console codepage that the target value would be whatever Window’s is using. but that could be made more clear as well.
Encodings are confusing and this doesn’t even mention using windows psql against Linux or how Unicode would fit in — though external notes indicate that the font change suggestion also solves Unicode characters as well as dealing with ANSI.
Re: warning about console code page on starting psql
———- Forwarded message ———-
From: David G Johnston [via PostgreSQL]
Date: Tuesday, December 16, 2014
Subject: Re: warning about console code page on starting psql
To: David G Johnston
On 12/16/2014 11:10 PM, Scott Robertson wrote:
> Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
> page that is appropriate for German; replace it with your value.) If
> you are using Cygwin, you can put this command in /etc/profile.
Do not type the «cmd.exe /c» part. This will run a new instance of «cmd»
(the Windows command-line console); «c» means «run the following
command». So you are basically starting a new console, changing the
code page within that new console, and exiting back to your original
console.
Instead, once you have a command prompt, use «chcp 1252» to change the
code page of the Windows console to match the code page «psql» expects
from Windows. Then you can run «psql» without the warning. You will have
to do this each time you open a new command line console, before running
«psql», as far as I can tell.
So basically the documented fix is useless. At least a «/k» would keep the new console with altered code page around for interactive use but the /c switch simply kills the console after running a single command whose sole purpose is to change the to-be-killed console’s codepage.
It is implied that since you are chasing the console codepage that the target value would be whatever Window’s is using. but that could be made more clear as well.
Encodings are confusing and this doesn’t even mention using windows psql against Linux or how Unicode would fit in — though external notes indicate that the font change suggestion also solves Unicode characters as well as dealing with ANSI.
Re: warning about console code page on starting psql
Thanks David, I am starting to understand the console is what they used
to call a dos prompt, the little black window where psql appears.
As you say, the font change had no effect on the Windows command prompt
console that I open from the Windows start menu. However, the font
change did persist in psql. Each time I reopen psql, it is now
automatically in Lucida Console font.
It seems I should be able to get to C:> from the same (psql) console,
but don’t know how, or how to get back to psql if I did. And don’t know
if there’s any reason to.
It sounds like you’re saying that I should type this command in the psql
console each time I open it. In which case, I’d have to get to the C:>
in order to do it, since it’s not a psql command.
However, returning to my original post, I have already determined that
Windows is set to 1252 as (?) instructed by pg documentation, and is
still giving the same error. Is there a windows configuration file I
should edit or.
Re: warning about console code page on starting psql
Thanks David, I am starting to understand the console is what they used
to call a dos prompt, the little black window where psql appears.
As you say, the font change had no effect on the Windows command prompt
console that I open from the Windows start menu. However, the font
change did persist in psql. Each time I reopen psql, it is now
automatically in Lucida Console font.
It seems I should be able to get to C:> from the same (psql) console,
but don’t know how, or how to get back to psql if I did. And don’t know
if there’s any reason to.
It sounds like you’re saying that I should type this command in the psql
console each time I open it. In which case, I’d have to get to the C:>
in order to do it, since it’s not a psql command.
Yes, I had a shortcut for psql in the program files start menu of Windows, which I moved to the desktop. I don’t know another way to open it.
Shortcut target is «C:Program FilesPostgreSQL9.4scriptsrunpsql.bat»
Start in location is «C:Program FilesPostgreSQL9.4scripts»
However, returning to my original post, I have already determined that
Windows is set to 1252 as (?) instructed by pg documentation, and is
still giving the same error. Is there a windows configuration file I
should edit or.
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: warning about console code page on starting psql
Sorry, I forgot to Cc the list earlier when I was replying from my phone.
On 18 December 2014 at 07:38, Scott Robertson wrote:
I assume you also changed the font. Since I don’t currently use
Postgres and have never used it on Windows, I’m not sure how important
it is to change the font, but since it was mentioned in the docs, I
assume it should be done.
> C:>cd program filespostgresql9.4bin
>
> C:Program FilesPostgreSQL9.4bin>psql
> Password:
> psql: FATAL: password authentication failed for user «Luther»
>
> C:Program FilesPostgreSQL9.4bin>psql
> Password:
> psql: FATAL: password authentication failed for user «Luther»
The way you were running psql before seems to be via a .bat or .cmd
file. Did the authentication work that way? If so, it might be easiest
to edit that file to add in the «chcp 1252» command before the call to
the actual psql command. Or otherwise see how that file calls the
actual psql command and do the same thing manually.
If you decide to edit the .bat (or .cmd) file, make a backup of it first
in case you make a mistake.
Re: warning about console code page on starting psql
On Tuesday, December 16, 2014, David Johnston wrote:
———- Forwarded message ———-
From: David G Johnston [via PostgreSQL]
Date: Tuesday, December 16, 2014
Subject: Re: warning about console code page on starting psql
To: David G Johnston
On 12/16/2014 11:10 PM, Scott Robertson wrote:
> Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
> page that is appropriate for German; replace it with your value.) If
> you are using Cygwin, you can put this command in /etc/profile.
Do not type the «cmd.exe /c» part. This will run a new instance of «cmd»
(the Windows command-line console); «c» means «run the following
command». So you are basically starting a new console, changing the
code page within that new console, and exiting back to your original
console.
Instead, once you have a command prompt, use «chcp 1252» to change the
code page of the Windows console to match the code page «psql» expects
from Windows. Then you can run «psql» without the warning. You will have
to do this each time you open a new command line console, before running
«psql», as far as I can tell.
So basically the documented fix is useless. At least a «/k» would keep the new console with altered code page around for interactive use but the /c switch simply kills the console after running a single command whose sole purpose is to change the to-be-killed console’s codepage.
It is implied that since you are chasing the console codepage that the target value would be whatever Window’s is using. but that could be made more clear as well.
Encodings are confusing and this doesn’t even mention using windows psql against Linux or how Unicode would fit in — though external notes indicate that the font change suggestion also solves Unicode characters as well as dealing with ANSI.
Case closed and much learned. The documentation was depending on me remembering some things learned from a dos class almost 20 years ago, haven’t used the command line console since.
SUMMARY OF SOLUTION
start console cmd.exe
use icon upper left on title bar to change font to Lucida Console
change to root directory: cd
check the code page to confirm it’s wrong: chcp
change the code page: chcp 1252
change to postgresql directory; in my Windows 7 it’s: cd program filespostgresql9.4bin
open psql (in same console) as superuser so operating system user password isn’t expected: psql -U postgres
prompt comes up for postgres password
RESULTS:
Microsoft Windows [Version 6.1.7600]
C:>chcp
Active code page: 437
C:>chcp 1252
Active code page: 1252
C:>cd program filespostgresql9.4bin
C:Program FilesPostgreSQL9.4bin>
C:Program FilesPostgreSQL9.4bin>psql -U postgres
Password for user postgres:
psql (9.4rc1)
Type «help» for help.
postgres=# c testdb2
You are now connected to database «testdb2» as user «postgres».
testdb2=# select * from jedstblinmelsdb;
key | name | address
——+——+———
(0 rows)
Источник
Adblock
detector
Для обычного виндоадмина PostgreSQL — как взрыв мозга и разрыв GUI шаблонов ))
И так задача — нужно создать пользователя БД. Средство администрирования pgAdmin не позволяет создать пользователя для определенной БД. Можно создать роль, но как привязать её к БД средствами GUI интерфейса совсем непонятно. Ладно, берем утилиту psql.exe, запускаем и получаем грозное сообщение:
C:\Programs\PostgreSQL\9.0\bin>psql -U postgres
psql (9.0.10)
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
Подробнее об этом смотрите документацию psql, раздел
«Notes for Windows users».
Введите «help», чтобы получить справку.
Можно впасть в депрессию, представив что нужно будет читать иероглифы, полученные отображением cp1251 под dos866. Но не всё потеряно. Рецепт из доки:
- \q или Ctrl+Z — выходим обратно в шелл
- chcp 1251 — меняем кодировку шелла на win1251
- в свойствах окна шелла меняем шрифт на Lucida Console
Ок. Кодировку починили, делаем пользователя. В сеансе psql:
- Подключаемся к БД — CONNECT our_database_name
- Создаем роль CREATE USER djangoweb;
(обазательно точку с запятой в конце, иначе не SQL не выполнится)
Please help me to solve the problem with psql Shell. When i am working inside the SQL Shell the column headers don’t display correctly (this should be display in more nicely, do you know to solve it? My operating system is windows 7 ultimate SP1
Like in this example:
╤яшёюъ срч фрээ√ї
╚ь | ┬ырфхыхЎ | ╩юфшЁютър | LC_COLLATE | LC_CTYPE |
╧Ёртр фюёЄєяр
or like this:
╤яшёюъ юЄэю°хэшщ
╤їхьр | ╚ь | ╥шя | ┬ырфхыхЎ
The full commands that I wrote in SQL Shell:
Server [localhost]:
Database [postgres]:
Port [5432]:
Username [postgres]:
Пароль пользователя postgres:
psql (10.11)
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
Подробнее об этом смотрите документацию psql, раздел
"Notes for Windows users".
Введите "help", чтобы получить справку.
postgres=# \l
╤яшёюъ срч фрээ√ї
╚ь | ┬ырфхыхЎ | ╩юфшЁютър | LC_COLLATE | LC_CTYPE |
╧Ёртр фюёЄєяр
-----------+----------+-----------+---------------------+---------------------+-
----------------------
postgres | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
template0 | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
=c/postgres +
| | | | |
postgres=CTc/postgres
template1 | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
=c/postgres +
| | | | |
postgres=CTc/postgres
(3 ёЄЁюъш)
postgres=# CREATE TABLE flights ( id SERIAL PRIMARY KEY, origin VARCHAR NO
T NULL, destination VARCHAR NOT NULL, duration INTEGER NOT NULL);
CREATE TABLE
postgres=# \d
╤яшёюъ юЄэю°хэшщ
╤їхьр | ╚ь | ╥шя | ┬ырфхыхЎ
--------+----------------+--------------------+----------
public | flights | ЄрсышЎр | postgres
public | flights_id_seq | яюёыхфютрЄхы№эюёЄ№ | postgres
(2 ёЄЁюъш)
postgres=#
I guess, i am not sure, maybe problem is here? But how to add a new fonts to this table?
postgres=# \l
╤яшёюъ срч фрээ√ї
╚ь | ┬ырфхыхЎ | ╩юфшЁютър | LC_COLLATE | LC_CTYPE |
╧Ёртр фюёЄєяр
-----------+----------+-----------+---------------------+---------------------+-
----------------------
postgres | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
template0 | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
=c/postgres +
| | | | |
postgres=CTc/postgres
template1 | postgres | UTF8 | Russian_Russia.1251 | Russian_Russia.1251 |
=c/postgres +
| | | | |
postgres=CTc/postgres
(3 ёЄЁюъш)
I read this website https://www.postgresql.org/docs/8.4/multibyte.html#AEN29822 this is pretty close to my problem, but according to these information I could only change the text fonts only inside tables, it couldn’t change the fonts of the column headers.
Ошибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:
Столь же скупа и информация для технической поддержки:
Обычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.
К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас — может скачать ее по ссылке с Инфостарта)
1:Tools (Зеркало на Инфостарте)
MD5: 448277422B59EFA426CC51E4F3A52F53
В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С — это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД — это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.
Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.
В зависимости от того, какая именно часть конфигурации ИБ оказалась повреждена база может не загружаться в обычном режиме, но загружаться в Конфигуратор, либо вообще не загружаться никак. Если доступен режим конфигуратора, то можно попробовать снять базу с поддержки и загрузить в нее исправную конфигурацию из файла, в некоторых случаях это приведет к успеху, в других может потребоваться сначала выявить и удалить сбойный элемент метаданных.
Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.
Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:
sudo -s
su postgres
Если утилита sudo не установлена (такой вариант может быть в Debian), то:
su -
su postgres
В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором — от учетной записи суперпользователя (root).
Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:
psql -l
В Windows вам потребуется ввести пароль пользователя postgres.
Выяснив имя необходимой базы данных выгрузим ее дамп командой:
#Linux
pg_dump basename > ~/basename.psql#Windows
pg_dump basename > D:\backup\basename.psql
Где basename — имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.
Для дальнейших действий нам потребуется развернуть на этом же сервере СУБД еще одну базу с точно такой же конфигурацией информационной базы, это может быть как старый бекап поврежденной базы, так и другая база такой же конфигурации, чистая установка или демо база. Главное, чтобы конфигурация новой базы с точностью до релиза совпадала с конфигурацией поврежденной.
После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:
psql
В Windows вы можете получить сообщение:
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
В этом случае выполните:
\! chcp 1251
Теперь подключимся к исправной базе:
\с newbasename
где newbasename — имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.
Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.
#Linux
COPY config TO '/var/lib/postgresql/config_OK.txt';#Windows
COPY config TO 'D:/backup/config_OK.txt';
Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.
Переподключимся к поврежденной базе:
\с basename
На всякий случай, также сохраним содержимое таблицы config:
#Linux
COPY config TO '/var/lib/postgresql/config_ERR.txt';#Windows
COPY config TO 'D:/backup/config_ERR.txt';
После чего очистим сбойную таблицу:
DELETE FROM config;
И загрузим в нее данные из исправной информационной базы:
#Linux
COPY config FROM '/var/lib/postgresql/config_OK.txt';#Windows
COPY config FROM 'D:/backup/config_OK.txt';
Для выхода из терминала PostgreSQL введите:
\q
Если все сделано правильно, то поврежденная конфигурация информационной базы будет заменена на исправную и ее работоспособность будет восстановлена.
В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:
DELETE FROM configsave;
Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.