Как изменить кодировку консоли visual studio

Как изменить кодировку в консоли Visual Studio 2017

Сразу хочу оговориться, что меня не интересуют команды типа setlocale(); SetConsoleCP(); и подобные. Если вы хотите предложить вариант как-то связанный с программным исправлением (с добавлением строк кода по исправлению кодировки к каждой программе), пожалуйста, не надо. Меня интересует, как изменить параметр «Текущая кодовая страница», который сейчас выставлен в свойствах консоли на 866 ?
И желательно изменить один раз, чтобы он выставлялся по умолчанию.

Отслеживать
user262779
задан 23 мар 2018 в 0:49
Simon Gerasimenko Simon Gerasimenko
133 1 1 серебряный знак 9 9 бронзовых знаков

Кодовая страница консоли не является свойством Visual Studio. Ее можно изменить на уровне ОС установкой определенных ключей реестра: superuser.com/questions/269818/… (но не нужно, так как неизвестно, что от этого сломается)

23 мар 2018 в 5:08

@MSDN.WhiteKnight В этом вопросе речь о консоли Windows. В консоли windows у меня кодировка 1251. В консоли студии — 866.

23 мар 2018 в 8:32

Никакого понятия «консоль студии» не существует. Решение по ссылке в чистом виде к вам действительно не применимо, оно требует дополнительно в свойствах проекта в разделе отладка установить параметры Команда: c:\windows\system32\cmd.exe и Аргументы: /k $(TargetPath)

23 мар 2018 в 9:08

@MSDN.WhiteKnight Да, теперь моя программа запускается в консоли windows. После завершения программы консоль продолжает работать (ожидает команды), из чего я могу сделать вывод, что для Visual Studio используется нечто другое (вполне вероятно, связанное с консолью windows, т.к. до этого даже значок был другой). Всё таки, можно ли настроить аргументами без команд (чтобы программа открывалась тем, чем открывалась до этого) кодовую страницу этого «нечто другого»?

23 мар 2018 в 9:59
У вас Windows 10?
23 мар 2018 в 10:13

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

На самом деле, кодовая страница для консольных приложений не является настройкой, которую можно изменить через Visual Studio. Дело в том, что не существует никакой «консоли Visual Studio» — при запуске консольного приложения из студии используется самая обычная консоль ОС, та же самая, что и для cmd.exe или любого другого консольного приложения (она может отличаться внешне, в зависимости от настроек, но суть та же). Кодовую страницу для нее можно задать:

На уровне ОС, установкой определенных ключей реестра
В конкретном сеансе командной оболочки, выполнением команды chcp 1251 . Таким образом, можно изменить действие при запуске приложения (в разделе «Отладка» в свойствах проекта) на c:\windows\system32\cmd.exe /k chcp 1251 && $(TargetPath) для достижения требуемого эффекта. Но тогда отладчик будет отлаживать cmd.exe, а не нашу программу 🙁
Для конкретного консольного приложения через параметр реестра HKCU\Console\(путь к приложению)\CodePage (REG_DWORD).

Используя последний способ и шаблоны проектов, можно автоматизировать установку кодовой страницы для приложений, собираемых в студии.

set MYSTRING=%~1 reg add "HKCU\Console\%MYSTRING:\=_%" /v CodePage /t REG_DWORD /f /d 1251

Поместим его, допустим, в папку c:\scripts\codepage.bat

Создадим проект консольного приложения под шаблон, допустим Cp1251ConsoleApplication
В свойствах проекта, в разделе События построения — Событие после построения, введем в параметр Командная строка значение:

c:\scripts\codepage.bat "$(TargetPath)"

Теперь при создании нового проекта в в разделе Visual C++ появится шаблон Cp1251ConsoleApplication. Если создавать проект на его основе, при сборке проекта в реестре автоматически будет устанавливаться кодовая страница консоли для этого приложения. Недостаток способа в том, что этот раздел реестра будет замусориваться, если создавать много проектов.

