Repository navigation
Invoke-WebRequest's .ToString() assumes content is ASCII #27154
Description
Activity
toString() is a fuzzy "preview" function, not the recommended way to process production data. The challenge is: with text and non-BOM-encoding, there is no way other than heuristically to determine the original encoding.
So toString() must pick one encoding in random best effort. Or is there a reliable HTTP header information that reveals the encoding? I am not much of a HTTP expert I admit.
- moved this from Queue to In-Progress-Issues in Cmdlets Working Group
on Jul 15, 2026 @PowerShell/wg-powershell-cmdlets discussed this. We believe in most cases the encoding should be available as part of the header. If not, it would make sense to default to utf-8 instead of ASCII.
- added and removed
on Jul 15, 2026 - moved this from In-Progress-Issues to Reviewed in Cmdlets Working Group
on Jul 15, 2026
Prerequisites
Steps to reproduce
When you call .ToString() on a response from Invoke-WebRequest the code here assumes ascii in the content body
https://github.com/PowerShell/PowerShell/blob/45a80d9a4894802a61637cc7c8843bc66b0bcc5d/src/Microsoft.PowerShell.Commands.Utility/commands/utility/WebCmdlet/Common/WebResponseObject.Common.cs#L187C13-L187C69
If the content is non-ascii this causes characters to be converted to '???'
Expected behavior
Non-ascii characters in the response body remain unchangedActual behavior
Non-ascii characters become '???'Error details
Environment data
Visuals
No response