Up to at least PowerShell 7.0, a bug in the underlying. This means that, in the absence of an -Encoding argument, BOM-less files that are ANSI-encoded (which is historically common) will then be misread, and files created with Set-Content will be UTF-8 rather than ANSI-encoded. If you're using Windows PowerShell, this will also make Get-Content and Set-Content and other contexts where Windows PowerShell default so the system's active ANSI code page, notably reading source code from BOM-less files, default to UTF-8 (which PowerShell Core (v6+) always does). This sets both the system's active OEM and the ANSI code page to 65001, the UTF-8 code page, which therefore (a) makes all future console windows, which use the OEM code page, default to UTF-8 (as if chcp 65001 had been executed in a cmd.exe window) and (b) also makes legacy, non-Unicode GUI-subsystem applications, which (among others) use the ANSI code page, use UTF-8. Follow the instructions in the screen shot below.Run intl.cpl (which opens the regional settings in Control Panel).If, by contrast, your concern is about the separate aspect of the limitations of Unicode character rendering in console windows, see the middle and bottom sections of this answer, where alternative console (terminal) applications are discussed too.ĭoes Microsoft provide an improved / complete alternative to chcp 65001 that can be saved permanently without manual alteration of the Registry?Īs of (at least) Windows 10, version 1903, you have the option to set the system locale ( language for non-Unicode programs) to UTF-8, but the feature is still in beta as of this writing.

UTF-8 (code page 65001), so that shells such as cmd.exe and PowerShell properly encode and decode characters (text) when communicating with external (console) programs with full Unicode support, and in cmd.exe also for file I/O. This answer shows how to switch the character encoding in the Windows console to

Windows terminal powershell 7