Также, при задействовании команды Запуск без отладки способ не сработает: вместо вашего приложения будет запускаться cmd.exe; для него кодовая страница настраивается отдельно — созданием точно такой же ветки в реестре с путем к cmd.exe.

Гарантированная локализация/русификация консоли Windows

Консольные приложения до сих пор остаются наиболее востребованным видом приложений, большинство разработчиков оттачивают архитектуру и бизнес-логику именно в консоли. При этом они нередко сталкиваются с проблемой локализации — русский текст, который вполне адекватно отражается в исходном файле, при выводе на консоль приобретает вид т.н. «кракозябр».

В целом, локализация консоли Windows при наличии соответствующего языкового пакета не представляется сложной. Тем не менее, полное и однозначное решение этой проблемы, в сущности, до сих пор не найдено. Причина этого, главным образом, кроется в самой природе консоли, которая, являясь компонентом системы, реализованным статическим классом System.Console, предоставляет свои методы приложению через системные программы-оболочки, такие как командная строка или командный процессор (cmd.exe), PowerShell, Terminal и другие.
По сути, консоль находится под двойным управлением — приложения и оболочки, что является потенциально конфликтной ситуацией, в первую очередь в части использования кодировок.

Данный материал не предлагает строгий алгоритм действий, а направлен на описание узловых проблем, с которыми неизбежно сталкивается разработчик локализованного консольного приложения, а также некоторые возможные пути их разрешения. Предполагается, что это позволит разработчику сформировать стратегию работы с локализованной консолью и эффективно реализовать существующие технические возможности, большая часть которых хорошо описана и здесь опущена.

Виды консолей

В общем случае функции консоли таковы:

управление операционной системой и системным окружением приложений на основе применения стандартных системных устройств ввода-вывода (экран и клавиатура), использования команд операционной системы и/или собственно консоли;
запуск приложений и обеспечение их доступа к стандартным потокам ввода-вывода системы, также с помощью стандартных системных устройств ввода-вывода.

Основная консоль Windows — командная строка или иначе командный процессор ( CMD ). Большие возможности предоставляют оболочки PowerShell ( PS ), Windows PowerShell ( WPS ) и Terminal. По умолчанию Windows устанавливает Windows Power Shell мажорной версией до 5, однако предлагает перейти на новую версию — 7-ку, имеющую принципиальное отличие (вероятно, начинающееся с 6-ки) — кроссплатформенность. Terminal — также отдельно уставливаемое приложение, по сути интегратор всех ранее установленных оболочек PowerShell и командной строки.

Отдельным видом консоли можно считать консоль отладки Visual Studio ( CMD-D ).

Конфликт кодировок

Полностью локализованная консоль в идеале должна поддерживать все мыслимые и немыслимые кодировки приложений, включая свои собственные команды и команды Windows, меняя «на лету» кодовые страницы потоков ввода и вывода. Задача нетривиальная, а иногда и невозможная — кодовые страницы DOS (CP437, CP866) плохо совмещаются с кодовыми страницами Windows и Unicode.

Исторически кодовой страницей Windows является CP1251 (Windows-1251, ANSI, Windows-Cyr), уверенно вытесняемая 8-битной кодировкой Юникода CP65001 (UTF-8, Unicode Transformation Format), в которой выполняется большинство современных приложений, особенно кроссплатформенных. Между тем, в целях совместимости с устаревшими файловыми системами, именно в консоли Windows сохраняет базовые кодировки DOS — CP437 (DOSLatinUS, OEM) и русифицированную CP866 (AltDOS, OEM).

Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8. Мир любит Юникод, а кроссплатформенность без него вообще невозможна.

Совет 2. Периодически проверять кодировку, например в текстовом редакторе Notepad++. Visual Studio может сбивать кодировку, особенно при редактировании за пределами VS.

Поскольку в консоли постоянно происходит передача управления от приложений к собственно командному процессору и обратно, регулярно возникает «конфликт кодировок», наглядно иллюстрируемый таблица 1 и 2, сформированных следующим образом:

Были запущены три консоли — CMD , PS и WPS . В каждой консоли менялась кодовая страница с помощью команды CHCP, выполнялась команда Echo c двуязычной строкой в качестве параметра (табл. 1), а затем в консоли запускалось тестовое приложение, исходные файлы которого были созданы в кодировке UTF-8 (CP65001): первая строка формируется и направляется в поток главным модулем, вторая вызывается им же, формируется в подключаемой библиотеке классов и направляется в поток опять главным модулем, третья строка полностью формируется и направляется в поток подключаемой библиотекой.

Команды и код приложения под катом

> Echo ffffff фффффф // в командной строке
PS> Echo ffffff фффффф // в PowerShell
PS> Echo ffffff . // так выглядит та же команда в Windows PowerShell

код тестового приложения:

using System; using ova.common.logging.LogConsole; using Microsoft.Extensions.Logging; using ova.common.logging.LogConsole.Colors; namespace LoggingConsole.Test < partial class Program < static void Main2(string[] args) < ColorLevels.ColorsDictionaryCreate(); Console.WriteLine("Hello World! Привет, мир!"); //вывод строки приветствия на двух языках LogConsole.Write("Лог из стартового проекта", LogLevel.Information); Console.WriteLine($"8. Active codepage: input , output "); Console.ReadKey(); > > >

Командную часть задания все консоли локализовали практически без сбоев во всех кодировках, за исключением: в WPS неверно отображена русскоязычная часть команды во всех кодировках.

Табл. 1. Результат выполнения команды консоли Echo ffffff фффффф

Вывод тестового приложения локализован лишь в 50% испытаний, как показано в табл.2.

Табл. 2. Результат запуска приложения LoggingConsole.Test

Сoвет 3. Про PowerShell забываем раз и навсегда. Ну может не навсегда, а до следующей мажорной версии.

По умолчанию Windows устанавливает для консоли кодовые страницы DOS. Чаще всего CP437, иногда CP866. Актуальные версии командной строки cmd.exe способны локализовать приложения на основе русифицированной кодовой страницы 866, но не 437, отсюда и изначальный конфликт кодировок консоли и приложения. Поэтому

Совет 4. Перед запуском приложения необходимо проверить кодовую страницу консоли командой CHCP и ей же изменить кодировку на совместимую — 866, 1251, 65001.

Совет 5. Можно установить кодовую страницу консоли по умолчанию. Кратко: в разделе реестра \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor добавить или изменить значение параметра Autorun на: chcp . Очень подробно здесь: Изменить кодовую страницу консоли Windows по умолчанию на UTF-8 (qastack.ru), оригинал на английском здесь: Change default code page of Windows console to UTF-8.

Проблемы консолей Visual Studio

В Visual Studio имеется возможность подключения консолей, по умолчанию подключены командная строка для разработчика и Windows PowerShell для разработчика. К достоинствам можно отнести возможности определения собственных параметров консоли, отдельных от общесистемных, а также запуск консоли непосредственно в директории разработки. В остальном — это обычные стандартные консоли Windows, включая, как показано ранее, установленную кодовую страницу по умолчанию.

Отдельной опцией Visual Studio является встроенная односеансная консоль отладки, которая перехватывает команду Visual Studio на запуск приложения, запускается сама, ожидает компиляцию приложения, запускает его и отдает ему управление. Таким образом, отладочная консоль в течение всего рабочего сеанса находится под управлением приложения и возможность использования команд Windows или самой консоли, включая команду CHCP, не предусмотрена. Более того, отладочная консоль не воспринимает кодовую страницу по умолчанию, определенную в реестре, и всегда запускается в кодировке 437 или 866.

Совет 6. Тестирование приложения целесообразно выполнять во внешних консолях, более дружелюбных к локализации.

