341

We have a project in Team Foundation Server (TFS) that has a non-English character (š) in it. When trying to script a few build-related things we've stumbled upon a problem - we can't pass the š letter to the command-line tools. The command prompt or what not else messes it up, and the tf.exe utility can't find the specified project.

I've tried different formats for the .bat file (ANSI, UTF-8 with and without BOM) as well as scripting it in JavaScript (which is Unicode inherently) - but no luck. How do I execute a program and pass it a Unicode command line?

saw303
  • 6,993
  • 4
  • 45
  • 81
Vilx-
  • 101,209
  • 85
  • 267
  • 409
  • 1
    @JohannesDewender - Copy-paste gone wrong? – Vilx- Dec 19 '12 at 08:25
  • 2
    Python 3.6: "the default console on Windows accept all Unicode characters with that version" (well, most of it for me) **BUT** you need to configure the console: right click on the top of the windows (of the cmd or the python IDLE), in default/font choose the "Lucida console". – JinSnow Jan 13 '17 at 20:48
  • [Output unicode strings in Windows console app](https://stackoverflow.com/q/2492077/995714), [Output Unicode to console Using C++, in Windows](https://stackoverflow.com/q/2849010/995714) – phuclv May 28 '17 at 04:07
  • Possible duplicate of [How to Output Unicode Strings on the Windows Console](https://stackoverflow.com/questions/3130979/how-to-output-unicode-strings-on-the-windows-console) – phuclv May 28 '17 at 04:07
  • 2
    @LưuVĩnhPhúc - No, this is about passing unicode command line arguments, rather than displaying text in the console. Console might not get involved at all. – Vilx- May 28 '17 at 11:08

18 Answers18

417

Try:

chcp 65001

which will change the code page to UTF-8. Also, you need to use Lucida console fonts.

kgiannakakis
  • 100,996
  • 27
  • 157
  • 193
  • 21
    Do you know if there's a way to make this the default? – AnnanFay Nov 14 '11 at 13:55
  • By me Lucida font stays chosen, but chcp must be typed each time... anyway great thanx for this tip, I didn't even thought it is possible :) – Danubian Sailor Nov 21 '11 at 15:41
  • 87
    Note there are serious implementation bugs in Windows's code page 65001 support which will break many applications that rely on the C standard library IO methods, so this is very fragile. (Batch files also just stop working in 65001.) Unfortunately UTF-8 is a second-class citizen in Windows. – bobince Dec 29 '11 at 21:51
  • 1
    Upvotes for everyone and accepted this answer because it's the most upvoted one. We moved away from TFS not long after this question was posted, so it's not relevant anymore. I also can't say if it works or not because we don't have a TFS server anymore to test on. – Vilx- Jan 28 '12 at 13:30
  • 8
    @bobince Do you have an example of a bug in the Windows code page 65001 support? I'm curious because I've never run into one, and googling didn't turn anything up either. (Batch files do stop working, of course, but UTF-8 is hardly a second-class citizen...) – Roman Starkov Dec 03 '12 at 02:09
  • 18
    @romkyns: My understanding is that calls that return a number-of-bytes (such as fread/fwrite/etc) actually return a number-of-characters. This causes a wide variety of symptoms, such as incomplete input-reading, hangs in fflush, the broken batch files and so on. [Some background.](http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/e4b91f49-6f60-4ffe-887a-e18e39250905/) The default code pages used for CJK "multibyte" locales have special handling built in to fix this, but 65001 doesn't - it is [not supported](http://blogs.msdn.com/b/michkap/archive/2006/03/13/550191.aspx). – bobince Dec 04 '12 at 12:26
  • 1
    @bobince ah, thank you, that was interesting. Also found [this](http://http://blogs.msdn.com/b/michkap/archive/2011/03/09/10138478.aspx), which has more info about the status of the bug... – Roman Starkov Dec 04 '12 at 13:31
  • @romkyns: aha! Thanks, I knew I had read more about it on Kaplan's blog but couldn't dig the post out. Depressing how long this has gone without fix (or even adequate doc). – bobince Dec 05 '12 at 02:29
  • 3
    @romkyns, and though I'm late, here is a bug, with Python 3.3.2 on Windows XP and console with chcp 65001 and Lucida Console: just build a string "s" with characters 945 to 969 (it's the greek alphabet). Then just try to show "s" (not even calling "print"). It's printed on three lines, with "s" on the first and garbage and the two others. –  Jul 31 '13 at 07:45
  • 7
    Interesting question here though - is the bug because it should report bytes and instead reports characters - or because the applications using it have assumed bytes=characters incorrectly? In other words, is it an API fail or an API usage fail? – Basic Nov 27 '13 at 13:04
  • 4
    Updated Kaplan blog on broken UTF-8 in windows [available here](http://www.siao2.com/2006/03/13/550191.aspx), since Microsoft deleted all his blog posts after he rubbed a higher-up the wrong way. – alexchandel Sep 11 '15 at 04:51
  • 1
    Doesn't work for me with Hebrew characters in Windows 10 (Lucida console + `chcp 65001`), – Ohad Schneider Dec 25 '16 at 22:16
  • 2
    Better use the font "Consolas". Lucida Console is missing unicode characters like 02B9 . – asmaier Jan 15 '17 at 12:24
  • 2
    To make utf-8 the default encoding: go to `[HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\Autorun]` and set it to `chcp 65001` – maviz Mar 05 '17 at 01:36
  • 5
    The console's (conhost.exe) support for codepage 65001 is fundamentally broken (for both input and output in Windows 7, but still broken for input in Windows 10). Please remove this suggestion to avoid repeating this bad advice in an endless loop of naive 'help'. The cmd shell is a Unicode application that uses the console's UTF-16 API and base APIs `CreateProcessW` and `ShellExecuteExW`. If there's a problem with handling the command-line, it's because the application is using the ANSI encoded `char *` version from a standard C `main` instead of the `wchar_t *` from a `wmain` entry point. – Eryk Sun Mar 05 '17 at 17:30
  • Due to the poor support, you're better off using alternative consoles if you need reliable Unicode. Like `Console2` for Windows programs and `mintty` for Cygwin ones (that's the reason why they rolled out `mintty` in the first place). – ivan_pozdeev Oct 28 '17 at 02:23
  • @eryksun what about the font? I get an impression that `cmd` fundamentally uses 8-bit character points for display, so it cannot possibly support more than 256 at a time. – ivan_pozdeev Oct 28 '17 at 02:32
  • 1
    @ivan_pozdeev, CMD is a standard I/O shell, not a console or terminal. For console handles, it uses the Unicode console functions `ReadConsoleW` and `WriteConsoleW`, which read and write UTF-16 text from and to its attached console host process, conhost.exe. If a file handle is not a console (e.g. reading a batch file or reading piped input from a `for /f` loop, or redirecting `dir` to a pipe), CMD's built-in commands use the console's input or output codepage as the encoding. For output, you can override this to UTF-16 via CMD's `/u` option. – Eryk Sun Oct 28 '17 at 05:00
  • 1
    @ivan_pozdeev, the console uses 16-bit character cells. In principle it can display any character in the BMP. However, it doesn't use Uniscribe/DirectWrite, so it doesn't support complex scripts (e.g. right-to-left text) or automatic fallback fonts. Manual font linking in the registry is possible, but the results aren't very good, so in practice it's limited to what the current font supports. A character beyond the BMP is written as a UTF-16 surrogate pair in two logically separate cells, so it renders as two default glyphs (e.g. empty boxes), but it can be copied to the clipboard fine. – Eryk Sun Oct 28 '17 at 05:07
  • 3
    **–1** UTF-8 in consoles works only partially and only for output. Additionally the question isn't about i/o but about command line arguments. Over 300 incompetents so far have upvoted this advice. That's impressive. – Cheers and hth. - Alf Nov 04 '17 at 19:28
  • 1
    @Cheersandhth.-Alf, the header is quite generic, I assume that's the reason why many search-engines will hit this page first. However, apart from undoubted limitation/bug I think `chcp 65001` is sufficient for 99% of people having problem with "Unicode in command line" – Wernfried Domscheit Feb 06 '18 at 11:03
  • 1
    @WernfriedDomscheit: What was the first part of “UTF-8 in consoles works only partially and only for output” that you failed to understand? – Cheers and hth. - Alf Feb 06 '18 at 17:11
  • 1
    @Cheersandhth.-Alf, I understand the issue. However for a typical usecase for example `echo € > euro.txt` and `type euro.txt` the solution is sufficient for most of the people. Such commands do not work with codepage 850 (the default for western europe) – Wernfried Domscheit Feb 06 '18 at 18:23
  • 2
    "the solution is sufficient for most of the people" It's not a solution. It's advice akin to pouring sugar in car's gas tank, plain sabotage. And regarding "I understand the issue", no you do not. Given that claim I advice to read up on the the Dunning-Kruger effect. – Cheers and hth. - Alf Feb 06 '18 at 19:28
  • 3
    @Cheers and hth. - Alf: Almost 300K people came to this question, because of the title. The vast majority didn't read the body of the question. They immediately copied and pasted the code from the first answer, it worked for them, up voted and continued with their lives. They most probably won't have to deal again with Windows Command Prompt intricacies. They just wanted to run a simple program and get on with their work. They don't need the deep expertise, you obviously possess and they aren't incompetents. You don't have to be rude. – kgiannakakis Feb 07 '18 at 09:00
  • @OhadSchneider windows version <=1709 can't use chcp and I failed too. – Rick Jun 06 '18 at 16:28
87

My background: I use Unicode input/output in a console for years (and do it a lot daily. Moreover, I develop support tools for exactly this task). There are very few problems, as far as you understand the following facts/limitations:

  • CMD and “console” are unrelated factors. CMD.exe is a just one of programs which are ready to “work inside” a console (“console applications”).
  • AFAIK, CMD has perfect support for Unicode; you can enter/output all Unicode chars when any codepage is active.
  • Windows’ console has A LOT of support for Unicode — but it is not perfect (just “good enough”; see below).
  • chcp 65001 is very dangerous. Unless a program was specially designed to work around defects in the Windows’ API (or uses a C runtime library which has these workarounds), it would not work reliably. Win8 fixes ½ of these problems with cp65001, but the rest is still applicable to Win10.
  • I work in cp1252. As I already said: To input/output Unicode in a console, one does not need to set the codepage.

The details

  • To read/write Unicode to a console, an application (or its C runtime library) should be smart enough to use not File-I/O API, but Console-I/O API. (For an example, see how Python does it.)
  • Likewise, to read Unicode command-line arguments, an application (or its C runtime library) should be smart enough to use the corresponding API.
  • Console font rendering supports only Unicode characters in BMP (in other words: below U+10000). Only simple text rendering is supported (so European — and some East Asian — languages should work fine — as far as one uses precomposed forms). [There is a minor fine print here for East Asian and for characters U+0000, U+0001, U+30FB.]

Practical considerations

  • The defaults on Window are not very helpful. For best experience, one should tune up 3 pieces of configuration:

    • For output: a comprehensive console font. For best results, I recommend my builds. (The installation instructions are present there — and also listed in other answers on this page.)
    • For input: a capable keyboard layout. For best results, I recommend my layouts.
    • For input: allow HEX input of Unicode.
  • One more gotcha with “Pasting” into a console application (very technical):

    • HEX input delivers a character on KeyUp of Alt; all the other ways to deliver a character happen on KeyDown; so many applications are not ready to see a character on KeyUp. (Only applicable to applications using Console-I/O API.)
    • Conclusion: many application would not react on HEX input events.
    • Moreover, what happens with a “Pasted” character depends on the current keyboard layout: if the character can be typed without using prefix keys (but with arbitrary complicated combination of modifiers, as in Ctrl-Alt-AltGr-Kana-Shift-Gray*) then it is delivered on an emulated keypress. This is what any application expects — so pasting anything which contains only such characters is fine.
    • However, the “other” characters are delivered by emulating HEX input.

    Conclusion: unless your keyboard layout supports input of A LOT of characters without prefix keys, some buggy applications may skip characters when you Paste via Console’s UI: Alt-Space E P. (This is why I recommend using my keyboard layouts!)

One should also keep in mind that the “alternative, ‘more capable’ consoles” for Windows are not consoles at all. They do not support Console-I/O APIs, so the programs which rely on these APIs to work would not function. (The programs which use only “File-I/O APIs to the console filehandles” would work fine, though.)

One example of such non-console is a part of MicroSoft’s Powershell. I do not use it; to experiment, press and release WinKey, then type powershell.


(On the other hand, there are programs such as ConEmu or ANSICON which try to do more: they “attempt” to intercept Console-I/O APIs to make “true console applications” work too. This definitely works for toy example programs; in real life, this may or may not solve your particular problems. Experiment.)

Summary

  • set font, keyboard layout (and optionally, allow HEX input).

  • use only programs which go through Console-I/O APIs, and accept Unicode command-line arguments. For example, any cygwin-compiled program should be fine. As I already said, CMD is fine too.

UPD: Initially, for a bug in cp65001, I was mixing up Kernel and CRTL layers (UPD²: and Windows user-mode API!). Also: Win8 fixes one half of this bug; I clarified the section about “better console” application, and added a reference to how Python does it.

Ilya Zakharevich
  • 1,070
  • 8
  • 6
  • 2
    OK, for something **this** thorough, you deserve to be the accepted answer! Awesome! – Vilx- Dec 16 '17 at 13:02
  • 12
    I am a newbie to C++ and can't understand this answer after reading carefully. Can somebody help me about this or make a easier explanation? – Rick Jun 06 '18 at 14:13
  • @Bachi Thanks to Bachi, I found out that v73 of my keyboard layout (mentioned above) was missing some support files. Now fixed! (Judging by my `.log` files, it is an intermittent bug in `zip -ru` [?!]. Have no clue how to debug it — or avoid in the future…) – Ilya Zakharevich Sep 20 '18 at 02:50
  • @Rick: Right! I added a link to a workaround in Python (but I cannot find a direct link to the patch right now…). – Ilya Zakharevich Sep 20 '18 at 03:51
  • @IlyaZakharevich :D Thank you. But I somehow give up using unicode on Windows. I am going to use Linux laterly. – Rick Sep 20 '18 at 04:14
  • 1
    Bugs in the console are not in the kernel. The APIs in kernel32.dll and kernelbase.dll typically interface to system calls exported by ntdll.dll. The console API ultimately makes either I/O calls (e.g. `NtReadFile`, `NtDeviceIoControlFile`) in Windows 8+ or LPC calls in older versions. These system calls go *through* the kernel (e.g. via the ConDrv device in Win 8+), but ultimately they're implemented in the user-mode console host process. This is either an instance of conhost.exe in Windows 7+ or, in older versions, the session subsystem process, csrss.exe. Console bugs are usually here. – Eryk Sun Sep 20 '18 at 14:14
  • It seems like the real (Unix-grade) UTF-8 support in Windows consoles is under way: https://github.com/Microsoft/console/issues/190 and https://github.com/Microsoft/WSL/issues/75. – vulcan raven Dec 16 '18 at 00:04
  • the Windows 10 cmd supports UTF-8 much better than previous versions [Windows Command-Line: Unicode and UTF-8 Output Text Buffer](https://blogs.msdn.microsoft.com/commandline/2018/11/15/windows-command-line-unicode-and-utf-8-output-text-buffer/) – phuclv Feb 20 '19 at 05:06
  • @phuclv: they *claim* that they do — but I did not see any **example** of what would work better than what is on Win7. Moreover, IIUC, this is **going to appear** at some moment — last time I checked, it looked like their changes were not accessible from outside of the kernel. (So: IIUC, one would need to open a handle to a certain driver — it is not “just writing to STDOUT”. I may be wrong — but it is hard to extract technical details from all the flack they create). – Ilya Zakharevich Feb 21 '19 at 06:59
  • "more capable consoles" can now be real consoles by using the [Pseudo Console API](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/). Microsoft now makes an official "more capable console", [Windows Terminal](https://devblogs.microsoft.com/commandline/windows-terminal-1-0/). – user31708 Jun 13 '20 at 18:36
  • Changing the font to `DejaVu Sans Mono Unifont` displays broken characters for korean and chinese on CMD and `Unifont` is not avaiable for CMD when it works on Microsoft Word. – PHD Sep 20 '20 at 13:33
  • You need to be more specific in your complaints. (Especially in your “`Unifont` is not avaiable for CMD”.) I may only guess that you mean that the “Mono” variant includes only those characters which make sense in 3:2 aspect ratio. (I have plans to make another flavor “including the remaining characters anyway”, but could not find time to work on this during last couple of years.) – Ilya Zakharevich Oct 05 '20 at 03:19
37

I had same problem (I'm from the Czech Republic). I have an English installation of Windows, and I have to work with files on a shared drive. Paths to the files include Czech-specific characters.

The solution that works for me is:

In the batch file, change the charset page

My batch file:

chcp 1250
copy "O:\VEŘEJNÉ\ŽŽŽŽŽŽ\Ž.xls" c:\temp

The batch file has to be saved in CP 1250.

Note that the console will not show characters correctly, but it will understand them...

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
vanna
  • 379
  • 3
  • 2
  • 1
    Cheers! I needed this so that I could input the copyright character within my batch file. – Lea Hayes Jul 30 '12 at 03:18
  • This worked perfectly for me too in an almost identical situation to yours. Instead my path contained Irish Gaelic characters i.e. `á`, `é`, `í`, `ó`, and `ú`. – Seany84 Feb 04 '14 at 21:43
  • @vanna that solves my "Turkish characters and spaces in path on network problem". you are great. – caglaror Dec 04 '14 at 11:39
  • Also find these resources: http://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx , http://ss64.com/nt/chcp.html , http://technet.microsoft.com/en-us/library/bb490874.aspx Turkish chcp is 857 . – caglaror Dec 04 '14 at 11:42
  • 2
    You probably just needed to use different font to also display the characters correctly, *Lucida Console* worked for me. – Vlastimil Ovčáčík Jan 05 '16 at 11:38
  • "Windows-1250 is a code page used under Microsoft Windows to represent texts in Central European and Eastern European languages that use Latin script, such as Polish, Czech, Slovak, Hungarian, Slovene, Bosnian, Croatian, Serbian (Latin script), Romanian (before 1993 spelling reform) and Albanian." – endolith Nov 29 '16 at 15:36
  • `cp1250` is still an 8-bit character set, it still only supports 256 characters, just changes what those characters are. – ivan_pozdeev Oct 28 '17 at 02:36
  • Finally useful answer! Displayed chars still garbled but the arguments (filenames with accents) are now passed to called programs correctly. Thank you! (I'm from CZ as well) – Pontiac_CZ Nov 14 '18 at 19:39
30

Check the language for non-Unicode programs. If you have problems with Russian in the Windows console, then you should set Russian here:

Changing language for non-Unicode programs

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Maxim Yefremov
  • 12,753
  • 25
  • 112
  • 158
  • 7
    That doesn't enable support for Unicode in `cmd`, it only switches the default codepage to `cp866` which is still an 8-bit character set. It even uses `cp866` instead of `cp1251` which adds its own shitload of trouble. – ivan_pozdeev Oct 28 '17 at 02:30
  • 1
    See also me answer below for new option in newer Windows 10 versions – zvi Apr 14 '19 at 11:33
16

It's is quite difficult to change the default Codepage of Windows console. When you search the web you find different proposals, however some of them may break your Windows entirely, i.e. your PC does not boot anymore.

The most secure solution is this one: Go to your Registry key HKEY_CURRENT_USER\Software\Microsoft\Command Processor and add String value Autorun = chcp 65001.

Or you can use this small Batch-Script for the most common code pages.

@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
)

Using @chcp 65001>nul instead of chcp 65001 suppresses the output "Active code page: 65001" you would get every time you start a new command line windows.

A full list of all available number you can get from Code Page Identifiers

Note, the settings will apply only for the current user. If you like to set it for all users, replace line SET ROOT_KEY="HKEY_CURRENT_USER" by SET ROOT_KEY="HKEY_LOCAL_MACHINE"

Wernfried Domscheit
  • 46,769
  • 7
  • 65
  • 91
14

Actually, the trick is that the command prompt actually understands these non-english characters, just can't display them correctly.

When I enter a path in the command prompt that contains some non-english chracters it is displayed as "?? ?????? ?????". When you submit your command (cd "??? ?????? ?????" in my case), everything is working as expected.

User
  • 29,367
  • 21
  • 77
  • 107
  • 2
    This is probably a bit dangerous as you could get naming conflict. e.g., if you have two files both which render as "???", and you enter "cd ???" it wouldn't know which to use (or worse would choose an arbitrary one). – John Jun 16 '09 at 13:53
  • 30
    You don't enter ???, you enter the real name it's just being displayed as ???. Think of it as of a password input box. Whatever you enter is displayed as ***, but submitted is the original text. – User Jun 16 '09 at 14:52
  • This did indeed works for commands run directly in the command prompt. However, with running a `.cmd` batch file, I still need to put `chcp 65001` at the top of of the batch file. – wisbucky Oct 23 '17 at 22:07
  • In your case, it is a font problem... the content is there, just no proper font to display it. But OP is different. – WesternGun Oct 30 '17 at 12:58
12

On a Windows 10 x64 machine, I made the command prompt display non-English characters by:

Open an elevated command prompt (run CMD.EXE as administrator). Query your registry for available TrueType fonts to the console by:

    REG query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont"

You'll see an output like:

    0    REG_SZ    Lucida Console
    00    REG_SZ    Consolas
    936    REG_SZ    *新宋体
    932    REG_SZ    *MS ゴシック

Now we need to add a TrueType font that supports the characters you need like Courier New. We do this by adding zeros to the string name, so in this case the next one would be "000":

    REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 000 /t REG_SZ /d "Courier New"

Now we implement UTF-8 support:

    REG ADD HKCU\Console /v CodePage /t REG_DWORD /d 65001 /f

Set default font to "Courier New":

    REG ADD HKCU\Console /v FaceName /t REG_SZ /d "Courier New" /f

Set font size to 20:

    REG ADD HKCU\Console /v FontSize /t REG_DWORD /d 20 /f

Enable quick edit if you like:

    REG ADD HKCU\Console /v QuickEdit /t REG_DWORD /d 1 /f
Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Alon Or
  • 728
  • 7
  • 7
  • 4
    In general using codepage 65001 will only work without bugs in Windows 10 with the Creators update. In Windows 7 it will have both output and input bugs. In Windows 8 and older versions of Windows 10 it only has the input bug, which limits input to 7-bit ASCII. – Eryk Sun Sep 09 '17 at 13:43
  • I tried using this method, and now the font is super small and it seem it is permanent. – Green Oct 18 '20 at 06:41
7

One really simple option is to install a Windows bash shell such as MinGW and use that:

Enter image description here

There is a little bit of a learning curve as you will need to use Unix command line functionality, but you will love the power of it and you can set the console character set to UTF-8.

Enter image description here

Of course you also get all the usual *nix goodies like grep, find, less, etc.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Steve Barnes
  • 26,342
  • 6
  • 60
  • 70
  • In this (old) case, the issue was with a script rather than a console. Would using bash scripts solve this? – Vilx- Jan 02 '16 at 15:32
  • Yes indeed they wood bash scripts can be flagged as UTF-8 and just work with a lot more power than windows batch files - I know that it was an old case but thought the option was worth flagging for future reference as MS don't seem to be getting much better at Unicode. – Steve Barnes Jan 02 '16 at 21:46
  • 1
    [grep](http://en.wikipedia.org/wiki/Grep), [find](http://en.wikipedia.org/wiki/Find), and [less](https://en.wikipedia.org/wiki/Less_(Unix)). – Peter Mortensen Jan 01 '17 at 23:47
  • Outputting UTF-8 encoded characters are fine. But input is still encoded by system codepage. – Rick Jun 06 '18 at 14:01
  • 1
    Just to add that Windows users may already have a bash shell if you use Git: just open a **Git > Git Bash** window. – skomisa Sep 25 '18 at 01:53
7

I found this method as useful in new versions of Windows 10:

Turn on this feature: "Beta: Use Unicode UTF-8 for worldwide language support"

Control panel -> Regional settings -> Administrative tab-> Change system locale...

Region Settings

zvi
  • 3,032
  • 1
  • 23
  • 40
  • How to achieve this by using powershell or cmd? – Corey Nov 19 '19 at 00:48
  • 1
    I'm trying to display Chinese characters in the console and doing this didn't work on Windows 10 64-bit (Installed in Turkish and later changed to English). Next, I'll try to install Chinese language and see if it works. – akinuri Apr 25 '20 at 12:02
  • 2
    Just be careful with this, it broke the functionality of some old and crappy programs that were working fine in server 2019. – Alon Or Jan 26 '21 at 15:52
6

As I haven't seen any full answers for Python 2.7, I'll outline the two important steps and an optional step that is quite useful.

  1. You need a font with Unicode support. Windows comes with Lucida Console which may be selected by right-clicking the title bar of command prompt and clicking the Defaults option. This also gives access to colours. Note that you can also change settings for command windows invoked in certain ways (e.g, open here, Visual Studio) by choosing Properties instead.
  2. You need to set the code page to cp65001, which appears to be Microsoft's attempt to offer UTF-7 and UTF-8 support to command prompt. Do this by running chcp 65001 in command prompt. Once set, it remains this way until the window is closed. You'll need to redo this every time you launch cmd.exe.

For a more permanent solution, refer to this answer on Super User. In short, create a REG_SZ (String) entry using regedit at HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor and name it AutoRun. Change the value of it to chcp 65001. If you don't want to see the output message from the command, use @chcp 65001>nul instead.

Some programs have trouble interacting with this encoding, MinGW being a notable one that fails while compiling with a nonsensical error message. Nonetheless, this works very well and doesn't cause bugs with the majority of programs.

Community
  • 1
  • 1
Aaron3468
  • 1,664
  • 15
  • 28
6

Starting June 2019, with Windows 10, you won't have to change the codepage.

See "Introducing Windows Terminal" (from Kayla Cinnamon) and the Microsoft/Terminal.
Through the use of the Consolas font, partial Unicode support will be provided.

As documented in Microsoft/Terminal issue 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.
VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
4

This problem is quite annoying. I usually have Chinese character in my filename and file content. Please note that I am using Windows 10, here is my solution:

To display the file name, such as dir or ls if you installed Ubuntu bash on Windows 10

  1. Set the region to support non-utf 8 character.

  2. After that, console's font will be changed to the font of that locale, and it also changes the encoding of the console.

After you have done previous steps, in order to display the file content of a UTF-8 file using command line tool

  1. Change the page to utf-8 by chcp 65001
  2. Change to the font that supports utf-8, such as Lucida Console
  3. Use type command to peek the file content, or cat if you installed Ubuntu bash on Windows 10
  4. Please note that, after setting the encoding of the console to utf-8, I can't type Chinese character in the cmd using Chinese input method.

The laziest solution: Just use a console emulator such as http://cmder.net/

code4j
  • 3,778
  • 3
  • 32
  • 51
3

For a similar problem, (my problem was to show UTF-8 characters from MySQL on a command prompt),

I solved it like this:

  1. I changed the font of command prompt to Lucida Console. (This step must be irrelevant for your situation. It has to do only with what you see on the screen and not with what is really the character).

  2. I changed the codepage to Windows-1253. You do this on the command prompt by "chcp 1253". It worked for my case where I wanted to see UTF-8.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Christoforos
  • 534
  • 2
  • 10
  • 8
    Windws-1253 isn't an Unicode codepage. It's a standard 256-character codepage. Apparently you only used characters that can be displayed in that codepage, but it won't be universal. – Vilx- Dec 02 '12 at 13:05
2

A quick decision for .bat files if you computer displays your path/file name correct when you typing it in DOS-window:

  1. copy con temp.txt [press Enter]
  2. Type the path/file name [press Enter]
  3. Press Ctrl-Z [press Enter]

This way you create a .txt file - temp.txt. Open it in Notepad, copy the text (don't worry it will look unreadable) and paste it in your .bat file. Executing the .bat created this way in DOS-window worked for mе (Cyrillic, Bulgarian).

S. Hristov
  • 71
  • 3
2

I see several answers here, but they don't seem to address the question - the user wants to get Unicode input from the command line.

Windows uses UTF-16 for encoding in two byte strings, so you need to get these from the OS in your program. There are two ways to do this -

1) Microsoft has an extension that allows main to take a wide character array: int wmain(int argc, wchar_t *argv[]); https://msdn.microsoft.com/en-us/library/6wd819wh.aspx

2) Call the windows api to get the unicode version of the command line wchar_t win_argv = (wchar_t)CommandLineToArgvW(GetCommandLineW(), &nargs); https://docs.microsoft.com/en-us/windows/desktop/api/shellapi/nf-shellapi-commandlinetoargvw

Read this: http://utf8everywhere.org for detailed info, particularly if you are supporting other operating systems.

Robert Boehne
  • 279
  • 4
  • 11
  • Ahh, no, I'm sorry, but you missed the question. This is for when I'm writing a program that will **receive** the unicode characters. My question was about **sending** the unicode characters to another program (which hopefully supports receiving them, but I really have no way to know except disassembly). – Vilx- Aug 31 '18 at 15:24
1

A better cleaner thing to do: Just install the available, free, Microsoft Japanese language pack. (Other oriental language packs will also work, but I have tested the Japanese one.)

This gives you the fonts with the larger sets of glyphs, makes them the default behavior, changes the various Windows tools like cmd, WordPad, etc.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Mike Beckerle
  • 685
  • 5
  • 13
1

Changing code page to 1252 is working for me. The problem for me is the symbol double doller § is converting to another symbol by DOS on Windows Server 2008.

I have used CHCP 1252 and a cap before it in my BCP statement ^§.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
madhav bitra
  • 135
  • 3
  • Thanks it works! I don't know why people voted this down, it is a valid alternative for some people.. This codepage 1252 does fix the problem also on Windows Server 2012, where the same code with CP 65001 did not work for me. I suppose it depends in what codepage the batch script was edited with, or the OS defaults. In this case it was created with Notepad on a German MUI machine with en-US base OS.. – Tony Wall Jan 05 '17 at 13:15
1

I got around a similar issue deleting Unicode-named files by referring to them in the batch file by their short (8 dot 3) names.

The short names can be viewed by doing dir /x. Obviously, this only works with Unicode file names that are already known.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Michael
  • 11
  • 1
  • new disks have [8.3 name generation disabled by default](https://ss64.com/nt/syntax-filenames.html) and this won't work – phuclv Apr 17 '21 at 07:14