I was planning on using the com.sun.nio.zipfs.ZipFileSystemProvider in a project I���m working on, but I noticed a strange behaviour when working with URIs that contain escaped octets ��� in particular, creating a FileSystem with ���jar��� scheme for a local filepath that contains spaces always fails with the following exception:
 
java.lang.IllegalArgumentException: Illegal character in path at index 12: file:/C:/dir with spaces/file.zip
    at com.sun.nio.zipfs.ZipFileSystemProvider.uriToPath(ZipFileSystemProvider.java:87)
    at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:107)
    at java.nio.file.FileSystems.newFileSystem(FileSystems.java:322)
    at java.nio.file.FileSystems.newFileSystem(FileSystems.java:272)

 

I had a look at the uriToPath(URI uri) method and noticed the following snippet that seems to be causing the issue:

String spec = uri.getSchemeSpecificPart();
int sep = spec.indexOf("!/");
if (sep != -1)
  spec = spec.substring(0, sep);
return Paths.get(new URI(spec)).toAbsolutePath();

The string returned by getSchemeSpecificPart() is passed back to the new URI(String) constructor. However, getSchemeSpecificPart() returns a string with decoded octets, which means that if the original URI contained any (%20 for spaces for example), they would not be propagated to the modified URI that contains the path to the underlying JAR. Perhaps getSchemeSpecificPartRaw() would be more suitable as it doesn���t decode octets? I have attached a small test case that demonstrates this issue.

Test case:

import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.nio.file.FileSystems;
import java.util.HashMap;
import java.util.Map;

public class Test {
	public static void main(String[] args) throws IOException {
		File zip = new File("C:\\dir with spaces\\file.zip");
		URI uri = URI.create("jar:" + zip.toURI());
		Map<String, String> env = new HashMap<>();
		env.put("create", "true");
		FileSystems.newFileSystem(uri, env);
	}
}