Анализ проблем консолей был бы не полон без ответа на вопрос — можно ли запустить консольное приложение без консоли? Можно — любой файл «.exe» запустится двойным кликом, и даже откроется окно приложения. Однако консольное приложение, по крайней мере однопоточное, по двойному клику запустится, но консольный режим не поддержит — все консольные вводы-выводы будут проигнорированы, и приложение завершится

Локализация отладочной консоли Visual Studio

Отладочная консоль — наиболее востребованная консоль разработчика, гораздо более удобная, чем внешняя консоль, поэтому резонно приложить максимум усилий для ее локализации.

На самом деле, правильнее говорить о локализации приложения в консоли — это важное уточнение. Microsoft по этому поводу высказывается недвусмысленно: «Programs that you start after you assign a new code page use the new code page. However, programs (except Cmd.exe) that you started before assigning the new code page will continue to use the original code page». Иными словами, консоль можно локализовать когда угодно и как угодно, но приложение будет локализовано в момент стабилизации взаимодействия с консолью в соответствии с текущей локализацией консоли, и эта локализация сохранится до завершения работы приложения. В связи с этим возникает вопрос — в какой момент окончательно устанавливается связь консоли и приложения?

Важно! Приложение окончательно стабилизирует взаимодействие с консолью в момент начала ввода-вывода в консоль, благодаря чему и появляется возможность программного управления локализацией приложения в консоли — до первого оператора ввода-вывода.

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

F:\LoggingConsole.Test\bin\Release\net5.0>chcp Active code page: 1251 F:\LoggingConsole.Test\bin\Release\net5.0>loggingconsole.test Codepages: current 1251:1251, setted 437:437, ΓΓεΣΦ∞ 5 ±Φ∞ΓεδεΓ ∩ε-≡≤±±ΩΦ: Θ÷≤Ωσ=Θ÷≤Ωσ Codepages: current 437:437, setted 65001:65001, 5 -: = Codepages: current 65001:65001, setted 1252:1252, ââîäèì 5 ñèìâîëîâ ïî-ðóññêè: éöóêå=éöóêå Codepages: current 1252:1252, setted 1251:1251, вводим 5 символов по-русски: йцуке=йцуке Codepages: current 1251:1251, setted 866:866, ттюфшь 5 ёшьтюыют яю-Ёєёёъш: щЎєъх=щЎєъх Codepages: current 866:866, setted 1251:1251, вводим 5 символов по-русски: йцуке=йцуке Codepages: current 1251:1251, setted 1252:1252, ââîäèì 5 ñèìâîëîâ ïî-ðóññêè: éöóêå=éöóêå F:\LoggingConsole.Test\bin\Release\net5.0>chcp Active code page: 1252

приложение запущено в консоли с кодовыми страницами 1251 (строка 2);
приложение меняет кодовые страницы консоли (current, setted);
приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);
по окончании работы приложения изменения консоли сохраняются (строка 14 — Active codepage 1252);
Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).

using System; using System.Runtime.InteropServices; namespace LoggingConsole.Test < partial class Program < [DllImport("kernel32.dll")] static extern uint GetConsoleCP(); [DllImport("kernel32.dll")] static extern bool SetConsoleCP(uint pagenum); [DllImport("kernel32.dll")] static extern uint GetConsoleOutputCP(); [DllImport("kernel32.dll")] static extern bool SetConsoleOutputCP(uint pagenum); static void Main(string[] args) < Write(437); Write(65001); Write(1252); Write(1251); Write(866); Write(1251); Write(1252); >static internal void Write(uint WantedIn, uint WantedOut) < uint CurrentIn = GetConsoleCP(); uint CurrentOut = GetConsoleOutputCP(); Console.Write($"current : - текущая кодировка, "); /*wanted :,*/ SetConsoleCP(WantedIn); SetConsoleOutputCP(WantedOut); Console.Write($"setted : - новая кодировка, "); Console.Write($"вводим 3 символа по-русски: "); string str = "" + Console.ReadKey().KeyChar.ToString(); str += Console.ReadKey().KeyChar.ToString(); str += Console.ReadKey().KeyChar.ToString(); Console.WriteLine($"="); > static internal void Write(uint ChangeTo) < Write(ChangeTo, ChangeTo); >> >

