[BUG] Get-PnPFile incorrectly interprets %20 as a space in the file name

[ninos-logic]

Reporting an Issue or Missing Feature

Bug
Get-PnPFile appears to interpret %20 as a space even when %20 is meant to be part of a literal file name, not URL encoding.

---

Expected Behavior

Using Get-PnPFile with a file URL that contains %20 (as part of the actual filename) should successfully retrieve the file without automatically decoding %20 into a space. For example:

Get-PnPFile -Url "Shared Documents/test%20file.txt" -Path . -FileName "output.txt"

This should download the file test%20file.txt from SharePoint.

Actual Behavior

Get-PnPFile interprets %20 as a space, so it searches for a file named test file.txt. This results in a “file not found” error when the actual filename contains %20 literally:

Get-PnPFile : File not found: Shared Documents/test file.txt

Steps to Reproduce

1. Upload a file named test%20file.txt to a SharePoint document library (e.g., “Shared Documents”).
2. On a Linux environment (e.g., Ubuntu 22.04), run:

Get-PnPFile -Url "Shared Documents/test%20file.txt" -Path . -FileName "output.txt"

3. Observe the error indicating the file cannot be found.

Version of PnP.PowerShell Module

Run:

Get-Module -Name "PnP.PowerShell" -ListAvailable

and paste the output here.

Operating System / Environment

• Linux (e.g., Ubuntu 22.04)
• Windows
• macOS
• Azure Cloud Shell
• Azure Functions
• Other: __________

Notes

It appears that the -Url parameter in Get-PnPFile is URL-decoded automatically, even when %20 is intended as a literal part of the filename. This behavior makes it impossible to retrieve files whose names contain literal %20 sequences unless they are renamed. If this behavior is intentional, please consider adding a flag or bypass option to prevent automatic decoding.