Bug of VirtualFileManager.constructUrl: constructs file://C:/ URIs without three /// on Windows
VirtualFileManager.constructUrl does not add three slashes for paths on Windows.
E.g. VirtualFileManager.constructUrl("file", "C:/Users/ComFreek/test.txt") will result in the URI "file://C:/Users/ComFreek/test.txt", which apparently is not a valid URI, see https://superuser.com/q/352133/137286.
Code of VirtualFileManager.constructUrl:
/**
* Constructs URL by specified protocol and path. URL is a string which uniquely identifies file in all
* file systems.
*
* @param protocol the protocol
* @param path the path
* @return URL
*/
@NotNull
public static String constructUrl(@NotNull String protocol, @NotNull String path) {
return protocol + URLUtil.SCHEME_SEPARATOR + path;
}
请先登录再写评论。
Is far as I get it, there is no any three slashes.
There is a protocol: file://
And a path (on unix systems starting with slash). /some/path
Together they give us three slashes.
Windows paths starting with letter, not slash. Therefore - only two.
Also, when you are stating a bug, would be nice to refer to some specification, not stackoverflow or smth.
You are right in requiring me to link to a better source. Apparently, the authoritative resource on file URIs is RFC 8089 as of February 2017.
Concerning the string
"file://C:/another-path/to/file",
I do not see how it is captured in the described syntax in section 2 of RFC 8089.
You could say it is of the form `file-scheme ":" "//" file-auth path-absolute` (a crude pseudo-parsed notation) with an empty `file-auth`, but then `C:/another-path/to/file` is *not* a `path-absolute`, which is specified in section 3.3 of RFC 3986. Namely, it begins with a slash. Indeed, this is consistent with the claim in appendix E.2 of RFC 8089, which basically says the same.
The following strings would be valid file URIs:
- "file:///C:/another-path/to/file"
- "file:/C:/another-path/to/file"