Кракозябры в командной строке cmd. Проблемы с кодировкой cmd.exe
Выполняю cmd и в нем set, хочу узнать USERNAME. Но оно показывается в непонятной кодировке.
chcp 866; chcp 1251; chcp 65001 — не помогали.
Оказывается надо в свойствах самого cmd выбрать шрифт Lucida Console. Только так можно получить нормальный текст на русском языке.
Спасшая статья:
Приложение cmd.exe – это командная строка или программная оболочка с текстовым интерфейсом (во загнул ).
Запустить командную строку можно следующим способом: Пуск → Выполнить → вводим в поле команду – cmd и жмем ОК. В итоге откроется рабочее окно программы – c:\WINDOWS\system32\cmd.exe. ( рис.1)
Если Вы занялись проблемой кодировки шрифтов в cmd.exe , то как запускать командную строку наверняка уже знаете
Перейдем собственно к проблеме: иногда вместо русских букв при выполнении команд выходит набор непонятных символов ( рис.2).
Первым делом нужно зайти в свойства окна – правой кнопкой щелкнуть по верхней части окна → Свойства → выйдет окно рис.3, здесь в поле Шрифтвыбираем Lucida Console и жмем ОК.
Теперь Вы получили нормальный текст на русском языке. Так же можно поменять текущую кодировку шрифта, для этого используется команда chcp. Набираем эту команду и жмем Enter, в результате получим текущую кодировку для командной строки – рис.4.
Для изменения кодировки так же применим chcp в следующем формате:
Где – это цифровой параметр нужного шрифта, например,
1251 – Windows (кириллица);
Выбирайте на любой вкус. Т.о. что бы изменить кодировку на UTF-8 нужно выполнить команду chcp 65001.
almix
Разработчик Loco, автор статей по веб-разработке на Yii, CodeIgniter, MODx и прочих инструментах. Создатель Team Sense.
Не корректно отображается Русский текст в CMD? Решение есть!
Как корректно отобразить Русский текст в CMD. Проблемы с кодировкой могут возникнуть, например, при выполнении Bat файла, когда нужно вывести в консоль русский текст и при других обстоятельствах, о которых речь пойдёт далее.
Рассмотрим пример: когда нужно вывести в консоль Русский текст, скажем «Примет мир». Для этого создадим Bat файл с именем «1.bat». Используйте для этого обычный Блокнот Windows (Notepad.exe) Запишем в него следующие строки!
Для тех, кто не понял или не в курсе, строчки «echo.» я добавил специально, что бы были отступы, от строки «Примет мир»
Теперь запускаем файл 1.bat и результат будет такого вида.
Как видим проблема с кодировкой в cmd на лицо. И произошло это по следующей причине.
Стандартный блокнот Windows сохранил Bat файл в кодировке «1251» а консоль вывела его в кодировки «866». Вот от сюда все проблемы!
Решения проблемы с кодировкой в CMD. 1 Способ.
Для решения проблемы нужно просто использовать текстовой редактор, с помощью которого можно сохранить текст в кодировке «866». Для этих целей прекрасно подходит «Notepad++» (Ссылку для загрузки Вы можете найти в моём Twitter-e).
Скачиваем и устанавливаем на свой компьютер «Notepad++».
После запуска «Notepad++» запишете в документ те же строки, которые мы уже ранние записывали в стандартный блокнот.
Теперь осталось сохранить документ с именем «2.bat» в правильной кодировке. Для этого идём в меню «Кодировки > Кодировки > Кириллица > OEM-866»
и теперь сохраняем файл с именем «2.bat» и запускаем его! Поле запуска результат на лицо.
Как видим, текст на Русском в CMD отобразился, как положено.
Решения проблемы с кодировкой в CMD. 2 Способ.
Теперь рассмотрим ещё одну ситуацию, когда могут возникнуть проблемы с кодировкой в CMD.
Допустим, ситуация требует сохранить результат выполнения той или иной команды в обычный «TXT» файл. В приделах этого поста возьмём для примера команду «HELP».
Задача : Сохранить справку CMD в файл «HelpCMD.txt. Для этого создайте Bat файл и запишите в него следующие строки.
После выполнения Bat файла в корне диска «C:\» появится файл «HelpCMD.txt» и вместо справки получится вот что:
Естественно, такой вариант не кому не понравится и что бы сохранить справку в понятном для человека виде, допишите в Bat файл строку.
Теперь содержимое кода будет такое.
После выполнения «Батника» результат будет такой:
Вот так на много лучше, правда?
Пожалуй, на этом я закончу пост. Добавить больше нечего. Если у Вас имеются какие-то соображения по данной теме, буду рад Вашему комментарию к посту.
Дополнительно из комментариев то Garric
Автор очень хорошо описал принцип. ! Но это неудобно.
Нужно бы добавить. Если автор добавит это в статью то это будет Good.
Создаём файл .reg следующего содержания:
——
Windows Registry Editor Version 5.00
«FileName»=»BATНастроенная кодировка.bat»
——
Выполняем.
——
Топаем в %SystemRoot%\SHELLNEW
Создаём там файл «BATНастроенная кодировка.bat»
Открываем в Notepad++
Вводим любой текст. (нужно!) Сохраняемся.
Удаляем текст. Меняем кодировку как сказано в статье. Сохраняемся.
———-
Щёлкаем правой кнопкой мыши по Рабочему столу. Нажимаем «Создать» — «Пакетный файл Windows».
Переименовываем. Открываем в Notepad++. Пишем батник.
В дальнейшем при работе с файлом не нажимаем ничего кроме как просто «Сохранить». Никаких «Сохранить как».
Powershell и кирилица в консольных приложениях (updated)
В процессе разработки очень часто возникает необходимость запустить из powershell скрипта консольное приложение. Что может быть проще?
Изучим поведение консольных приложений при запуске их из командной строки, через PowerShell и через PowerShell ISE:
В PowerShell ISE возникла проблема с кодировкой, так как ISE ожидает вывод в кодировке 1251. Воспользуемся гуглом и найдем два решения проблемы: c использованием [Console]::OutputEncoding и через powershell pipeline. Воспользуемся первым решением:
В командной строке все хорошо, а вот в ISE ошибка. Exception setting «OutputEncoding»: «The handle is invalid.». Снова берем в руки гугл, и в первом же результате находим решение — надо запустить какое-нибудь консольное приложение для создания консоли. Ну что-же, попробуем.
Все красиво, все работает. Кто читал мою прошлую заметку, обратил внимание, что WinRM приносит нам много острых впечатлений. Попробуем запустить тест через WinRM. Для запуска воспользуемся вот таким скриптом:
Что-то пошло не так. Решение с созданием консоли не работает. Ранее мы находили два решения проблемы кодировки. Попробуем второй:
В ISE и через WinRM решение работает, а вот через командную строку и shell — нет.
Надо объединить эти два способа и проблема будет решена!
Кажется, что проблема решена, но продолжим исследование и усложним наше консольное приложение, добавив в него вывод в stdError.
Становится все веселее 🙂 В ISE исполнение скрипта прервалось на середине, а через WinRM мало того, что прервалось, так еще сообщение из stdErr прочитать невозможно. Первым шагом решим проблему с остановкой запускаемого из скрипта приложения, для этого перед запуском приложения изменим значение глобальной переменной $ErrorActionPreference.
Какой будет результат выполнения такого скрипта?
Вторым шагом доработаем скрипт удаленного запуска через WinRM, чтобы он не падал:
И осталось самое сложное — скорректировать сообщение формируемое через stdErr и при этом не изменить его положение в логе. В процессе решения этой задачи коллеги предложили самостоятельно создать консоль, воспользовавшись win api функцией AllocConsole.
Избавится от информации, которую добавляет powershell к stdErr мне так и не удалось.
Надеюсь, что эта информация окажется полезной не только мне! 🙂
update 1
В некоторых сценариях использования создавалась дополнительная консоль, в которую выдавался результат выполнения скриптов. В скрипт test8.ps1 внесены исправления.
update 2
Так как у многих комментаторов статьи возникла путаница между понятиями набор символов (char set) и кодировка (encoding) хотел бы еще раз обратить внимание, что в статье решается проблема именно несоответствия кодировок консоли и вызываемого приложения.
Как можно увидеть из скрипта test8.ps1, кодировка указывается в статическом свойстве [Console]::OutputEncoding, и никто не мешает указать в нем одну из кодировок семейства unicode:
Но, для работы скрипта в стандартной консоли windows (aka cmd.exe) необходимо изменить шрифт консоли со стандартного «Rasters Fonts» на Consolas или «Lucida Console». Если бы данные скрипты мы использовали только на собственных рабочих станциях или серверах, то такое изменение было бы допустимо, но так как нам приходится распространять наши решения заказчикам, вмешиваться в системные настройки серверов мы не имеем права. Именно по этой причине в скриптах используется cp866, как кодировка настроенная по умолчанию для консоли.
Ой, у вас баннер убежал!
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.
Похожие публикации
Первое исследование состояния DevOps в России
С чего начать DevOps?
Powershell и глубина стека
Заказы
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Комментарии 37
Русские символы? Кажется, вы хотели сказать «кириллица».
Не обижайтесь, но… Идет 2017 год, все человечество уже лет 15-17 точно перешло на Unicode. И только в Windows нужны какие-то эзотерические заклинания, вспоминать, что такое магические 866 и 1251. Понимаю, что все это видимо ради совместимости с приложениями 30-летней давности, но все же, можно было бы придумать и более изящное решение, особенно учитывая, что PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Unicode конечно несовершенен, как и все в этом мире. Но UTF-8 покрывает значительно большее количество случаев и намного более удобен, чем подобные костыли с code pages.
Я не знаток всех мировых языков. На повседневном уровне использую три: русский, английский, испанский. У меня в альтернативной операционной системе, что в консоли, что в любом другом приложении можно свободно использовать и комбинировать эти языки как угодно. При необходимости можно использовать еще сколько угодно языков. Да, наверное, какие-то проблемы с редкими символами из японского/китайского или малаяламского могут возникнуть, специально этим не интересовался.
В общем, Unicode — может быть и не всеобъемлющее решение, но однозначно намного более универсальное, чем полуработающие костыли (автор, насколько я понимаю, так и не добился работы без предупреждений во всех ситуациях). Допустим, если у нас существует необходимость работать с 2-3 языками одновременно, то я не вижу возможного решения вообще.
И это в 2017 году, когда по улицам скоро начнут ездить робомобили с искусственным интеллектом, память компьютеров измеряется десятками, если не сотнями гигабайт, а скорость процессоров дошла до физического предела… Но до сих пор в консоли Windows существуют ограничения 30-летней давности, когда компьютеры были слабее, чем самый слабый процессор в наручных часах.
Но UTF-8 покрывает значительно большее количество случаев и намного более удобен, чем подобные костыли с code pages.
А почему именно UTF-8?
Был опыт в попытке подружить вывод консоли TalendStudio с со сборочным агентом bamboo работающем под linux, вот только первый отправлял в stdout данные в кодировке UTF-16 а агент считывал их используя кодировку UTF-8. Так что использование unicode и не windows стека технологий в общем случае не спасет от возникновения проблем.
Ну и не надо забывать, что первоначально была задача решить проблему производства. 🙂
PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Да, конечно, вы правы. И поэтому так такой совместимости по умолчанию и не предусмотрено: приложения, которые пользуются современными юникодовыми API ( WriteConsoleW ), будут печатать вывод нормально, а для устаревших приложений нужны бубны (некоторые сорта которых описаны в посте). К сожалению, приложений, которые не пользуются современными юникодовыми API, ещё очень много. Многие рантаймы языков программирования также этот режим вывода не поддерживают, что ещё печальнее.
А в линуксе как вы будете запускать программу, которая выводит UTF-16 в stdout, и чтоб этот текст отобразился на терминале?
(Я не утверждаю, что вы не сможете это сделать, просто мне действительно интересно посмотреть на решение.)
Во-первых, приложение, которое выводит на stdout интерактивный контент не в том, что указано в переменных локализации LC_*, надо исправлять, а не жить с этим. Это — ошибка, а не нормальное поведение.
Во-вторых, если очень нужно — большинство эмуляторов терминала умеют установить произвольную кодировку в качестве отображаемой, в том числе варианты UTF16.
приложение, которое выводит на stdout интерактивный контент не в том, что указано в переменных локализации LC_*, надо исправлять, а не жить с этим. Это — ошибка, а не нормальное поведение.
В этом я с вами тоже полностью согласен! Приложения, которые пытаются использовать функции семейства WriteConsoleA (которые по определению работают в текущей OEM-кодировке), чтобы выводить текст в другой кодировке, тоже надо исправлять. В Windows, если вам угодно, переменные локализации LC_* всегда константы и указывают UTF-16 кодировку, для которой есть соответствующее семейство функций вывода на экран. К сожалению, многие программы это игнорируют и пытаются совать в OEM-функции тексты в своих кодировках, что иногда и вызывает проблемы.
если очень нужно — большинство эмуляторов терминала умеют установить произвольную кодировку в качестве отображаемой, в том числе варианты UTF16.
А это не испортит вывод предыдущих команд в том же терминале? Пожалуй, для каких-то единичных программ всё-таки лучше пайпать их вывод в iconv .
Приложения, которые пытаются использовать функции семейства WriteConsoleA [. ] тоже надо исправлять
Только вот Microsoft с вами, боюсь, не согласен. Иначе бы делали какие-то телодвижения по объявлению *A функций deprecated и пытались бы как-то форсировать переход человечества в светлое будущее. Вот здесь говорят, что их пытаются deprecate’ить, но только по каким-то одиночным библиотекам типа winsock2.
А это не испортит вывод предыдущих команд в том же терминале?
Не должно. Хотя бы потому, что терминал, вообще говоря, не имеет возможности переинтерпретировать какую-то часть старого потока символов при таком переключении кодировки (хотя бы потому, что эту часть еще как-то выделить и запомнить надо, а это потребует весьма нетривиальных телодвижений). Это же не браузер, в котором кодировку всего документа переключают — документа-то нет.
Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции WriteConsoleA есть вполне определённое поведение: вывести строку в текущей OEM-кодировке (ну, вообще говоря, просто в текущей кодировке консоли в соответствии с SetConsoleOutputCP , которая по умолчанию инициализируется из OEM).
Если конкретному приложению нужно именно это (мне сложно представить себе современное приложение с такими нуждами, но мало ли) — оно вполне легитимно вправе использовать это семейство функций.
Если же конкретное приложение хочет выводить какой-то национальный текст вне зависимости от кодировки терминала — оно должно использовать соответствующие юникодовые функции (a la WriteConsoleW ). Вот и всё.
Не обижайтесь, но во-первых, отучайтесь говорить за всё человечество, во-вторых, unicode в той же ntfs появился в 1993 году, когда… в каком состоянии был софт, который вы используете, что вам позволяет не зная в принципе матчасти игнорируя реальный кейс по powershell пускаться в публичные пространные рассуждения внезапно об операционной системе в целом, человечестве и необходимости обратной совместимости?
Про обратную совместимость: благодаря этим бесконечным костылям в windows 10.0 запускается и работает то, что писалось во времена windows 3.5. А уж без специфических программ если — то windows 5 софт работает без проблем в windows 10.
Вы на каком красноглазии сидите, что позволяете себе свысока подобные сентенции публично? Там можно десятилетний бинарник запустить без проблем, да?
unicode в той же ntfs появился в 1993 году
Простите, что так задел вас.
Не знаю, как с бинарной совместимостью с Linux. Она там есть, но насколько хорошая — не знаю, т.к. весь необходимый мне софт — opensource — поэтому никогда не нужна была бинарная совместимость. Раньше у меня было время читать lkml и множество других источников информации о развитии Linux, и помню, что этот вопрос обсуждался и совместимость старались сохранить.
Предполагаю, что десятилетний бинарник скорее всего можно будет запустить.
Что касается поддержки Unicode в ntfs — не знаю, что тут сказать. Может быть это требовалось по каким-то причинам для ntfs, про файловые системы Linux/Unix можно сказать, что они поддерживали Unicode с самого начала существования, еще до возникновения Unicode, так как для большинства файловых систем Linux/Unix — имя файла — это просто набор байтов, который они никак не пытаются интерпретировать. То же самое относится, естественно, к содержимому файла. Поэтому можно использовать хоть Unicode, хоть что угодно вместо него.
Но тут речь не о сравнении операционных систем — я не пытался и не хотел начинать такой разговор. Просто описанное в статье мне показалось костылями, да еще и неработающими. Выразил свое удивление, вот и все. Может быть все эти неудобства стоят того, чтобы кто-то мог запустить на Windows 10 программу для Windows 3.11. Меня это удивляет, конечно, потому что таких людей наверняка меньше 1%, и почему бы им не использовать копию Win 3.11 или виртуальную машину, вместо того, чтобы миллионы людей по всему миру испытывали неудобства.
Мне кажется, эта полемика возникла из взаимонепонимания двух ортогональных точек зрения: Ваша, «как надо писать программы»(точка зрения разработчика) и автора, «как заставить работать то, что написали другие»(т.зр. сисадмина). Вы поавы, ситуацию надо менять в корне. Но пока она не исправлена, проблема есть и её надо решать в рамках задач по эксплуатации независимо от того, что «есть правильный путь». Так что да, автор тоже прав, что ищет пути.
Я не обладаю всей информацией, чтобы предложить решение. Всю жизнь использую Linux — так сложилось, что Linux увидел раньше Windows, еще где-то в 95 или 96 году. С Windows знаком постольку-поскольку, сталкиваюсь лишь на компьютерах знакомых.
Поэтому мне сложно предложить техническое решение, решающее данную проблему. Просто удивило — все это выглядит как нагромождение костылей. Представляю какое астрономическое количество человеко-лет тратит Microsoft на поддержку этой совместимости, в том числе откровенно дебильных codepages, которые, мне казалось, давно остались лишь в музеях. А затем пользователи Windows по всему миру тратят свои человеко-часы, чтобы построить новые костыли поверх старых, чтобы обойти эти грабли древних кодировок.
В итоге, полмира тратит время впустую, лишь бы кто-то мог запустить supercalc.exe 1986 года на операционной системе 2015-го года. Мне почему-то это не кажется поводом для гордости. Есть какой-то баланс между ломанием совместимости в каждой новой версии и фанатичной поддержкой совместимости. Кому нужно работать с приложениями 20-30 летней давности, скорее всего будет делать это на старом железе со старой системой. В крайнем случае, почему бы не установить виртуальную машину.
Зачем подвергать людей таким пыткам, что они даже банальный скрипт невозможно написать без танцев с бубном? Неужели не существует разумного способа решить данную проблему раз и навсегда? Например, сказать: «пусть cmd и все прочее, что потенциально может использоваться для старых приложений, будет использовать codepages, а для PowerScript мы делаем стандартом Unicode?»
Ну, Linux тоже стоит в куче мегакорпораций, и ничего, как-то умудряется поддерживать всюду сквозной unicode без костылей. В любом приложении, консольном или GUI, написанном на любом языке программирования, с использованием любого фреймворка, могу вводить текст на нескольких языках, и он будет отображаться всюду без проблем, сохраняться, загружаться. По-моему, это просто необходимое условие для минимально комфортного уровня работы, потому что за пределами Северной Америки, почти всем людям приходится ежедневно использовать два и более языка.
Про supercalc — не верю, что кто-то покупает новую машину с i7, устанавливает Windows 10, и все это, для того, чтобы запустить supercalc. Если такие пользователи и есть, то у них стоит какое-нибудь древнее железо, на котором крутится DOS, Windows 3.11 или что-то подобное.
Понятно, что полная статистика есть только у Microsoft, да и есть ли. Но все же сомнительно, чтобы такие пользователи составляли хоть сколько-нибудь значительный процент среди покупателей тех же Windows 7, Windows 10.
А мне вот интересно, если бы в статье был описан более частный случай с несогласованностью кодировок UTF-16 в приложении, UTF-8 в «консоли» Вы бы тоже писали, что эта проблема вот уже 100 лет как решена в linux, а Microsoft только на бабки пользователей разводит? 🙂
Ну и как я писал выше — путаете набор символов (char set) и кодировку (encoding).
Я нигде не писал, что «Microsoft разводит пользователей на бабки». И отлично знаю разницу между char set и encoding, хотя частенько использую термин unicode как синоним utf-8, прошу за это прощения.
На самом деле удивило, что до сих пор людям приходится бороться с code pages причем в современных языках и приложениях. Когда уже много лет не испытывал абсолютно никаких проблем в этой области, подобные проблемы на самом деле удивляют. 866? 1251? Какие-то хаки, чтобы прочитать кириллицу в выводе скрипта? Это действительно удивительно при взгляде с другой стороны баррикад.
Причем я ни в одном комментарии не критиковал Microsoft, только лишь выражал искреннее недоумение.
Простите, что так задел вас
Какой унылый демагог. Ваше мнение, безусловно, очень важно, держите в курсе.
благодаря этим бесконечным костылям в windows 10.0 запускается и работает кое-что, что писалось во времена windows 3.5
PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Идет 2017 год, все человечество уже лет 15-17 точно перешло на Unicode. И только в Windows нужны какие-то эзотерические заклинания
А при чем тут кстати вообще powershell? Вот пример приложения:
вот скрипт (1.ps1 в UTF8-BOM):
Результат: