Материал из Кафедра ИУ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
Всё, теперь кириллица будет нормально отображаться.
Проверяем:
Для обычного виндоадмина PostgreSQL — как взрыв мозга и разрыв GUI шаблонов ))
И так задача — нужно создать пользователя БД. Средство администрирования pgAdmin не позволяет создать пользователя для определенной БД. Можно создать роль, но как привязать её к БД средствами GUI интерфейса совсем непонятно. Ладно, берем утилиту psql.exe, запускаем и получаем грозное сообщение:
C:ProgramsPostgreSQL9.0bin>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: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] �������� | ���������� �������� ����������
|
eye-cutter Member encoding win-1251 |
27 ��� 11, 18:26����[10576522] �������� | ���������� �������� ���������� |
|
������� Member SET client_encoding=win866; |
28 ��� 11, 00:19����[10577825] �������� | ���������� �������� ���������� |
|
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 |
Вопрос №11268 от пользователя Sergey Erofeev в уроке «Введение», курс «Базы данных: SQL (DDL/DML)»
Sergey Erofeev
Кто столкнется с такой бедой:
ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
страницы Windows (1251).
8-битовые (русские) символы могут отображаться некорректно.
Подробнее об этом смотрите документацию psql, раздел
«Notes for Windows users».
Введите «help», чтобы получить справку.
Решение здесь.
1
0
Используйте Хекслет по-максимуму!
-
Задавайте вопросы по уроку -
Проверяйте знания в квизах -
Проходите практику прямо в браузере -
Отслеживайте свой прогресс
Зарегистрируйтесь или
войдите в свой аккаунт
Рекомендуемые программы
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Разработка фронтенд-компонентов для веб-приложений
9 февраля
10 месяцев
Интенсивное обучение профессии в режиме полного дня
9 февраля
4 месяца
Разработка веб-приложений на Django
9 февраля
10 месяцев
Разработка приложений на языке Java
9 февраля
10 месяцев
Разработка веб-приложений на Laravel
9 февраля
10 месяцев
Ручное тестирование веб-приложений
9 февраля
4 месяца
Разработка бэкенд-компонентов для веб-приложений
9 февраля
10 месяцев
Разработка фронтенд- и бэкенд-компонентов для веб-приложений
9 февраля
16 месяцев
Создание веб-приложений со скоростью света
9 февраля
5 месяцев
Верстка с использованием последних стандартов CSS
в любое время
5 месяцев
Профессия
В разработке
с нуля
Сбор, анализ и интерпретация данных
16 марта
8 месяцев
Брошюра сказала мне:
В ОС Windows запустите программу «SQL Shell (psql)» из меню «Пуск».
В ответ на запрос введите пароль пользователя postgres, который вы указали при установке PostgreSQL.
Попробовал и в результате получил:
Код: Выделить всё
Текущая кодовая страница: 1251
psql: ошибка: подключиться к серверу "localhost" (127.0.0.1), порту 5432 не удалось: Connection refused (0x0000274D/10061)
Сервер действительно работает по данному адресу и принимает TCP-соединения?
подключиться к серверу "localhost" (::1), порту 5432 не удалось: Connection refused (0x0000274D/10061)
Сервер действительно работает по данному адресу и принимает TCP-соединения?
Для продолжения нажмите любую клавишу . . .
Нажимание «любой клавиши» привело к закрытию окошка командной строки…
Всё правильно, всё нормально, поскольку на моем ноутбуке действительно не работает сервер PostgreSQL.
Почитаем, как присоединяться к удаленному серверу.
Прилагаемая документация в формате Microsoft Help никак не помогла подключиться к удаленному серверу.
Там также рассматривается вариант, когда база стоит на той же машине, что и клиент.
Более подробную документацию не нашел, поэтому решил пока прорваться «методом научного тыка».
Нашел, что моя программа psql.exe расположена в каталоге D:PostgreSQL14bin
Там же расположены другие утилиты.
Однако путь в этот каталог не был добавлен в системную переменную PATH,
как это делалось при установке продуктов Oracle Database.
Я не стал вручную добавлять в PATH дополнительную строчку, а просто написал командный файл run_psql.bat
Код: Выделить всё
@ECHO OFF
SET "PATH=D:PostgreSQL14bin;%PATH%"
REM было так, но не хватало параметров для вызова:
REM psql.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
REM стало вот так. Теперь параметров должно хватить!
psql.exe %*
Выполнил этот файл, убедился, что вызывается утилита psql.
А кроме того узнал, что параметры командных файлов в Windows можно не перечислять поштучно, а задавать в шаблоне ‘%*’
Решил посмотреть, какие параметры есть у psql
Попытка #1: ключ /? (в стиле DOS/Windows):
Код: Выделить всё
D:PostgreSQLTESTINGSQL>run_psql.bat /? psql: ошибка: подключиться к серверу "localhost" (127.0.0.1), порту 5432 не удалось: Connection refused (0x0000274D/10061)
Сервер действительно работает по данному адресу и принимает TCP-соединения?
подключиться к серверу "localhost" (::1), порту 5432 не удалось: Connection refused (0x0000274D/10061)
Сервер действительно работает по данному адресу и принимает TCP-соединения?
Понятно. Ключи в стиле DOS/Windows мы не понимаем, хотя мы и есть программы под DOS/Windows
Замечу, что ввод ключа ? или help«в стиле PostgreSQL» приводит к таким же результатам,
то есть и в этом стиле такой ключ игнорируется.
Странное поведение.
В DOS/Windows принято сообщать, что это неверный параметр, а не игнорировать его.
Код: Выделить всё
D:PostgreSQLTESTINGSQL>dir /lazha Ошибка в формате параметра: "lazha".
Попытка #2: ключ -? (в стиле Unix):
Код: Выделить всё
D:PostgreSQLTESTINGSQL>run_psql.bat -?
. . .
Параметры подключения:
-h, --host=ИМЯ имя сервера баз данных или каталог сокетов
(по умолчанию: "локальный сокет")
-p, --port=ПОРТ порт сервера баз данных (по умолчанию: "5432")
-U, --username=ИМЯ имя пользователя (по умолчанию: "vyourinsky")
-w, --no-password не запрашивать пароль
-W, --password запрашивать пароль всегда (обычно не требуется)
Чтобы узнать больше, введите "?" (список внутренних команд) или "help" (справка по операторам SQL) в psql, либо обратитесь к разделу psql в документации PostgreSQL.
Об ошибках сообщайте по адресу <pgsql-bugs@lists.postgresql.org>. Домашняя страница PostgreSQL: <https://www.postgresql.org/>
Вот! Информацию нужную добыл. буду пробовать подключаться.
Последний раз редактировалось SQL*Plus Ср июл 13, 2022 5:12 pm, всего редактировалось 1 раз.
Содержание
- PostgreSQL — Кириллица в psql под Windows
- Содержание
- Описание проблемы
- Решение проблемы
- Конкретные действия
- Супер быстро и просто
- Быстро и просто
- Посложнее и подольше
- Psql кодовая страница консоли 866 отличается от основной страницы windows 1251 + видео обзор
- Psql кодовая страница консоли 866 отличается от основной страницы windows 1251
- Можно: SET CLIENT_ENCODING TO
- Спасибо, но не помогло, это
- Не ту кодировку выбрали вот и
- Дело в том, что она не
- Так в psql надо команду
- Странно, может это все руки,
- Простите, а вы что не в
- Чтобы не создавать новую тему, добавлю вопрос сюда
- SET CLIENT_ENCODING
- Воспользуйтесь рекомендацией
- Кириллица в консоли на английской Windows с кодовой страницей, отличающеся от CP 1251 #88
- Comments
- alexkmbk commented Dec 6, 2017 •
- nixel2007 commented Dec 6, 2017
- alexkmbk commented Dec 6, 2017
- nixel2007 commented Dec 6, 2017
- alexkmbk commented Dec 6, 2017
- alexkmbk commented Feb 7, 2018
- nixel2007 commented Feb 7, 2018
- EvilBeaver commented Feb 7, 2018 •
- EvilBeaver commented Feb 7, 2018
- alexkmbk commented Feb 7, 2018 •
- tsukanov-as commented Feb 7, 2018
- EvilBeaver commented Feb 7, 2018
- tsukanov-as commented Feb 7, 2018 •
- EvilBeaver commented Feb 7, 2018
- tsukanov-as commented Feb 7, 2018
- Asakra commented Mar 6, 2019
- Psql кодовая страница консоли 866 отличается от основной страницы windows 1251
- 23.3.1. Поддерживаемые кодировки
- 23.3.2. Настройка кодировки
- Важно
- 23.3.3. Автоматическая перекодировка между сервером и клиентом
- 23.3.4. Возможные перекодировки наборов символов
- 23.3.5. Дополнительные источники информации
- О кодировках и кодовых страницах
- PostgreSQL: предупреждение: кодовая страница консоли (437) отличается от кодовой страницы Windows (1252)
- 12 ответов
- Похожие вопросы:
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. Нажать ОК.
В ответ выведет:
Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.
Всё, теперь кириллица будет нормально отображаться.
Источник
Psql кодовая страница консоли 866 отличается от основной страницы windows 1251 + видео обзор
Psql кодовая страница консоли 866 отличается от основной страницы windows 1251
Можно-ли как-нибудь поменять кодировку консоли ну или как-то это исправить, если причина в другом?
Можно: SET CLIENT_ENCODING TO
Спасибо, но не помогло, это
Спасибо, но не помогло, это уже пробовал) Все равно иероглифы вместо русских букв.
Не ту кодировку выбрали вот и
Не ту кодировку выбрали вот и всё. Всем помогает, вам нет?
Дело в том, что она не
Дело в том, что она не меняется, как была 866, так и остается, может я куда-то не туда ввожу команду? (пробовал в саму консоль и в граф. интерфейсе, команда выполняется (за
Так в psql надо команду
Так в psql надо команду вводить, при чём здесь консоль?
Команда переключает вывод символов PostgreSQL в ту кодировку, которую вы укажете.
При этом на содержимое БД это никак не влияет.
Странно, может это все руки,
Странно, может это все руки, поступаю так:
Запускаем PSQL Shell (psql), после ввода названия сервера, порта, БД, пользователя и пароля..
music1=# SET CLIENT_ENCODING TO ‘WIN1251’;
(выводятся по прежнему кракозябры)
Еще пробовал
music1=# encoding win1251; (тоже нет)
и менять строку #client_encoding = sql_ascii (в postgresql.conf) на #client_encoding = win1251
(все как раньше) Хотя результаты запросов, если их вводить в pgAdmin (кнопка «выполнить пользовательские sql-запросы»), выводятся нормально.
Простите, а вы что не в
Простите, а вы что не в курсе, что консоль 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. Ничего не помогает, кракозябры и все.
Шрифт консоли переключал с «Точечные шрифты» на «Lucinda Console». Тоже не помогает.
Что я делаю не так? Как его «русифицировать»?
Спасибо.
SET CLIENT_ENCODING
SET CLIENT_ENCODING устанавливает кодировку для вывода значений из БД, а не хелпа.
Воспользуйтесь рекомендацией
Воспользуйтесь рекомендацией «Set the code page by entering cmd.exe /c chcp 1252.»
т.е. запускаете cmd.exe, набираете «chcp 1251«, далее enter. Выйдет сообщение
Текущая кодовая страница: 1251
После этого запускаете psql.
Кодовую страницу необходимо устанавливать при каждом запуске cmd.
Кириллица в консоли на английской Windows с кодовой страницей, отличающеся от CP 1251 #88
Прикладываю скриншот с проблемой.
Можно конечно в ручную поменять кодовую страницу командой CHCP 1251, но может быть есть более крутое решение на уровне самого opm?
Я предлагаю выводить справочную инфу на английском в случае, если не CP 1251 или Windows не русифицированная.
The text was updated successfully, but these errors were encountered:
По идее кириллица должна нормально выводится при chcp 65001
По идее кириллица должна нормально выводится при chcp 65001
Да, так и есть, но у меня в конкртеном случае (в силу определенных причин) по дефолту в консоли стоит другая. Возможно моя проблема очень редкая.
Это наверное даже больше в движок. @EvilBeaver?
Это скорее к микрософту, чем ко мне. Если предлагаемое решение звучит, как:
«Определить текущую кодировку консоли, и если она не может выводить русский то задать такую кодировку, которая сможет выводить русский», то я пас.
И пас я из-за строчки, выделенной жирным. У меня пробелы в образовании, я не знаю, как надежно проверить данное условие.
Хотя, с удовольствием приму пулреквест.
@EvilBeaver Но мы ведь точно знаем какие кодировки поддерживают кириллицу, а какие нет, я их все на память не приведу сходу, но их число конечно, а самые популярные так это должны быть 65001 и 1251
@alexkmbk Вопрос наверно не в тему. Но зачем вообще использовать CMD, когда в винде он заменен на повершел? Нравится страдать? )))
В павершеле тоже не все гладко с кодировками.
@EvilBeaver Все там гладко. Просто использовать нужно юникод всегда
ps Вообще не пересекаюсь с 1251 и не понимаю на кой с ней вообще возиться в 2018 году
@tsukanov-as в условии задачи от @alexkmbk сказано что нельзя юникод и на то есть причины.
@EvilBeaver Ну мое дело вбросить. Страдать или нет это личный выбор каждого )
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Psql кодовая страница консоли 866 отличается от основной страницы windows 1251
Важным ограничением, однако, является то, что кодировка каждой базы данных должна быть совместима с параметрами локали базы данных LC_CTYPE (классификация символов) и LC_COLLATE (порядок сортировки строк). Для локали C или POSIX подойдёт любой набор символов, но для других локалей, предоставляемых библиотекой libc, есть только один набор символов, который будет работать правильно. (Однако в среде Windows кодировка UTF-8 может использоваться с любой локалью.) Если у вас включена поддержка ICU, локали, предоставляемые библиотекой ICU, можно использовать с большинством (но не всеми) кодировками на стороне сервера.
23.3.1. Поддерживаемые кодировки
Таблица 23.1. Кодировки PostgreSQL
23.3.2. Настройка кодировки
При создании базы данных можно указать кодировку, отличную от заданной по умолчанию, если эта кодировка совместима с выбранной локалью:
Важно
23.3.3. Автоматическая перекодировка между сервером и клиентом
PostgreSQL поддерживает автоматическое перекодирование символов между сервером и клиентов для многих сочетаний кодировок (они перечисляются в Подразделе 23.3.4).
Чтобы включить автоматическую перекодировку символов, необходимо сообщить PostgreSQL кодировку, которую вы хотели бы использовать на стороне клиента. Это можно выполнить несколькими способами:
libpq (Раздел 33.10) имеет функции, для управления клиентской кодировкой.
Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES :
Получить текущую клиентскую кодировку:
Вернуть кодировку по умолчанию:
Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1 ), возникает ошибка.
23.3.4. Возможные перекодировки наборов символов
Таблица 23.2. Встроенные клиент-серверные перекодировки наборов символов
Таблица 23.3. Все встроенные перекодировки наборов символов
23.3.5. Дополнительные источники информации
Рекомендуемые источники для начала изучения различных видов систем кодирования.
О кодировках и кодовых страницах
Вряд ли это сейчас сильно актуально, но может кому-то покажется интересным (или просто вспомнит былые годы).
Начну с небольшого экскурса в историю компьютера. Поскольку компьютер использовался для обработки информации, то он просто обязан представлять эту информацию в «человеческом» виде. Компьютер хранит информацию в виде чисел (байтов), а человек воспринимает символы (буквы, цифры, различные знаки). Значит, надо сделать сопоставление число символ и задача будет решена. Сначала посчитаем, сколько символов нам надо (не забудем, что «мы» — американцы, использующие латинский алфавит). Нам надо 10 цифр + 26 заглавных букв английского алфавита + 26 строчных букв + математические знаки (хотя бы +-/*=> + можно определить соответствующий ей код в Unicode (сейчас в кодовых страницах для каждого 8-битного кода показывается 16-битный код Unicode) и потом при необходимости вывести этот символ для любой кодовой страницы, где он присутствует. В настоящее время проблема кодировок и перекодировок для пользователей практически исчезла, но все же изредка приходят письма, где либо тема письма либо содержание «не в той» кодировке.
Интересно, что примерно год назад проблема кодировок ненадолго всплыла при «наезде» ФАС на сотовых операторов, мол те дискриминируют русскоязычных пользователей, поскольку за передачу кириллицы берут больше. Это объясняется техническим решением, выбранным разработчиком протокола SMS связи. Если бы его россияне разработали, они бы, возможно, отдали приоритет кириллице. В указанной статье «начальник управления контроля транспорта и связи Дмитрий Рутенберг отметил, что существуют и восьмибитные кодировки для кириллицы, которые могли бы использовать операторы.» Во как — на улице 21-й век, Unicode шагает по миру, а господин Рутенберг тянет нас в начало 90-х, когда шла «война кодировок» и проблема перекодировок стояла во весь рост. Интересно, в какой кодировке должен получить СМС Вася Пупкин, пользующийся финским телефоном, находящийся в Турции на отдыхе, от жены с корейским телефоном, отправляющей СМС из Казахстана? А от своего французского компаньона (с японским телефоном), находящегося в Испании? Думаю, никакой начальник ответа на этот вопрос дать не сможет. К счастью, это «экономное» предложение не воплотилось в жизнь.
Юный читатель может спросить — а что помешало сразу использовать Unicode, зачем были придуманы эти заморочки с кодовыми страницами? Думаю, дело в финансовой стороне проблемы. Unicode требует в 2 раза больше памяти, а память стоит денег (и дисковая и ОЗУ). Стал бы американец покупать компьютер на 1-2 тыс дороже из-за того, что «теперь новая ОС требует больше памяти, но позволяет без проблем работать с русским, европейскими, арабскими языками»? Боюсь, простой англоязычный покупатель воспринял бы такой аргумент «неадекватно» (и обратился бы к другим производителям).
PostgreSQL: предупреждение: кодовая страница консоли (437) отличается от кодовой страницы Windows (1252)
Использование PostgreSQL при подключении к БД с использованием c testdb внутри PostgreSQL базы данных SQL Prompt. Я успешно подключаюсь к БД, но получаю следующее предупреждение:
Что означает это предупреждение? Как ее решить?
12 ответов
Когда я использую функцию Chr(225), я получаю символ á, потому что кодовая страница Windows равна 1250 (System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage) Можно ли использовать Chr(225), но получить символ другой кодовой страницы? Например, код 225 представляет на кодовой.
psql построен как «console application». Начиная с консоли Windows windows используйте другую кодировку, чем rest системы, вы должны быть особенно осторожны при использовании 8-битных символов в psql. Если psql обнаружит проблемную кодовую страницу консоли, он предупредит вас при запуске.
Чтобы изменить кодовую страницу консоли, необходимо выполнить две вещи: Установите кодовую страницу, введя cmd.exe /c chcp 1252. (1252-это кодовая страница, подходящая для немецкого языка; замените ее своим значением.) если вы используете Cygwin, вы можете поместить эту команду в /etc/profile.
Чтобы сделать это еще более очевидным, файл, к которому @user3423801 добавляет строку
Например, в моем случае это
Кодовая страница по умолчанию для CMD.exe отличается от кодовой страницы по умолчанию для postgres. Чтобы перейти на CMD.exe с помощью REGISTRY, попробуйте сделать следующее:
Затем снова откройте CMD.exe
Постановка моей задачи выглядит следующим образом: В архитектуре клиент/сервер, включающей связь веб-служб, я получаю на стороне сервера файл CSV от клиента. The API дает мне org.apache.commons.fileupload.FileItem Допустимыми кодовыми страницами для этих файлов являются кодовая страница 850 и.
Я установил PostgreSQL, желая создать новую базу данных, все идет нормально, пока я не пытаюсь использовать знак€. И тогда я понял, что предупреждение, которое я получаю в самом начале, не просто так. Предупреждение, которое я получаю при запуске моего psql shell, таково: WARNING: Console code.
Перейти к ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftCommand Processor
Создайте строковое значение с именем: Autorun и измените его на chcp 1252
Ответ dvdgsng это правильно, но с Пример кода-это более очевидно.
Или вы можете просто ввести cmd.exe /c chcp 1252 в окне командной строки.
Я не мог понять, как установить его на Cygwin глобально. Это, казалось, работало, хотя в моем сценарии bash
Приведенные выше ответы хороши, но нигде не упоминайте, что кодировка Windows 1252 хороша для англоязычных версий Windows AND других западноевропейских языков. Это завершает ответ для тех людей, которые могут запутаться в вышеупомянутом приложении к кодировке немецкого языка. Да, он работает для английского языка без умлаутов и других специальных символов, необходимых для немецкого, испанского, французского, итальянского, румынского, венгерского и т. д.
Что такое кодировка Windows 1252?
Windows-1252 или CP-1252 (кодовая страница 1252)-это однобайтовая кодировка символов латинского алфавита, используемая по умолчанию в устаревших компонентах Microsoft Windows для английского и некоторых других западных языков (другие языки используют другие кодировки по умолчанию).
Пожалуйста, не думайте, что исправления Unix работают для Windows пользователей. Для Windows 10 и PostgreSQL 12 объединение ответов на «user3423801» и «numbers longer» сработало для меня. (Взлом реестра Windows не сработает. Я еще не пытался перезагрузиться.) В любом случае лучше исправить это в сценарии запуска PSQL.
После долгих поисков ответа, который имел для меня смысл, я нашел эту цепочку help email на сайте PostgreSQL, которая в основном говорит о запуске chcp 1252 из открытого командного окна. Затем я смог запустить свои команды PostgreSQL без предупреждения кода.
NOTE: это изменение не сохраняется, поэтому вы должны запускать его каждый раз, когда открываете новое командное окно, в котором планируете использовать команды PostgreSQL.
Для Postgres 11
«WARNING: кодовая страница консоли (437) отличается от кодовой страницы Windows (1252) 8-битные символы могут работать неправильно. Подробнее см. справочную страницу psql «Notes for Windows users».»
В принципе, установите кодировку консольного приложения с 8-битной на utf-8.
Для пользователей git bash выполните команду chcp.com 1252 перед запуском postgres
git bash не может расширить chcp до полного исполняемого файла сам по себе, поэтому вам нужно ввести полную команду.
Похожие вопросы:
Я получаю следующее предупреждение об источнике OLEDB в пакете SSIS. Предупреждение 1 предупреждение о проверке. Задача Потока Данных: : не удается получить.
я знаю, что некоторые locale-е (например, дальневосточные локали) имеют многобайтовые наборы символов, где для представления символа требуется несколько байтов. я хотел бы проверить способность.
Delphi 2010 При чтении из файла с помощью процедуры readLn по умолчанию я получаю строку unicode, преобразованную из кодовой страницы 1251 (кодовая страница windows). Как я могу изменить это и.
Когда я использую функцию Chr(225), я получаю символ á, потому что кодовая страница Windows равна 1250 (System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage) Можно ли использовать.
Постановка моей задачи выглядит следующим образом: В архитектуре клиент/сервер, включающей связь веб-служб, я получаю на стороне сервера файл CSV от клиента. The API дает мне.
Я установил PostgreSQL, желая создать новую базу данных, все идет нормально, пока я не пытаюсь использовать знак€. И тогда я понял, что предупреждение, которое я получаю в самом начале, не просто.
Я использую последнюю версию windows 10. Когда я попытался запустить клиентский код expample из boost asio и получил ожидаемое исключение в этой строке: catch (const std::exception& e) Как настроить правильную кодировку в PostgreSql
💻 PostgreSQL: установка, настройка, консоль
#ФормулаЗдоровья Гипнотическое кодирование организма на спонтанное выздоровление — суть «тя-жести»
Всё об установке 1С: платформа, конфигурация, база данных, сервер, SQL, резервное копирование
Администрирование СУБД PostgreSQL. Основы SQL [GeekBrains]
80286-й наконец-то разглючен (неожиданное объяснение проблем с памятью)
QSL почта выпуск от 16 июня 2022
С чего начать программатор для старта MiniPro TL866II
POSTGRESQL НА WINDOWS ► Установка PostgreSQL на Windows
01 — Создание, Подключение и Удаление Базы Данных — Уроки PostgreSQL
Источник
Adblock
detector
Имя преобразования [a] | Исходная кодировка | Целевая кодировка |
---|---|---|
big5_to_euc_tw | BIG5 | EUC_TW |
big5_to_mic | BIG5 | MULE_INTERNAL |
big5_to_utf8 | BIG5 | UTF8 |
euc_cn_to_mic | EUC_CN | MULE_INTERNAL |
euc_cn_to_utf8 | EUC_CN | UTF8 |
euc_jp_to_mic | EUC_JP | MULE_INTERNAL |
euc_jp_to_sjis | EUC_JP | SJIS |
euc_jp_to_utf8 | EUC_JP | UTF8 |
euc_kr_to_mic | EUC_KR | MULE_INTERNAL |
euc_kr_to_utf8 | EUC_KR | UTF8 |
euc_tw_to_big5 | EUC_TW | BIG5 |
euc_tw_to_mic | EUC_TW | MULE_INTERNAL |
euc_tw_to_utf8 | EUC_TW | UTF8 |
gb18030_to_utf8 | GB18030 | UTF8 |
gbk_to_utf8 | GBK | UTF8 |
iso_8859_10_to_utf8 | LATIN6 | UTF8 |
iso_8859_13_to_utf8 | LATIN7 | UTF8 |
iso_8859_14_to_utf8 | LATIN8 | UTF8 |
iso_8859_15_to_utf8 | LATIN9 | UTF8 |
iso_8859_16_to_utf8 | LATIN10 | UTF8 |
iso_8859_1_to_mic | LATIN1 | MULE_INTERNAL |
iso_8859_1_to_utf8 | LATIN1 | UTF8 |
iso_8859_2_to_mic | LATIN2 | MULE_INTERNAL |
iso_8859_2_to_utf8 | LATIN2 | UTF8 |
iso_8859_2_to_windows_1250 | LATIN2 | WIN1250 |
iso_8859_3_to_mic | LATIN3 | MULE_INTERNAL |
iso_8859_3_to_utf8 | LATIN3 | UTF8 |
iso_8859_4_to_mic | LATIN4 | MULE_INTERNAL |
iso_8859_4_to_utf8 | LATIN4 | UTF8 |
iso_8859_5_to_koi8_r | ISO_8859_5 | KOI8R |
iso_8859_5_to_mic | ISO_8859_5 | MULE_INTERNAL |
iso_8859_5_to_utf8 | ISO_8859_5 | UTF8 |
iso_8859_5_to_windows_1251 | ISO_8859_5 | WIN1251 |
iso_8859_5_to_windows_866 | ISO_8859_5 | WIN866 |
iso_8859_6_to_utf8 | ISO_8859_6 | UTF8 |
iso_8859_7_to_utf8 | ISO_8859_7 | UTF8 |
iso_8859_8_to_utf8 | ISO_8859_8 | UTF8 |
iso_8859_9_to_utf8 | LATIN5 | UTF8 |
johab_to_utf8 | JOHAB | UTF8 |
koi8_r_to_iso_8859_5 | KOI8R | ISO_8859_5 |
koi8_r_to_mic | KOI8R | MULE_INTERNAL |
koi8_r_to_utf8 | KOI8R | UTF8 |
koi8_r_to_windows_1251 | KOI8R | WIN1251 |
koi8_r_to_windows_866 | KOI8R | WIN866 |
koi8_u_to_utf8 | KOI8U | UTF8 |
mic_to_big5 | MULE_INTERNAL | BIG5 |
mic_to_euc_cn | MULE_INTERNAL | EUC_CN |
mic_to_euc_jp | MULE_INTERNAL | EUC_JP |
mic_to_euc_kr | MULE_INTERNAL | EUC_KR |
mic_to_euc_tw | MULE_INTERNAL | EUC_TW |
mic_to_iso_8859_1 | MULE_INTERNAL | LATIN1 |
mic_to_iso_8859_2 | MULE_INTERNAL | LATIN2 |
mic_to_iso_8859_3 | MULE_INTERNAL | LATIN3 |
mic_to_iso_8859_4 | MULE_INTERNAL | LATIN4 |
mic_to_iso_8859_5 | MULE_INTERNAL | ISO_8859_5 |
mic_to_koi8_r | MULE_INTERNAL | KOI8R |
mic_to_sjis | MULE_INTERNAL | SJIS |
mic_to_windows_1250 | MULE_INTERNAL | WIN1250 |
mic_to_windows_1251 | MULE_INTERNAL | WIN1251 |
mic_to_windows_866 | MULE_INTERNAL | WIN866 |
sjis_to_euc_jp | SJIS | EUC_JP |
sjis_to_mic | SJIS | MULE_INTERNAL |
sjis_to_utf8 | SJIS | UTF8 |
windows_1258_to_utf8 | WIN1258 | UTF8 |
uhc_to_utf8 | UHC | UTF8 |
utf8_to_big5 | UTF8 | BIG5 |
utf8_to_euc_cn | UTF8 | EUC_CN |
utf8_to_euc_jp | UTF8 | EUC_JP |
utf8_to_euc_kr | UTF8 | EUC_KR |
utf8_to_euc_tw | UTF8 | EUC_TW |
utf8_to_gb18030 | UTF8 | GB18030 |
utf8_to_gbk | UTF8 | GBK |
utf8_to_iso_8859_1 | UTF8 | LATIN1 |
utf8_to_iso_8859_10 | UTF8 | LATIN6 |
utf8_to_iso_8859_13 | UTF8 | LATIN7 |
utf8_to_iso_8859_14 | UTF8 | LATIN8 |
utf8_to_iso_8859_15 | UTF8 | LATIN9 |
utf8_to_iso_8859_16 | UTF8 | LATIN10 |
utf8_to_iso_8859_2 | UTF8 | LATIN2 |
utf8_to_iso_8859_3 | UTF8 | LATIN3 |
utf8_to_iso_8859_4 | UTF8 | LATIN4 |
utf8_to_iso_8859_5 | UTF8 | ISO_8859_5 |
utf8_to_iso_8859_6 | UTF8 | ISO_8859_6 |
utf8_to_iso_8859_7 | UTF8 | ISO_8859_7 |
utf8_to_iso_8859_8 | UTF8 | ISO_8859_8 |
utf8_to_iso_8859_9 | UTF8 | LATIN5 |
utf8_to_johab | UTF8 | JOHAB |
utf8_to_koi8_r | UTF8 | KOI8R |
utf8_to_koi8_u | UTF8 | KOI8U |
utf8_to_sjis | UTF8 | SJIS |
utf8_to_windows_1258 | UTF8 | WIN1258 |
utf8_to_uhc | UTF8 | UHC |
utf8_to_windows_1250 | UTF8 | WIN1250 |
utf8_to_windows_1251 | UTF8 | WIN1251 |
utf8_to_windows_1252 | UTF8 | WIN1252 |
utf8_to_windows_1253 | UTF8 | WIN1253 |
utf8_to_windows_1254 | UTF8 | WIN1254 |
utf8_to_windows_1255 | UTF8 | WIN1255 |
utf8_to_windows_1256 | UTF8 | WIN1256 |
utf8_to_windows_1257 | UTF8 | WIN1257 |
utf8_to_windows_866 | UTF8 | WIN866 |
utf8_to_windows_874 | UTF8 | WIN874 |
windows_1250_to_iso_8859_2 | WIN1250 | LATIN2 |
windows_1250_to_mic | WIN1250 | MULE_INTERNAL |
windows_1250_to_utf8 | WIN1250 | UTF8 |
windows_1251_to_iso_8859_5 | WIN1251 | ISO_8859_5 |
windows_1251_to_koi8_r | WIN1251 | KOI8R |
windows_1251_to_mic | WIN1251 | MULE_INTERNAL |
windows_1251_to_utf8 | WIN1251 | UTF8 |
windows_1251_to_windows_866 | WIN1251 | WIN866 |
windows_1252_to_utf8 | WIN1252 | UTF8 |
windows_1256_to_utf8 | WIN1256 | UTF8 |
windows_866_to_iso_8859_5 | WIN866 | ISO_8859_5 |
windows_866_to_koi8_r | WIN866 | KOI8R |
windows_866_to_mic | WIN866 | MULE_INTERNAL |
windows_866_to_utf8 | WIN866 | UTF8 |
windows_866_to_windows_1251 | WIN866 | WIN |
windows_874_to_utf8 | WIN874 | UTF8 |
euc_jis_2004_to_utf8 | EUC_JIS_2004 | UTF8 |
utf8_to_euc_jis_2004 | UTF8 | EUC_JIS_2004 |
shift_jis_2004_to_utf8 | SHIFT_JIS_2004 | UTF8 |
utf8_to_shift_jis_2004 | UTF8 | SHIFT_JIS_2004 |
euc_jis_2004_to_shift_jis_2004 | EUC_JIS_2004 | SHIFT_JIS_2004 |
shift_jis_2004_to_euc_jis_2004 | SHIFT_JIS_2004 | EUC_JIS_2004 |
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