Программное управление кодировками консоли — это единственный способ гарантированной адекватной локализацией приложения в консоли. Языки .Net такой возможности не предоставляют, однако предоставляют функции WinAPI: SetConsoleCP(uint numcp) и SetConsoleOutputCP(uint numcp), где numcp — номер кодовой страницы потоков ввода и вывода соответственно. Подробнее здесь: Console Functions — Windows Console | Microsoft Docs. Пример применения консольных функций WInAPI можно посмотреть в тестовом приложении под катом выше.

Совет 7. Обязательный и повторный! Функции SetConsoleCP должны размещаться в коде до первого оператора ввода-вывода в консоль.

Стратегия локализации приложения в консоли

Удалить приложение PowerShell (если установлено), сохранив Windows PowerShell;
Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5;
Разработку приложений выполнять в кодировке utf-8 Unicode;
Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad++;
Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:

using System; using System.Runtime.InteropServices; namespace LoggingConsole.Test < partial class Program < static void Main(string[] args) < [DllImport("kernel32.dll")] static extern bool SetConsoleCP(uint pagenum); [DllImport("kernel32.dll")] static extern bool SetConsoleOutputCP(uint pagenum); SetConsoleCP(65001); //установка кодовой страницы utf-8 (Unicode) для вводного потока SetConsoleOutputCP(65001); //установка кодовой страницы utf-8 (Unicode) для выводного потока Console.WriteLine($"Hello, World!"); >> >

Помощь

Проблемы с кодировками MySQL могут возникать для версий 4.1 и выше, поскольку для них введена возможность задания разной кодировки для разных уровней иерархии базы данных (сервер, база данных, таблица, столбец) и отдельно для соединения сервера с клиентом. По умолчанию MySQL имеет кодировку latin1 на всех уровнях.

Кодировка, в которой хранятся данные на сервере MySQL, должна совпадать с кодировкой самих данных. Например, для русских символов используется кодировка cp1251. Если в таблице будут храниться записи русскими буквами, то и кодировка этой таблицы должна быть задана cp1251, иначе отображаться будут не русские символы, а знаки вопроса или другие знаки.

При создании баз данных сразу указывайте кодировку для хранения символов, поскольку в случае отсутствия явно заданной кодировки будет использовано значение по умолчанию (latin1). Например, создавайте базу данных командой:

create database `my-db` default charset cp1251;

Кодировка соединения сервера с клиентом устанавливает, в каком виде будут передаваться данные между ними. Например, если в скрипте на сайте используются русские символы, то при обращении сайта к базе данных MySQL должен правильно распознать эти символы, чтобы корректно выполнить скрипт. Если кодировка соединения использует значение по умолчанию latin1, то русские символы сервер баз данных не сможет правильно распознать, следовательно, скрипт выполнится с ошибкой.

Установите нужную вам кодировку соединения сразу после подключения к серверу MySQL запросом:

set names cp1251

Существует ряд клиентов, которые не могут установить нужную кодировку, имеют свою собственную. Для подобных случаев внесите в файл my.cnf в секцию [mysqld] строку:

set init_connect="set names cp1251" где cp1251 – это нужная вам кодировка.

В этом случае сервер выполнит команду «set names cp1251» сразу после соединения с клиентом и установит указанную в запросе кодировку.

Самые распространенные в России кодировки следующие:

utf8, cp866 (DOS), cp1251 (Windows), koi8r

Установка и использование на всех уровнях сервера баз данных одинаковой кодировки устраняет 90% проблем с кодировкой в MySQL.

Как русифицировать MySQL?

Внесите следующие изменения в файл my.cnf:

[client] default-character-set=cp1251 [mysqld] character-set-server=cp1251 collation-server=cp1251_general_ci init-connect = "set names cp1251"

