How can curl.exe upload files with Unicode or special characters in the path?

You can avoid quoting and argument-parsing surprises by building the arguments as an array and invoking curl with splatting. Also obtain the actual path from the filesystem instead of manually typing the filename:

`$file = Get-ChildItem 'D:OST*.zip' -ErrorAction Stop | Select-Object -First 1`
`$curlArgs = @('-F','sess_id=xxxxxx','-F','utype=prem','-F','to_folder=28890','-F',('file_0=@' + $file.FullName),'https://example.invalid/upload')`
`& curl.exe @curlArgs`

If this still produces error 26, the curl executable is probably the issue rather than PowerShell quoting; check that it supports Unicode and that the file exists at the exact path.

PowerShell can send multipart form data directly, so curl is not required. In PowerShell 7, `Invoke-RestMethod` supports a `-Form` hashtable and can receive the file with `Get-Item`:

`$params = @{`
` Uri = 'https://example.invalid/upload'`
` Method = 'Post'`
` Form = @{`
` sess_id = 'xxxxxx'`
` utype = 'prem'`
` to_folder = '28890'`
` file_0 = Get-Item 'D:OST[2026.05.27] TVアニメ「勇者のクズ」OP2テーマ「Revive」／ClariS [FLAC 96kHz／24bit].zip'`
` }`
`}`
`Invoke-RestMethod @params`

This lets PowerShell resolve the Unicode path itself and avoids passing the filename through curl's command-line parser.

First check the curl build with `curl.exe -V`. The important part is the `Features:` line: it should include `Unicode`. Unicode filename support was added in newer Windows builds, so an older curl.exe may not be able to open this path at all. Updating curl is likely the simplest fix. The two PowerShell encoding settings do not control how curl reads a filename: `OutputEncoding` affects piped input, while `Console.OutputEncoding` affects console output. A current Windows curl build should handle this filename normally.