Unicode in Microsoft Windows
was one of the first companies to implement Unicode in their products. Windows NT was the first operating system that used "wide characters" in system calls. Using the UCS-2 encoding scheme at first, it was upgraded to the variable-width encoding UTF-16 starting with Windows 2000, allowing a representation of additional planes with surrogate pairs. However Microsoft did not support UTF-8 in its API until May 2019.
Before 2019, Microsoft emphasized UTF-16, but has since recommended to use UTF-8, on Windows and Xbox, even states "UTF-8 is the universal code page for internationalization UTF-16 a unique burden that Windows places on code that targets multiple platforms. Windows moving forward to support UTF-8 to remove this unique burden in fewer internationalization issues in apps and games".
A large amount of Microsoft documentation uses the word "Unicode" to refer explicitly to the UTF-16 encoding. Anything else, including UTF-8, is not "Unicode" in Microsoft's outdated language.
In various Windows families
Windows NT based systems
Current Windows versions and all back to Windows XP and prior Windows NT are shipped with system libraries that support string encoding of two types: 16-bit "Unicode" and a encoding called the "code page". 16-bit functions have names suffixed with 'W' such asSetWindowTextW. Code page oriented functions use the suffix 'A' for "ANSI" such as SetWindowTextA. This split was necessary because many languages, including C, did not provide a clean way to pass both 8-bit and 16-bit strings to the same function.Microsoft attempted to support Unicode "portably" by providing a "UNICODE" switch to the compiler, that switches unsuffixed "generic" calls from the 'A' to the 'W' interface and converts all string constants to "wide" UTF-16 versions. This does not actually work because it does not translate UTF-8 outside of string constants, resulting in code that attempts to open files just not compiling.
Earlier, and independent of the "UNICODE" switch, Windows also provided the Multibyte Character Sets API switch. This changes some functions that don't work in MBCS such as
strrev to an MBCS-aware one such as _mbsrev.Windows CE
In Windows CE, UTF-16 was used almost exclusively, with the 'A' API mostly missing. A limited set of ANSI API is available in Windows CE 5.0, for use on a reduced set of locales that may be selectively built onto the runtime image.Windows 9x
In 2001, Microsoft released a special supplement to Microsoft's old Windows 9x systems, which was described as providing "a layer over the Win32 API on Windows 95/98/Me so that a software developer can write a single Unicode version of their application and have it run properly on all platforms." It includes a dynamic link library, 'unicows.dll', containing the 16-bit flavor of all the basic functions of Windows API. It is merely a translation layer:SetWindowTextW will simply convert its input using the current codepage and call SetWindowTextA on Windows 9x, while Windows NT systems will pass through to the OS version of SetWindowTextW.Alternatives exist, among them, "", a free re-implementation of the MSLU by Mozilla. Open source versions of the link library are also available, which can be used with the original or.
UTF-8
Microsoft Windows explicit conversion functions such as MultiByteToWideChar and/or b) the Win32 console commandchcp 65001 to translate stdin/out between UTF-8 and UTF-16. This meant that "narrow" functions, in particular fopen, couldn't be called with UTF-8 strings, and in fact there was no way to open all possible files using fopen no matter what the locale was set to and/or what bytes were put in the string, as none of the available locales could produce all possible UTF-16 characters. This problem also applied to all other APIs that take or return 8-bit strings, including Windows ones such as SetWindowText.Programs that wanted to use UTF-8, in particular code intended to be portable to other operating systems, needed a workaround for this deficiency. The usual work-around was to add new functions to open files that convert UTF-8 to UTF-16 using MultiByteToWideChar and call the "wide" function instead of
fopen. Dozens of multi-platform libraries added wrapper functions to do this conversion on Windows, an example is a proposed addition to Boost,. Another popular work-around was to convert the name to the 8.3 filename equivalent, this is necessary if the fopen is inside a library. None of these workarounds are considered good, as they require changes to the code that works on non-Windows.In April 2018, with insider build 17035 for Windows 10, a "Beta: Use Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8. This allows for calling "narrow" functions, including
fopen and SetWindowTextA, with UTF-8 strings. However this is a system-wide setting and a program cannot assume it is set.In May 2019, Microsoft added the ability for a program to set the code page to UTF-8 itself, allowing programs written to use UTF-8 to be run by non-expert users.
, Microsoft recommends programmers use UTF-8, on Windows and Xbox, and may be recommending its use instead of UTF-16, even stating "UTF-8 is the universal code page for internationalization UTF-16 is a unique burden that Windows places on code that targets multiple platforms." Microsoft does appear to be transitioning to UTF-8, stating it previously emphasized its alternative, and in Windows 11 some system files are required to use UTF-8 and do not require a Byte Order Mark. Notepad can now recognize UTF-8 without the Byte Order Mark, and can be told to write UTF-8 without a Byte Order Mark. Some other Microsoft products are using UTF-8 internally, including Visual Studio and their SQL Server 2019, with Microsoft claiming 35% speed increase from use of UTF-8, and "nearly 50% reduction in storage requirements."