wrong file Encoding
See original GitHub issueSteps to reproduce
-
create text file in UTF-8
-
run the follow command in powershell 5
Get-Content <path to UTF8 file> -Encoding UTF8 | Set-Content <path to new output file> -Encoding default
-
the output file will be encoded in ANSI (what is correct)
-
run the follow command in powershell core (6.2.1)
Get-Content <path to UTF8 file> -Encoding UTF8 | Set-Content <path to new output file> -Encoding default
-
the output file will be encoded in UTF8I (what is NOT correct)
Expected behavior
the output file from Set-Content with parameter “-Encoding ANSI” have to bee encoded in ANSI like it does in Powershell 5 and so on
Actual behavior
the output file from Set-Content with parameter “-Encoding default” is encoded in UTF8 what is wrong
Environment data
Name Value
PSVersion 6.2.1 PSEdition Core GitCommitId 6.2.1 OS Microsoft Windows 6.1.7601 S Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0.} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0
Issue Analytics
- State:
- Created 4 years ago
- Comments:36 (9 by maintainers)
@SteveL-MSFT OK got it now. [Encoding] objects don’t work with V5 because of the validate sets in use. That needs to be fixed … but just typing the parameter as [system.text.encoding] won’t allow code pages and “OEM” which leads to
encodingMap
in the code which gets to the right values but looks wrong.@Skybeat Posts like that long one don’t help. As far as anyone here knows, you are the only person impacted by this. You say 25 people in your company use
set-content -encoding default.
If you ask them what it does , how many would say selecting a different code page ? Can any of them can give an example of something which will break if they put ASCII or UTF8 . When you talk “about millions of data in thousands of companies” (which assumes that those companies switch from Windows PowerShell to PowerShell core without testing their scripts first) but no-one else has reported the problem, so it reads like the ranting of a crazy person and instead of helping you people ignore a crazy person. You took a dependency on an old mistake and the fix creates extra work for you (like testing), people should be sympathetic but again, ranting crazy people don’t get sympathy.to the short post. Yes. you can over-ride it with a proxy function. If the version is >5 replace “default” with a code page. Done properly it will generate a warning when it does that so you get told where to check your scripts.
@SteveL-MSFT could you clarify what you mean by “a deliberate decision to enable cross platform support”.
Neither the on-line help nor intellisense suggest “default”. No one should ever use
-encoding default
in code written for PowerShell 6 or 7, so it isn’t a cross platform issue, as far as I can see.I get the feeling that @Skybeat manages systems which aren’t running in English, and “default” gets the right code page but “ASCII” does not, a problem someone working in English doesn’t have.
There is one line of code in PowerShell core which seems to be there to ensure that if a script author put
-encoding "default"
in a scripts for PowerShell 3,4,5 it doesn’t throw an error don’t throw an error, on 6 & 7. But, it appears that the person who put that line in did not understand that “default” here didn’t mean what it usually means. Form @Skybeat 's point of view that misunderstanding means New PowerShell = Corrupt Output.Deleting that one line would force anyone using “default” to get their national code page to make a change, and changing it as I outlined in a previous post would all @Skybeat 's produced the expected out put. Either this was not clear to committee when it was discussed, or if was the benefit of silently corrupting output if a legacy choice is selected needs a little more explanation.