The file exists but Windows says "File Not Found": WebDAV URL encoding, CJK names, and the 404 that is not one

The share is reachable. The folder opens. The file is right there in the listing, with its name spelled correctly. Double-click it and Windows says "File Not Found."

That specific contradiction is almost never a missing file. It is the URL underneath the name.

Why a file that exists gets a 404

A WebDAV client turns a filename into a URL path before it sends anything. The server then decodes that path and looks up the file. Every step in that chain has its own opinion about what a legal filename is, and they rarely agree.

The classic case is a non-ASCII name. A client that percent-encodes UTF-8 correctly sends %E7%BD%91%E7%9B%98.txt, and the server decodes it and finds the file. A client that sends the raw bytes sends /网盘.txt, and the server applies its own charset guess, which may not be UTF-8 at all. Same file, two different paths, one of which does not exist. The server is not lying when it answers 404 - it is truthfully reporting that the path you asked for is not there.

The four checks that find it

1. Copy the name into a browser address bar on the same URL the client is using. If the browser shows a different file, or nothing, the encoding is the problem, not the storage.
2. Compare the response headers for a real file and for the missing one. A genuine missing file returns 404 with no Content-Type; a mis-encoded path often returns 404 with the server's normal error page, or 400, or even 200 with an empty body.
3. Watch for the redirect. Some servers redirect a path with a space or a non-ASCII character to an escaped path, and a client that does not follow the redirect reports the first response as the final one.
4. Check whether the name contains anything that has to be escaped at all: spaces, #, ?, %, or a path separator that the server treats as a directory boundary.

If the same share mounts and the same client opens ASCII-named files perfectly, you have narrowed it to encoding, and you can stop blaming the network.

The practical fix

Any client that is going to be used with real-world folder names has to percent-encode outgoing paths as UTF-8 and decode incoming headers as UTF-8, and it has to follow redirects while doing it. Getting that wrong is a client bug that no amount of server-side configuration will fix.

ScsDriver mounts a WebDAV share as a normal Windows drive letter and handles the encoding and redirect handling at the driver level, so CJK-named files open from Explorer the same way ASCII-named files do. It is $5.50 as a one-time purchase - the license is yours permanently, no annual renewal - and there is a 7-day full-feature trial if you want to test it against your own folders first.

Full disclosure: I work on ScsDriver, and everything above comes from supporting it in the field.