An application I'm working on involves accessing files on network file shares, and we're using URIs to specify the files' locations.
My understanding of the file: URI is that they should take the form of file://
+path. In the case of a Windows network share, this path looks something like \\servername\dir\file
, so the resultant URI becomes file:////servername/dir/file
.
This seems to be working great for Java's URI class, but the Win32 API seems to want a file://servername/dir/file
style URI, which Java rejects because it "has an authority component".
Am I understanding network-share URIs correctly? Is there another way to specify a path without Java complaining about the authority?
Edit: We were hoping to be able to store paths as URIs, so as to make use of the scheme-part of the URI to specify other locations (e.g. file: versus other:). But as pointed out, it looks like Java may just have its own issues with URIs...
It seems that Java is wrong:
Incorrect:
file:////applib/products/a%2Db/abc%5F9/4148.920a/media/start.swf
Correct:file://applib/products/a-b/abc_9/4148.920a/media/start.swf
The URI class handles UNC paths reasonably well, but has some problems. In the Java class libraries, the string representation of a UNC path is as follows:
new File("//SERVER/some/path").toURI().toString() -> "file:////SERVER/some/path
In other words, the URI stores the entire UNC path in the path component of the URI, and leaves the server/authority component empty. As long as you consistently use this string representation you will be able to interact successfully with java.net.URI.