ANSI Code Page in Hyper-V Windows containers should not be 65001

[neberson]

Description
When running a Windows container with Hyper-V isolation, the system ANSI Code Page (ACP) is set to 65001, which corresponds to the UTF-8 code page, rather than to an "ordinary" code page.

For Windows Desktop, this is a Beta feature called "Beta: Use Unicode UTF-8 for worldwide language support":

As this causes incompatibilities with software that doesn't support UTF-8, it should not be enabled in containers by default.

Most notoriously, this happens with SQL Server: microsoft/mssql-docker#466 (comment)
But it also affects other software: https://social.msdn.microsoft.com/Forums/en-US/0c4a2452-efd5-4e39-bd58-9748201e1670/codepages-in-servercorenanoserver?forum=windowscontainers
Another example: conda/conda#8088
Repro steps without SQL Server:

Execute docker run -it --rm --isolation=hyperv mcr.microsoft.com/windows/servercore:1903 powershell
Inside the PowerShell, run this:
$Signature = "[DllImport("kernel32.dll")] public static extern int GetACP();";$acpGetter = Add-Type -MemberDefinition $Signature -Name "Acp" -Namespace Win32Functions -PassThru; $acpGetter::GetACP()
Observe the results
Describe the results you received:

With process isolation: 1252 (an "ordinary" code page)
With Hyper-V isolation: 65001 (the UTF-8 code page)
Describe the results you expected:
The selected code page shouldn't be determined by a beta feature that's not enabled on the host, regardless of the isolation mode. So it should either

be the same as on the host OS (in my case, 1252),
be hardcoded to something more friendly to non-UTF-8 applications,
or be configurable at container start.
Output of docker version:

Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:22:37 2019
OS/Arch: windows/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.24)
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:36:50 2019
OS/Arch: windows/amd64
Experimental: false
Output of docker info:

Client:
Debug Mode: false

Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 7
Server Version: 19.03.5
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 18362 (18362.1.amd64fre.19h1_release.190318-1202)
Operating System: Windows 10 Pro Version 1903 (OS Build 18362.592)
OSType: windows
Architecture: x86_64
CPUs: 12
Total Memory: 31.85GiB
Name: W1119
ID: 6SEL:LRZQ:3NZL:TEA3:KE36:A6UU:Y4WU:EXDA:PRKO:QSZQ:QQA3:V4WU
Docker Root Dir: D:\DockerData
Debug Mode: true
File Descriptors: -1
Goroutines: 28
System Time: 2020-02-17T15:21:58.5160558+01:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

[github-actions]

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

[ntrappe-msft]

Thanks for bringing up this issue. I'll discuss this with my team and whether it makes more sense to have the container's code page (a) inherit the host settings, (b) use a default that's more backwards compatible with non-UTF-8 apps, or (c) be configurable. In the meantime, can you explain more about your use case and why this is relevant?

[neberson]

Thanks for bringing up this issue. I'll discuss this with my team and whether it makes more sense to have the container's code page (a) inherit the host settings, (b) use a default that's more backwards compatible with non-UTF-8 apps, or (c) be configurable. In the meantime, can you explain more about your use case and why this is relevant?

Hello,

Thank you sincerely for your feedback and the attention you’ve given to this matter. I would like to provide more details about the scenario and the impact that this default encoding configuration is having on our environment.

Use Case
I am developing an API that integrates a legacy ERP, developed in Delphi 2006, via calls to DLLs that operate on the ANSI standard (Windows-1252). Additionally, the Oracle database used by the system is configured to use the same encoding (NLS_LANG = WE8MSWIN1252). In traditional environments (physical hosts or VMs), we set the NLS_LANG environment variable to WE8MSWIN1252 to avoid corruption of special characters (such as ç, ã, á) during read and write operations.

Problem in Containers
When migrating the solution to Windows containers with Hyper-V isolation, we observed that the default ANSI code page is forced to UTF-8 (65001), even when the “Beta: Use Unicode UTF-8” feature is not enabled on the host. This imposition creates two critical issues:

Database Character Corruption: Since Oracle is configured for Windows-1252, it does not correctly interpret the data sent by the API, resulting in the incorrect recording of special characters.

Incompatibility with Legacy DLLs: The ERP’s DLLs, which expect input and output in Windows-1252, end up receiving or returning data with improper encoding, compromising the integrity of business rules.

Impact and Considerations
The inability to adjust the encoding configuration in the container prevents the setting of environment variables (such as NLS_LANG) to enforce the use of Windows-1252, thereby making the migration of legacy applications to containers unfeasible.

It would be ideal if the container’s code page could:

Inherit the host’s configuration (in my case, 1252);

Use a standard more compatible with legacy applications (such as 1252) by default; or

Be configurable at container startup (for example, via a parameter in docker run or an environment variable).

This flexibility would ensure compatibility with legacy systems without compromising the functionality of applications that depend on UTF-8.

Thank you again for your analysis. I remain available to provide further details or collaborate with testing, if necessary.

[ntrappe-msft]

On Windows 10 hosts with the beta "Use Unicode UTF‑8" enabled, GetACP() returns 65001 (UTF‑8), which causes these issues. Note that running chcp inside the container only changes the console display code page, not the underlying system setting.

Our recommendation is to upgrade to newer hosts—like Windows Server 2022, Windows Server 2025, or Windows 11—where GetACP() returns the expected legacy code page (e.g., 1252) even with the beta feature on. This change, along with using container types from these newer hosts, should resolve the compatibility problems.

[neberson]

In the example scenario mentioned, our host machine is configured with the beta feature "Use Unicode UTF‑8" disabled, which is our current standard. With this in mind, I would like to know if it is feasible to use a Windows Server 2019 image as the base for applications that rely on legacy DLLs. Additionally, what configurations will I need to apply to the image to ensure that code page 1252 is used as the default encoding?

[ntrappe-msft]

We found that the Server Core 2019 image has the UTF‑8 beta feature baked into its UVM and ignores any registry tweaks at boot, so you can’t force it back to a legacy code page. To guarantee GetACP() returns 1252 (or another non‑UTF‑8 code page), you’ll need to switch your containers to a Server Core 2022 (or newer) base image.

Let me know if you'd like any specific examples or commands.