Перезапустите MySQL сервер.

Вывод Unicode строки в Windows

Добрый день. Не понимаю, как правильно в Windows вывести строку с русскими буквами. Без юникода, понятно, выводятся странные символы.

В итоге в настройках проекта Visual Studio выбрал Use Unicode character set, пишу такой код:

include include int main(int argc, _TCHAR** argv) < cout

Но при запуске этого кода в виндоусовской консоли, она выводит и не странные символы и не русскую фразу «Работа завершена», а вообще какой-то шестнадцатеричный код 00F84208

Подскажите пожалуйста, в чем причина? Может дело в кодировке вывода самой консоли? Хотя системные сообщения Windows она исправно на русском пишет.

Zhenek91
03.11.15 11:42:01 MSK arkadij-smirnov
( 03.11.15 11:45:16 MSK ) anonymous
( 03.11.15 11:45:29 MSK )

Шindows cannot into Unicode. Deal with it.

Lincor ☆
( 03.11.15 11:49:24 MSK ) Ответ на: комментарий от anonymous 03.11.15 11:45:29 MSK

вопрос про виндовс

arkadij-smirnov
( 03.11.15 11:52:52 MSK )

Походу линукс тут не причем, кодировка в cmd винды 866.

ilovewindows ★★★★★
( 03.11.15 11:52:56 MSK )
Последнее исправление: ilovewindows 03.11.15 11:54:32 MSK (всего исправлений: 1)

Ответ на: комментарий от arkadij-smirnov 03.11.15 11:52:52 MSK anonymous
( 03.11.15 12:04:57 MSK ) anonymous
( 03.11.15 12:06:57 MSK ) Ответ на: комментарий от anonymous 03.11.15 12:04:57 MSK

В любом случае этот вопрос лучше задать на специализированном форуме

arkadij-smirnov
( 03.11.15 12:07:59 MSK ) Ответ на: комментарий от arkadij-smirnov 03.11.15 12:07:59 MSK Zhenek91
( 03.11.15 12:09:39 MSK ) автор топика x3al ★★★★★
( 03.11.15 12:14:55 MSK )

chcp 65001 и поставь юникодный шрифт в терминале

annulen ★★★★★
( 03.11.15 14:16:24 MSK )

#include setlocale (LC_ALL,"Russian");

~~sudopacman~~ ★★★★★
( 03.11.15 16:17:32 MSK )
Ответ на: комментарий от annulen 03.11.15 14:16:24 MSK

Не очень здорово, если требуется переносимость, на каждом профиле придётся ручками ставить этот шрифт. Лучше, если есть возможность, под 866 кодировку приспособиться.

Dreamject ★
( 03.11.15 16:33:46 MSK )
Ответ на: комментарий от Dreamject 03.11.15 16:33:46 MSK

Для переносимости как раз лучше utf8 использовать, а не подстраиваться под ущербные системы 🙂

annulen ★★★★★
( 03.11.15 17:05:15 MSK )
Ответ на: комментарий от annulen 03.11.15 17:05:15 MSK

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

Dreamject ★
( 03.11.15 17:13:39 MSK )

Может дело в кодировке вывода самой консоли?

Именно так. В винде в консоли однобайтная кодировка, зависящая от локали, но отличающаяся от Юникода и от однобайтной кодировки для функций Windows API. Для русской версии Винды это CP866. Попробуй переключить консоль на UTF-8: https://stackoverflow.com/questions/388490/unicode-characters-in-windows-comm.

proud_anon ★★★★★
( 03.11.15 20:26:29 MSK )
Ответ на: комментарий от annulen 03.11.15 17:05:15 MSK

Для переносимости как раз лучше utf8 использовать, а не подстраиваться под ущербные системы 🙂

Переносимого способа выводить юникод в консоль нет.

x3al ★★★★★
( 03.11.15 20:35:54 MSK )
Ответ на: комментарий от Dreamject 03.11.15 16:33:46 MSK

Вот почему в каждой теме «юникод в виндовой консоли» кто-нибудь обязательно влезет с CP866? Виндовый эмулятор терминала юникоден и умеет в UTF-16, но нет, нужно пользоваться legacy, тянущимся уже фиг знает сколько лет.

x3al ★★★★★
( 03.11.15 20:37:16 MSK )
Ответ на: комментарий от proud_anon 03.11.15 20:26:29 MSK

В винде в консоли однобайтная кодировка, зависящая от локали, но отличающаяся от Юникода и от однобайтной кодировки для функций Windows API. Для русской версии Винды это CP866.

В общем случае она ничерта не однобайтная, поскольку в моей консоли спокойно отображаются иероглифы. CP65001 — фигово поддерживаемое решение, поскольку все остальные виндовые утилиты, даже те, что умеют в юникод (UTF-16 без всяких chcp), будут странно работать: chcp попутно меняет язык отображения.

x3al ★★★★★
( 03.11.15 20:42:08 MSK )
Ответ на: комментарий от x3al 03.11.15 20:42:08 MSK

В общем случае она ничерта не однобайтная, поскольку в моей консоли спокойно отображаются иероглифы.

Да, правильно. Следовало сказать: «кодировка, отличная от Юникода».

proud_anon ★★★★★
( 03.11.15 20:56:48 MSK )
Ответ на: комментарий от x3al 03.11.15 20:37:16 MSK

Виндовый эмулятор терминала юникоден и умеет в UTF-16, но нет, нужно пользоваться legacy, тянущимся уже фиг знает сколько лет.

Речь ведь о шрифте, если ты Лусиду или что-то юникодное, а не пиксельный дефолт, не выберешь, то даже при правильной кодировке будет херня.

Dreamject ★
( 03.11.15 21:08:31 MSK )
Ответ на: комментарий от Dreamject 03.11.15 21:08:31 MSK

Местный эмулятор терминала умеет отображать юникод даже с пиксельным дефолтом.

x3al ★★★★★
( 03.11.15 21:10:45 MSK )
Ответ на: комментарий от x3al 03.11.15 21:10:45 MSK

Dreamject ★
( 03.11.15 21:22:42 MSK )
Ответ на: комментарий от x3al 03.11.15 21:10:45 MSK

Dreamject ★
( 03.11.15 21:32:16 MSK )
Ответ на: комментарий от Dreamject 03.11.15 21:32:16 MSK

chcp — жуткий костыль и не нужно. На какой чёрт тебе менять кодировку для legacy-софта, не умеющего в юникод, если можно нативным способом писать в UTF-16 независимо от того, на что там сменили кодировку?

x3al ★★★★★
( 03.11.15 21:38:58 MSK )
Ответ на: комментарий от x3al 03.11.15 21:38:58 MSK

Как? Можешь пример батника?

Dreamject ★
( 03.11.15 22:19:01 MSK )
Ответ на: комментарий от Dreamject 03.11.15 22:19:01 MSK

Берёшь http://www.madore.org/~david/misc/unitest/ и сохраняешь как UTF-16 текст. Делаешь type (cmd) или gc (он же cat) в powershell, убеждаешься, что chcp нафиг не нужен.

WriteConsoleW если нужно в C.

*.bat — наследие времён DOS, не упоминай это к ночи. Пишешь что угодно в ps1-файл, сохраняешь как UTF-16 текст и запускаешь мощношеллом, получаешь юникод в том же окне connhost'а, что и cmd.exe и с тем же дефолтным растровым шрифтом в пределах его возможностей. Возможности шрифта (допустимые символы), конечно, зависят от кодировки, но пока ты в ней — никакие chcp не нужны.

x3al ★★★★★
( 03.11.15 23:12:40 MSK )
Последнее исправление: x3al 03.11.15 23:13:44 MSK (всего исправлений: 1)

Читать:

Как перевести int в char java