As discussed in #6550:
While you can pass OEM to filesystem cmdlets to support the legacy system locale's OEM code page on Windows, its "ANSI" counterpart (such as Windows 1252 on US-English systems) is currently missing.
(In Windows PowerShell, the Default value fulfills that role, but in PowerShell Core Default now refers to the new default, (BOM-less) UTF-8.)
Therefore, an ANSI encoding value should be introduced to complement the OEM value.
With ANSI available, the current workaround:
Get-Content -Encoding ([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage) file.txt
would simply become:
Get-Content -Encoding Ansi file.txt # Wishful thinking.
Note: Given that OEM already is available even when running on Unix-like platforms, it sounds like we shouldn't restrict ANSI's availability to Windows. ([System.Text.Encoding]::GetEncoding([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage)seemingly does return a locale-appropriate value on Unix-like platforms as well.)
Environment data
Written as of:
As discussed in #6550:
While you can pass
OEMto filesystem cmdlets to support the legacy system locale's OEM code page on Windows, its "ANSI" counterpart (such as Windows 1252 on US-English systems) is currently missing.(In Windows PowerShell, the
Defaultvalue fulfills that role, but in PowerShell CoreDefaultnow refers to the new default, (BOM-less) UTF-8.)Therefore, an
ANSIencoding value should be introduced to complement theOEMvalue.With
ANSIavailable, the current workaround:would simply become:
Note: Given that
OEMalready is available even when running on Unix-like platforms, it sounds like we shouldn't restrictANSI's availability to Windows. ([System.Text.Encoding]::GetEncoding([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage)seemingly does return a locale-appropriate value on Unix-like platforms as well.)Environment data
Written as of:
PowerShell Core v6.0.2