Как поменять язык в командной строке

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

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

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

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

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

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

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

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

Отдельным видом консоли можно считать консоль отладки 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, сформированных следующим образом:

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

> Echo ffffff фффффф // в командной строке

PS> Echo ffffff фффффф // в PowerShell

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

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

Командную часть задания все консоли локализовали практически без сбоев во всех кодировках, за исключением: в 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 получает номера текущих страниц, устанавливает новые кодовые страницы вводного и выводного потоков, выполняет чтение с консоли и записывает выводную строку, содержащий русский текст, в том числе считанный с консоли, обратно в консоль. Операция повторяется несколько раз для всех основных кодовых страниц, упомянутых ранее.

приложение запущено в консоли с кодовыми страницами 1251 (строка 2);

приложение меняет кодовые страницы консоли (current, setted);

приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);

по окончании работы приложения изменения консоли сохраняются (строка 14 — Active codepage 1252);

Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).

Программное управление кодировками консоли — это единственный способ гарантированной адекватной локализацией приложения в консоли. Языки .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++;

Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:

Englishize Cmd — Change Non-English Command Line Interface to English Fast

There often comes a need to use built-in command-line tools in English in non-English Windows, as they are localized to another language which can be difficult for admins who only speak English. ‘Englishize Cmd’ employs a different technique to ‘englishize’ CLI tools with a click.

[Go to Download]

Also on Chocolatey: choco install englishizecmd / winget: winget install englishizecmd

Figure 1. Bilingual command prompt: Upper has Englishize Cmd applied (changed to English); lower has it restored (to original language).

[2019–05–13] Update: As reported by a German user (thanks), some en-US files (e.g. ipconfig.exe.mui) are not included in the German release of Windows 10 since 1809. This doesn’t seem to affect other countries or regions. For details and workarounds, refer to this comment.

[2021–03–27] Update: Continued from the above, another German user reported an issue with the German 2004 version of Windows 10. In German Windows 10 2004, not only those files do not exist, but that putting the files back do not work. Again, this doesn’t seem to affect other countries or regions. For a workaround, refer to this GitHub issue.

List of Features

1. Toggles between English and non-English for many Windows commands
2. For English system admins who manages Windows PCs of other languages
3. No need to log off; settings are appled immediately
4. Comes with a restorer. Apply or restore is as simple as a click or typing EnglishizeCmd and RestoreCmd commands
5. Better character compatibility than changing DOS codepage
6. Many languages and executables are supported. Customizable
7. Ensure the outputs which your scripts catch are always in English
8. Administrator rights are required. It asks for rights to elevates itself (Does not elevate over network mapped drives)
9. Parameter /quiet can be used to suppress confirmation messages for unattended usage. (Only works when existing Command Prompt is run elevated)
10. Supports Windows Vista and later, as well as their server versions only, including Windows 10 or Windows Server 2019
11. Portable by default. Optional installer enables EnglishizeCmd and RestoreCmd commands globally in Command Prompt and Run prompt. (The commands including the extensions would be EnglishizeCmd.bat and RestoreCmd.bat )

Background

Occasionally, there comes a need to use built-in command-line tools in English in non-English Windows, as they are localized to another language which can be difficult to use for system administrators who only speak English. There are a number of workarounds focusing around entering chcp 437 , which is the English codepage, prior to running a command. Or, creating a shortcut to cmd.exe and setting in its properties the “Current Codepage” setting to 437.

Figure 2. 437 = English codepage

Unfortunately, both methods could make non-English characters non-displayable (becoming questions marks . as shown in the picture below). In addition, the former method requires typing chcp 437 every time (although it can be configured to automatically do so in “HKLM\SOFTWARE\Microsoft\Command Processor\AutoRun” registry key), while the latter is limited to shortcuts. So I thought it would be useful to share this method which employs a different technique.

Figure 3. Changing codepage turns non-English characters into question marks

