Как использовать символы юникода в командной строке Windows?
У нас есть проект в Team Foundation Server (TFS), в котором используется не английский символ (š). При попытке написать сценарий для некоторых вещей, связанных со сборкой, мы столкнулись с проблемой - мы не можем передать букву š инструментам командной строки. Командная строка или что-то еще портит ее, и утилита tf.exe не может найти указанный проект.
Я пробовал разные форматы для файла .bat (ANSI, UTF-8 с Спецификация и без него), а также писал его в JavaScript (который по своей сути является Unicode) - но не повезло. Как выполнить программу и передать ей командную строку Юникод?
Python 3.6: «консоль по умолчанию в Windows принимает все символы Unicode с этой версией» (ну, большая часть для меня) НО вам нужно настроить консоль: щелкните правой кнопкой мыши в верхней части окна (cmd или python IDLE ), в default / font выберите "Lucida console".
Возможный дубликат Как выводить строки Unicode на консоли Windows
@ LưuVĩnhPhúc - Нет, речь идет о передаче аргументов командной строки Unicode, а не отображении текста в консоли. Консоль может вообще не вмешиваться.
Ответы 17
Пытаться:
chcp 65001
который изменит кодовую страницу на UTF-8. Также вам нужно использовать консольные шрифты Lucida.
Вы знаете, есть ли способ сделать это по умолчанию?
Мною шрифт Lucida остается выбранным, но chcp нужно набирать каждый раз ... в любом случае большое спасибо за этот совет, я даже не думал, что это возможно :)
Обратите внимание, что в поддержке кодовой страницы 65001 Windows есть серьезные ошибки реализации, которые нарушат работу многих приложений, которые полагаются на методы ввода-вывода стандартной библиотеки C, так что это очень хрупко. (Пакетные файлы также просто перестают работать в 65001.) К сожалению, UTF-8 - второсортный гражданин в Windows.
Проголосовал за всех и принял этот ответ, потому что он получил наибольшее количество голосов. Мы отказались от TFS вскоре после публикации этого вопроса, поэтому он больше не актуален. Я также не могу сказать, работает это или нет, потому что у нас больше нет сервера TFS для тестирования.
@bobince У вас есть пример ошибки в поддержке кодовой страницы 65001 в Windows? Мне любопытно, потому что я никогда не встречал ни одного, и поиск в Google тоже ничего не дал. (Пакетные файлы, конечно, перестают работать, но UTF-8 вряд ли является второсортным ...)
@romkyns: Насколько я понимаю, вызовы, возвращающие количество байтов (например, fread / fwrite / и т. д.), на самом деле возвращают количество символов. Это вызывает множество симптомов, таких как неполное чтение ввода, зависания в fflush, битые командные файлы и т. д. Немного предыстории. Кодовые страницы по умолчанию, используемые для "многобайтовых" локалей CJK, имеют специальную встроенную обработку, чтобы исправить это, но 65001 этого не делает - это не поддерживается.
@bobince а, спасибо, это было интересно. Также был найден это, в котором есть дополнительная информация о статусе ошибки ...
@romkyns: ага! Спасибо, я знал, что читал об этом больше в блоге Каплана, но не мог выкопать пост. Удивительно, как долго это длилось без исправления (или даже без адекватной документации).
@romkyns, и хотя я опаздываю, вот ошибка с Python 3.3.2 в Windows XP и консоли с chcp 65001 и Lucida Console: просто создайте строку «s» с символами от 945 до 969 (это греческий алфавит) . Тогда просто попробуйте показать «s» (даже не называя «print»). Он напечатан на трех строках, с буквой «s» в первой, мусором и двумя другими.
Интересный вопрос здесь - это ошибка, потому что он должен сообщать байты, а вместо этого сообщает символы, или потому, что приложения, использующие его, неправильно приняли символы bytes =? Другими словами, это сбой API или сбой использования API?
Обновлен блог Kaplan о сломанном UTF-8 в Windows доступна здесь, поскольку Microsoft удалила все его сообщения в блоге после того, как он неправильно обработал верхнюю часть страницы.
У меня не работает с еврейскими символами в Windows 10 (консоль Lucida + chcp 65001),
Лучше используйте шрифт «Consolas». В Lucida Console отсутствуют символы Юникода, например 02B9.
Чтобы сделать utf-8 кодировкой по умолчанию: перейдите к [HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\Autorun] и установите для него chcp 65001
Поддержка консоли (conhost.exe) кодовой страницы 65001 в корне нарушена (как для ввода, так и для вывода в Windows 7, но все еще не работает для ввода в Windows 10). Пожалуйста, удалите это предложение, чтобы не повторять этот плохой совет в бесконечном цикле наивной «помощи». Оболочка cmd - это приложение Unicode, которое использует консольный интерфейс UTF-16 API и базовые API CreateProcessW и ShellExecuteExW. Если есть проблема с обработкой командной строки, это потому, что приложение использует версию char * в кодировке ANSI из стандартного C main вместо wchar_t * из точки входа wmain.
Из-за плохой поддержки вам лучше использовать альтернативные консоли, если вам нужен надежный Unicode. Например, Console2 для программ Windows и mintty для программ Cygwin (именно поэтому они в первую очередь развернули mintty).
@eryksun как насчет шрифта? У меня сложилось впечатление, что cmd в основном использует для отображения 8-битные точки символов, поэтому он не может поддерживать более 256 одновременно.
@ivan_pozdeev, CMD - это стандартная оболочка ввода-вывода, а не консоль или терминал. Для дескрипторов консоли он использует функции консоли Unicode ReadConsoleW и WriteConsoleW, которые считывают и записывают текст UTF-16 из и в связанный с ним хост-процесс консоли, conhost.exe. Если дескриптор файла не является консолью (например, чтение пакетного файла или чтение конвейерного ввода из цикла for /f или перенаправление dir в конвейер), встроенные команды CMD используют кодовую страницу ввода или вывода консоли в качестве кодировки. Для вывода вы можете переопределить это на UTF-16 с помощью опции CMD /u.
@ivan_pozdeev, в консоли используются 16-битные символьные ячейки. В принципе, он может отображать любой символ в BMP. Однако он не использует Uniscribe / DirectWrite, поэтому не поддерживает сложные сценарии (например, текст с письмом справа налево) или автоматические резервные шрифты. Ручное связывание шрифтов в реестре возможно, но результаты не очень хорошие, поэтому на практике это ограничивается тем, что поддерживает текущий шрифт. Символ за пределами BMP записывается как суррогатная пара UTF-16 в двух логически отдельных ячейках, поэтому он отображается как два глифа по умолчанию (например, пустые поля), но его можно скопировать в буфер обмена.
@ Cheersandhth.-Alf, заголовок довольно общий, я предполагаю, что именно поэтому многие поисковые системы сначала попадают на эту страницу. Однако, помимо несомненного ограничения / ошибки, я думаю, что chcp 65001 достаточно для 99% людей, имеющих проблемы с «Unicode в командной строке».
@WernfriedDomscheit: Какая первая часть «UTF-8 в консолях работает только частично и только для вывода», которую вы не смогли понять?
@ Cheersandhth.-Альф, я понимаю суть проблемы. Однако для типичного варианта использования, например echo € > euro.txt и type euro.txt, этого решения достаточно для большинства людей. Такие команды не работают с кодовой страницей 850 (значение по умолчанию для Западной Европы).
«решение достаточно для большинства людей» Это не решение. Это совет сродни засыпке сахара в бензобак машины, банальному саботажу. А насчет «я понимаю проблему» - нет, вы не понимаете. Учитывая это утверждение, я советую прочитать об эффекте Даннинга-Крюгера.
@ Cheers и hth. - Альф: Почти 300 тысяч человек пришли к этому вопросу из-за названия. Подавляющее большинство не прочитали основной вопрос. Они сразу же скопировали и вставили код из первого ответа, это сработало для них, проголосовало и продолжило свою жизнь. Скорее всего, им больше не придется иметь дело с тонкостями командной строки Windows. Они просто хотели запустить простую программу и продолжить свою работу. Им не нужен глубокий опыт, которым вы, очевидно, обладаете, и они не некомпетентны. Не нужно быть грубым.
@OhadSchneider версия Windows <= 1709 не может использовать chcp, и я тоже потерпел неудачу.
На самом деле хитрость в том, что командная строка действительно понимает эти неанглийские символы, просто не может их правильно отобразить.
Когда я ввожу в командную строку путь, содержащий неанглийские символы, он отображается как «?? ?????? ?????». Когда вы отправляете свою команду (в моем случае cd "??? ?????? ?????"), все работает, как ожидалось.
Это, вероятно, немного опасно, так как может возникнуть конфликт имен. например, если у вас есть два файла, которые отображаются как «???», и вы вводите «cd ???» он не знал бы, что использовать (или, что еще хуже, выберет произвольный).
Вы не вводите ???, вы вводите настоящее имя, оно просто отображается как ???. Думайте об этом как о поле для ввода пароля. Все, что вы вводите, отображается как ***, но отправленный - это исходный текст.
Это действительно работает для команд, запускаемых непосредственно в командной строке. Однако при запуске командного файла .cmd мне все равно нужно поместить chcp 65001 в начало командного файла.
В вашем случае это проблема со шрифтом ... контент есть, просто нет подходящего шрифта для его отображения. Но OP другое.
У меня была такая же проблема (я из Чехии). У меня английская версия Windows, и мне приходится работать с файлами на общем диске. Пути к файлам включают символы, специфичные для чешского языка.
Решение, которое мне подходит:
В пакетном файле измените страницу кодировки
Мой командный файл:
chcp 1250
copy "O:\VEŘEJNÉ\ŽŽŽŽŽŽ\Ž.xls" c:\temp
Пакетный файл необходимо сохранить в CP 1250.
Учтите, что консоль не будет правильно отображать символы, но поймет их ...
Ваше здоровье! Мне это было нужно, чтобы я мог ввести символ авторского права в свой командный файл.
Это отлично сработало и у меня в ситуации, почти идентичной вашей. Вместо этого мой путь содержал ирландские гэльские символы, то есть á, é, í, ó и ú.
@vanna, которая решает мою "проблему с турецкими символами и пробелами в пути в сети". ты замечательный.
Также найдите эти ресурсы: msdn.microsoft.com/en-us/library/windows/desktop/…, ss64.com/nt/chcp.html, technet.microsoft.com/en-us/library/bb490874.aspx Турецкий chcp - 857.
Вероятно, вам просто нужно было использовать другой шрифт, чтобы также правильно отображать символы, Консоль Lucida у меня сработал.
«Windows-1250 - это кодовая страница, используемая в Microsoft Windows для представления текстов на языках Центральной и Восточной Европы, использующих латинский алфавит, таких как польский, чешский, словацкий, венгерский, словенский, боснийский, хорватский, сербский (латинский алфавит), румынский. (до реформы правописания 1993 г.) и албанский ".
cp1250 по-прежнему является 8-битным набором символов, он по-прежнему поддерживает только 256 символов, просто меняет то, что это за символы.
Наконец-то полезный ответ! Отображаемые символы по-прежнему искажены, но аргументы (имена файлов с акцентами) теперь правильно передаются вызываемым программам. Спасибо! (Я тоже из Чехии)
Для аналогичной проблемы (моя проблема заключалась в том, чтобы показать символы UTF-8 из MySQL в командной строке),
Я решил это так:
Я изменил шрифт командной строки на Lucida Console. (Этот шаг не должен иметь отношения к вашей ситуации. Он имеет отношение только к тому, что вы видите на экране, а не к тому, что на самом деле является персонажем).
Я изменил кодовую страницу на Windows-1253. Вы делаете это в командной строке с помощью «chcp 1253». Это сработало для моего случая, когда я хотел увидеть UTF-8.
Windws-1253 не является кодовой страницей Unicode. Это стандартная кодовая страница из 256 символов. По-видимому, вы использовали только символы, которые могут отображаться на этой кодовой странице, но это не будет универсальным.
Проверьте язык на предмет программ, не поддерживающих Юникод. Если у вас проблемы с русским языком в консоли Windows, то вам следует установить русский язык здесь:
Это не включает поддержку Unicode в cmd, а только переключает кодовую страницу по умолчанию на cp866, которая по-прежнему является 8-битным набором символов. Он даже использует cp866 вместо cp1251, что добавляет кучу проблем.
См. Также мой ответ ниже, чтобы узнать о новой опции в новых версиях Windows 10.
Что можно сделать лучше: просто установите доступный бесплатный языковой пакет Microsoft для японского языка. (Другие восточные языковые пакеты также будут работать, но я тестировал японский.)
Это дает вам шрифты с большим набором глифов, делает их поведением по умолчанию, изменяет различные инструменты Windows, такие как cmd, WordPad и т. д.
У меня работает изменение кодовой страницы на 1252. Проблема для меня в том, что символ double doller § преобразуется в другой символ DOS в Windows Server 2008.
Я использовал CHCP 1252 и колпачок перед ним в своем заявлении о BCP ^ §.
Спасибо, это работает! Я не знаю, почему люди проголосовали против этого, это действительная альтернатива для некоторых людей .. Эта кодовая страница 1252 действительно решает проблему также на Windows Server 2012, где тот же код с CP 65001 не работал у меня. Я полагаю, это зависит от того, в какой кодовой странице был отредактирован пакетный скрипт, или от настроек ОС по умолчанию. В этом случае он был создан с помощью Блокнота на немецкой машине MUI с базовой ОС en-US.
Быстрое решение для файлов .bat, если ваш компьютер отображает ваш путь / имя файла правильно, когда вы вводите его в окне DOS:
- скопировать con temp.txt [нажмите Enter]
- Введите путь / имя файла [нажмите Enter]
- Нажмите Ctrl-Z [нажмите Enter]
Таким образом вы создадите файл .txt - temp.txt. Откройте его в Блокноте, скопируйте текст (не волнуйтесь, он будет выглядеть нечитабельным) и вставьте его в свой .bat-файл. Выполнение созданного таким образом .bat в DOS-окне у меня работало (кириллица, болгарский).
Изменить кодовую страницу консоли Windows по умолчанию довольно сложно. Когда вы ищете в Интернете, вы найдете разные предложения, однако некоторые из них могут полностью сломать вашу Windows, то есть ваш компьютер больше не загружается.
Самое безопасное решение - это:
Перейдите в раздел реестра HKEY_CURRENT_USER\Software\Microsoft\Command Processor и добавьте строковое значение Autorun = chcp 65001.
Или вы можете использовать этот небольшой пакетный скрипт для наиболее распространенных кодовых страниц.
@ECHO off
SET ROOT_KEY = "HKEY_CURRENT_USER"
FOR /f "skip=2 tokens=3" %%i in ('reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage /v OEMCP') do set OEMCP=%%i
ECHO System default values:
ECHO.
ECHO ...............................................
ECHO Select Codepage
ECHO ...............................................
ECHO.
ECHO 1 - CP1252
ECHO 2 - UTF-8
ECHO 3 - CP850
ECHO 4 - ISO-8859-1
ECHO 5 - ISO-8859-15
ECHO 6 - US-ASCII
ECHO.
ECHO 9 - Reset to System Default (CP%OEMCP%)
ECHO 0 - EXIT
ECHO.
SET /P CP = "Select a Codepage: "
if %CP%==1 (
echo Set default Codepage to CP1252
reg add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 1252>nul" /f
) else if %CP%==2 (
echo Set default Codepage to UTF-8
reg add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 65001>nul" /f
) else if %CP%==3 (
echo Set default Codepage to CP850
reg add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 850>nul" /f
) else if %CP%==4 (
echo Set default Codepage to ISO-8859-1
add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 28591>nul" /f
) else if %CP%==5 (
echo Set default Codepage to ISO-8859-15
add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 28605>nul" /f
) else if %CP%==6 (
echo Set default Codepage to ASCII
add "%ROOT_KEY%\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "@chcp 20127>nul" /f
) else if %CP%==9 (
echo Reset Codepage to System Default
reg delete "%ROOT_KEY%\Software\Microsoft\Command Processor" /v AutoRun /f
) else if %CP%==0 (
echo Bye
) else (
echo Invalid choice
pause
)
Использование @chcp 65001>nul вместо chcp 65001 подавляет вывод «Активная кодовая страница: 65001», который вы будете получать каждый раз при запуске нового окна командной строки.
Полный список всех доступных номеров вы можете получить на Идентификаторы кодовой страницы
Обратите внимание, что настройки будут применяться только для текущего пользователя. Если вы хотите установить его для всех пользователей, замените строку SET ROOT_KEY = "HKEY_CURRENT_USER" на SET ROOT_KEY = "HKEY_LOCAL_MACHINE".
хорошая идея и полезный пример!
Я обошел аналогичную проблему, удаляя файлы с именами Unicode, ссылаясь на них в пакетном файле по их коротким (8 точек 3) именам.
Краткие имена можно просмотреть, выполнив dir /x. Очевидно, это работает только с уже известными именами файлов Unicode.
Один действительно простой вариант - установить оболочку Windows bash, такую как MinGW, и использовать ее:
Существует небольшая кривая обучения, поскольку вам нужно будет использовать функциональность командной строки Unix, но вам понравится ее сила, и вы можете установить набор символов консоли на UTF-8.
Конечно, вы также получаете все обычные * nix-полезности, такие как grep, find, less и т. д.
В этом (старом) случае проблема заключалась в сценарии, а не в консоли. Решит ли это использование сценариев bash?
Да, действительно, они деревянные сценарии bash могут быть помечены как UTF-8 и просто работают с гораздо большей мощностью, чем пакетные файлы Windows - я знаю, что это был старый случай, но подумал, что этот вариант стоит отметить для дальнейшего использования, поскольку MS не кажется чтобы стать лучше в Юникоде.
Вывод символов в кодировке UTF-8 в порядке. Но ввод по-прежнему кодируется системной кодовой страницей.
Просто добавим, что у пользователей Windows, возможно, уже есть оболочка bash, если вы используете Git: просто откройте окно Git> Git Bash.
Поскольку я не видел полных ответов для Python 2.7, я опишу два важных шага и дополнительный шаг, который весьма полезен.
- Вам нужен шрифт с поддержкой Unicode. Windows поставляется с консолью Lucida, которую можно выбрать, выполнив щелчок правой кнопкой мыши по строке заголовка командной строки и нажав опцию
Defaults. Это также дает доступ к цветам. Обратите внимание, что вы также можете изменить настройки для командных окон, вызываемых определенными способами (например, открыть здесь, Visual Studio), выбрав вместо этогоProperties. - Вам необходимо установить кодовую страницу на
cp65001, что похоже на попытку Microsoft предложить поддержку UTF-7 и UTF-8 в командной строке. Сделайте это, запустивchcp 65001в командной строке. После установки он остается таким, пока окно не закроется. Вам нужно будет повторять это каждый раз при запуске cmd.exe.
Для более постоянного решения обратитесь к этот ответ на суперпользователе. Короче говоря, создайте запись REG_SZ (String) с помощью regedit в HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor и назовите ее AutoRun. Измените его значение на chcp 65001. Если вы не хотите видеть выходное сообщение от команды, используйте вместо этого @chcp 65001>nul.
У некоторых программ есть проблемы с взаимодействием с этой кодировкой, примечательно, что MinGW дает сбой при компиляции с бессмысленным сообщением об ошибке. Тем не менее, это работает очень хорошо и не вызывает ошибок в большинстве программ.
На машине Windows 10 x64 я заставил командную строку отображать неанглийские символы следующим образом:
Откройте командную строку с повышенными привилегиями (запустите CMD.EXE от имени администратора). Запросите в реестре доступные шрифты TrueType для консоли:
REG query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont"
Вы увидите такой вывод:
0 REG_SZ Lucida Console
00 REG_SZ Consolas
936 REG_SZ *新宋体
932 REG_SZ *ＭＳ ゴシック
Теперь нам нужно добавить шрифт TrueType, который поддерживает нужные вам символы, например Courier New. Мы делаем это, добавляя нули к имени строки, поэтому в этом случае следующим будет «000»:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 000 /t REG_SZ /d "Courier New"
Теперь реализуем поддержку UTF-8:
REG ADD HKCU\Console /v CodePage /t REG_DWORD /d 65001 /f
Установите шрифт по умолчанию "Courier New":
REG ADD HKCU\Console /v FaceName /t REG_SZ /d "Courier New" /f
Установите размер шрифта на 20:
REG ADD HKCU\Console /v FontSize /t REG_DWORD /d 20 /f
Включите быстрое редактирование, если хотите:
REG ADD HKCU\Console /v QuickEdit /t REG_DWORD /d 1 /f
В целом использование кодовой страницы 65001 будет работать без ошибок только в Windows 10 с обновлением Creators. В Windows 7 будут ошибки как вывода, так и ввода. В Windows 8 и более старых версиях Windows 10 есть только ошибка ввода, которая ограничивает ввод 7-битным ASCII.
Я пробовал использовать этот метод, и теперь шрифт очень маленький и кажется постоянным.
Эта проблема очень раздражает. Обычно в имени файла и содержимом файла используются китайские символы. Обратите внимание, что я использую Windows 10, вот мое решение:
Чтобы отобразить имя файла, например dir или ls, если вы установили Ubuntu bash в Windows 10
Установите для региона поддержку символов 8, отличных от UTF.
После этого шрифт консоли будет изменен на шрифт этой локали, а также изменится кодировка консоли.
После того, как вы выполнили предыдущие шаги, чтобы отобразить содержимое файла файла UTF-8 с помощью инструмента командной строки
- Меняем страницу на utf-8 по
chcp 65001 - Измените шрифт, поддерживающий utf-8, например Lucida Console.
- Используйте команду
type, чтобы просмотреть содержимое файла, илиcat, если вы установили Ubuntu bash в Windows 10. - Обратите внимание, что после установки кодировки консоли на utf-8 я не могу ввести китайский символ в cmd, используя китайский метод ввода.
Самое ленивое решение: просто используйте эмулятор консоли, например http://cmder.net/
Это не для меня. Китайские символы в выводе команды point все еще искажены.
@SiqingYu Я отказываюсь от безумной обстановки. Просто используйте blog.miniasp.com/post/2015/09/27/Useful-tool-Cmder.aspx
Раньше я использовал Cmder, но он не может заменить консоль разработчика, используемую Visual Studio.
@SiqingYu Вы имеете в виду интерактивную оболочку PowerShell C#?
Не интерактивная оболочка питания, а консоль разработчика, тоже используемая Visual C++. Это консоль отладки по умолчанию в проектах консольных приложений Win32.
Я вижу здесь несколько ответов, но они, похоже, не касаются вопроса - пользователь хочет получить ввод Unicode из командной строки.
Windows использует UTF-16 для кодирования двухбайтовых строк, поэтому вам нужно получить их из ОС в своей программе. Есть два способа сделать это -
1) У Microsoft есть расширение, которое позволяет main принимать широкий массив символов: int wmain (int argc, wchar_t * argv []); https://msdn.microsoft.com/en-us/library/6wd819wh.aspx
2) Вызовите API Windows, чтобы получить версию командной строки в Юникоде. wchar_t win_argv = (wchar_t) CommandLineToArgvW (GetCommandLineW (), & nargs); https://docs.microsoft.com/en-us/windows/desktop/api/shellapi/nf-shellapi-commandlinetoargvw
Прочтите это: http://utf8everywhere.org для получения подробной информации, особенно если вы поддерживаете другие операционные системы.
Ах, нет, извини, но ты упустил вопрос. Это когда я пишу программу, которая будет получить символов Юникода. Мой вопрос касался отправка символов Unicode для другой программы (которая, надеюсь, поддерживает их получение, но у меня действительно нет другого способа узнать, кроме разборки).
Я нашел этот метод полезным в новых версиях Windows 10:
Включите эту функцию: «Бета: используйте Unicode UTF-8 для поддержки языков во всем мире»
Control panel -> Regional settings -> Administrative tab-> Change system locale...
Как добиться этого с помощью powershell или cmd?
Я пытаюсь отобразить китайские символы в консоли, но это не сработало в 64-разрядной версии Windows 10 (установлено на турецком языке, а затем изменено на английский). Далее попробую установить китайский язык и посмотрю, работает ли.
Только будьте осторожны, это нарушило функциональность некоторых старых и дрянных программ, которые нормально работали на сервере 2019.
Начиная с июня 2019 года с Windows 10 вам не придется менять кодовую страницу.
См. «Представляем Windows Terminal» (из Кайла Корица) и Microsoft / Терминал.
Благодаря использованию шрифта Consolas будет обеспечена поддержка Unicode частичный.
Как описано в Microsoft/Terminal, выпуск 387:
There are 87,887 ideographs currently in Unicode. You need all of them too?
We need a boundary, and characters beyond that boundary should be handled by font fallback / font linking / whatever.What Consolas should cover:
- Characters that used as symbols that used by modern OSS programs in CLI.
- These characters should follow Consolas' design and metrics, and properly aligned with existing Consolas characters.
What Consolas should NOT cover:
- Characters and punctuation of scripts that beyond Latin, Greek and Cyrillic, especially characters need complex shaping (like Arabic).
- These characters should be handled with font fallback.
@JohannesDewender - Копирование и вставка пошли не так?