René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Need \"ANSI\" encoding enumeration value to support \"ANSI\"-code-page-encoded files (e.g., Windows 1252)","articleBody":"As discussed in #6550:\r\n\r\nWhile 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.\r\n(In _Windows PowerShell_, the `Default` value fulfills that role, but in PowerShell Core `Default` now refers to the new default, (BOM-less) UTF-8.)\r\n\r\nTherefore, an `ANSI` encoding value should be introduced to complement the `OEM` value.\r\n\r\nWith `ANSI` available, the current workaround:\r\n\r\n```powershell\r\nGet-Content -Encoding ([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage) file.txt\r\n```\r\n\r\nwould simply become:\r\n\r\n```powershell\r\nGet-Content -Encoding Ansi file.txt   # Wishful thinking.\r\n```\r\n\r\nNote: 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.)\r\n\r\nEnvironment data\r\n----------------\r\n\r\nWritten as of:\r\n\r\n```powershell\r\nPowerShell Core v6.0.2\r\n```\r\n","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2018-04-04T19:10:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":12},"url":"https://github.com/6562/PowerShell/issues/6562"}