For command line programs, Non-English versions of Windows Vista and later actually ship with both English and non-English MUIs (Multilingual User Interface). That means if we cannot get used to command line interface being localized and shown in non-English (e.g. Chinese Taiwan, i.e. zh-TW), in some simpler way we must be able to set it to English without totally switching to a English user account in Regional Options then reboot the PC. (BTW, non-Ultimate/non-Enterprise editions of Windows does not officially allow installing MUI).

Concept (Temporary Language File Renaming)

Investigation using Sysinternals Process Monitor reveals that, whenever Windows fails to locate a .exe.mui file in any zh-TW directory, it falls back to locating the .exe.mui in en-US. Comes the concept of Englishize Cmd: Why not temporarily rename the .mui file in zh-TW to something else so that it just falls back to using the one in en-US? Now it has been confirmed the technique works, except that it is a lot of work deciding which system files can be renamed, unprotecting those files as they are protected by WRP (Windows Resource Protection), renaming every single command-line executable… Comes “Englishize Cmd” for this. “Englishize Cmd” is a simple customizable program (batch script) written to automate this tiresome process so that changing back and forth from English to non-English is easier.

Figure 4. Upper: EnglishizeCmd.bat; lower: RestoreCmd.bat

Instructions

“Englishize Cmd” comes with 4 files:

1. “EnglishizeCmd.bat” for changing command line tools from non-English to English.

2. “RestoreCmd.bat” to restore everything back to original language, including original permissions and ownerships.

— Figure 5. Left: _files_to_process.txt; right: _lang_codes.txt. Note not all executables exist. (e.g. Cd.exe)

3. “_lang_codes.txt” is a modifiable list containing all non-English language codes. It includes most languages but in case your language is not there, add it and “Englishize Cmd” will support it.

4. “_files_to_process.txt” is a modifiable list of file names of command-line executables that will be affected in the change. All commands in Windows Vista, 7 and 8.1 should be covered (although it contains much more commands than there actually are, it doesn’t matter because it has no effect on commands that don’t exist.) If you decide some commands are better left localized rather than being changed to English, remove them from this list before running EnglishizeCmd.bat . Also, although the list covers command-line executables, you can add GUI — Graphical User Interface — programs such as Paint — mspaint.exe and lots of others to “_files_to_process.txt”. There is a limitation here though. Windows comes with both English and non-English .mui files for command-line programs only; by default .mui for GUI programs don’t exist in en-US folder until users install the English MUI through Windows Update) or some third-party tool (for non-Ultimate/Enterprise Windows users).

— Figure 6. Interestingly, there is a point where both languages are shown while processing EnglishizeCmd.bat

Tip: If Englishize Cmd is installed in the computer (instead of using it the portable way), the above files would be located in either %ProgramFiles(x86)%\wandersick\EnglishizeCmd (for an all-user setup) or %LocalAppData%\wandersick\EnglishizeCmd (for a per-user setup)

Video Demonstrating Englishize Cmd

(Tip: Turn on captions to understand better)

Safety Design

Englishize Cmd has been designed with safety in mind; it does not allow a .mui to be disabled when its en-US counterpart is not found, in order to prevent from causing system problems. On the other hand, ‘RestoreCmd.bat’ restores original permission and ownership information in addition to renaming language files back to original file names. It is recommended to run ‘RestoreCmd.bat’ after use to fall back to original configuration at once. Next time, when it is desired to use Englishize Cmd, simply repeat the procedure of running ‘EnglishizeCmd.bat’ and ‘RestoreCmd.bat’ again.

Download

Over the years, Englishize Cmd has been seen referenced by or integrated in several projects by others. Feel free to continue doing so, and thanks for linking back even if it is optional.

⭐ The latest release of Englishize Cmd can be downloaded from its homepage.

Word of Mouth

Below are some of the kind comments left by users of the script. (Thanks!)

• “You provide a really great script. It saved my life because we here at school need the English commands in cmd with German OS language in Windows 10.”
• “It’s a very useful app. Thanks.”
• “Your script is awesome!”
• “I just can’t thank you enough for your efforts! I really appreciate it. You helped a lot!”

The homepage of Englishize Cmd has also been referenced by Microsoft Support for the discovered technique of renaming .mui files.

Englishize Cmd has been seen referenced by or integrated in several projects by others, such as NetChecker by HakerDefo and Xbox One Disk Partitioning Script by XFiX.

(If you find any additional projects or interesting usage leveraging Englishize Cmd, feel free to let me know!)

Release History

Welcome to buy me a cup of coffee ☕ if this tool is useful to you. �� Thanks!

Как поменять язык в командной строке

В некоторых случаях, когда используется неверная кодировка, могут возникать так называемые кракозябры или иероглифы, т.е. не читаемые символы, которые невозможно разобрать при работе с командной строкой. Эти проблемы могут также возникать и при запуске различных BAT-файлов. В данной статье мы расскажем о том, как можно сменить шрифт или кодировку, чтобы избавиться от этой проблемы. Пример таких не читаемых символов можно видеть на картинке ниже:

Первым делом нужно зайти в свойства окна: Правой кнопкой щелкнуть по верхней части окна -> Свойства -> в открывшемся окне в поле Шрифт выбрать Lucida Console и нажать кнопку ОК.
После этого не читаемые символы должны исчезнуть, а текст должен выводиться на русском языке.

Вместо смены шрифта, можно сменить кодировку, которая используется при работе cmd.exe.
Узнать текущую кодировку можно введя в командной строке команду chcp , после ввода данной команды необходимо нажать Enter .

Как видно на скриншоте, текущая используемая кодировка Windows-1251
Для изменения кодировки нам необходимо воспользоваться командой chcp <код_новой_кодировки> , где <код_новой_кодировки> — это сам код кодировки, на которую мы хотим переключиться. Возможные значения:

command-line – Сменить клавиатуру на английский язык в командной строке с кириллицы

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

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

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

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

Command-line – сменить клавиатуру на английский язык в командной строке с кириллицы

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

Некоторые вероятные подозреваемые – это ключ Caps Lock (латинская блокировка), клавиша Alt Alt (AltGr) или, возможно, комбинация клавиш Alt и Сдвиньте вместе.

Если бы вы могли посмотреть файл раскладки (или запустить dumpkeys), то вы точно знаете. Но может быть трудно найти информацию, пока ваша клавиатура застряла в незнакомом каркасе!

Комментарий в верхней части /usr/share/keymaps/i386/qwerty/ru.kmap.gz в Ubuntu 16.04 LTS (Xenial Xerus) говорит:

«Кириллический» режим переключается клавишей Right_Ctrl и сдвигается клавишей AltGr.

Надеюсь, ваша клавиатура имеет правый ключ Caps Lock ! Если это не так, вам нужно будет удерживать клавишу Alt-Alt (AltGr) во время переключения.

Вам понадобится

• Программное обеспечение:
• – командная строка;
• – терминал.

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

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

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

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

Основная консоль 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.

Локализация отладочной консоли 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 получает номера текущих страниц, устанавливает новые кодовые страницы вводного и выводного потоков, выполняет чтение с консоли и записывает выводную строку, содержащий русский текст, в том числе считанный с консоли, обратно в консоль. Операция повторяется несколько раз для всех основных кодовых страниц, упомянутых ранее.

приложение запущено в консоли с кодовыми страницами 1251 (строка 2);

приложение меняет кодовые страницы консоли (current, setted);

приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);

по окончании работы приложения изменения консоли сохраняются (строка 14 – Active codepage 1252);

Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).

Программное управление кодировками консоли – это единственный способ гарантированной адекватной локализацией приложения в консоли. Языки .Net такой возможности не предоставляют, однако предоставляют функции WinAPI: SetConsoleCP(uint numcp) и SetConsoleOutputCP(uint numcp), где numcp – номер кодовой страницы потоков ввода и вывода соответственно.

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

Проблемы консолей visual studio

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

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

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

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

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

Удалить приложение PowerShell (если установлено), сохранив Windows PowerShell;

Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5 ;

Разработку приложений выполнять в кодировке utf-8 Unicode;

Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad ;

Реализовать программное управление локализацией приложения в консоли, пример ниже под катом: