-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
8
-
x86_64
-
windows_10
ADDITIONAL SYSTEM INFORMATION :
>java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
A DESCRIPTION OF THE PROBLEM :
URL-encoding is performed on ZipFileSystem URI's when it should not be. URIs given to ZipFileSystem are already URL-encoded. When they are encoded for a second time the '%' character of the already-encoded character is re-encoded as '%25', breaking the URI. The result of this is that any call to ZipFileSystem.getPath(...) will be incorrect when there are special characters in the path to the zip file.
I can't pinpoint exactly where this double encoding is happening, but it looks like only the scheme-specific URI part is wrongly encoded twice. Perhaps there is a call to 'getSchemeSpecificPart()' somewhere where there should be a call to 'getRawSchemeSpecificPart()'.
See also: https://stackoverflow.com/questions/37936627/uri-to-file-in-zip-incorrect-if-path-contains-spaces
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Convert a URI that is part of a ZipFileSystem to a Path and then back to a URI:
Paths.get(new URI("jar:file:/C:/path%20with%20spaces/jarfile.jar!/example")).toUri();
OR
Request a path from a ZipFileSystem, then convert it to a URI.
FileSystem fs = ...;
fs.getPath("example").toUri();
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correct URI with value "jar:file:/C:/path%20with%20spaces/jarfile.jar!/example"
ACTUAL -
Incorrect URI with value "jar:file:/C:/path%2520with%2520spaces/jarfile.jar!/example"
Since this URI does not actually exist, any attempt to manipulate/read from it will lead to crashes.
---------- BEGIN SOURCE ----------
Paths.get(new URI("jar:file:/C:/path%20with%20spaces/jarfile.jar!/example")).toUri()
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The path's root's scheme-specific part of the URI can be manually replaced with a decoded copy when creating new URI's.
Path path = ...;
URI wrongUri = path.getRoot().toUri();
String uriText = path.toUri().toString();
uriText = uriText.replaceFirst(wrongUri.getRawSchemeSpecificPart(), wrongUri.getSchemeSpecificPart());
URI rightUri = new URI(uriText);
FREQUENCY : always
>java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
A DESCRIPTION OF THE PROBLEM :
URL-encoding is performed on ZipFileSystem URI's when it should not be. URIs given to ZipFileSystem are already URL-encoded. When they are encoded for a second time the '%' character of the already-encoded character is re-encoded as '%25', breaking the URI. The result of this is that any call to ZipFileSystem.getPath(...) will be incorrect when there are special characters in the path to the zip file.
I can't pinpoint exactly where this double encoding is happening, but it looks like only the scheme-specific URI part is wrongly encoded twice. Perhaps there is a call to 'getSchemeSpecificPart()' somewhere where there should be a call to 'getRawSchemeSpecificPart()'.
See also: https://stackoverflow.com/questions/37936627/uri-to-file-in-zip-incorrect-if-path-contains-spaces
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Convert a URI that is part of a ZipFileSystem to a Path and then back to a URI:
Paths.get(new URI("jar:file:/C:/path%20with%20spaces/jarfile.jar!/example")).toUri();
OR
Request a path from a ZipFileSystem, then convert it to a URI.
FileSystem fs = ...;
fs.getPath("example").toUri();
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correct URI with value "jar:file:/C:/path%20with%20spaces/jarfile.jar!/example"
ACTUAL -
Incorrect URI with value "jar:file:/C:/path%2520with%2520spaces/jarfile.jar!/example"
Since this URI does not actually exist, any attempt to manipulate/read from it will lead to crashes.
---------- BEGIN SOURCE ----------
Paths.get(new URI("jar:file:/C:/path%20with%20spaces/jarfile.jar!/example")).toUri()
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The path's root's scheme-specific part of the URI can be manually replaced with a decoded copy when creating new URI's.
Path path = ...;
URI wrongUri = path.getRoot().toUri();
String uriText = path.toUri().toString();
uriText = uriText.replaceFirst(wrongUri.getRawSchemeSpecificPart(), wrongUri.getSchemeSpecificPart());
URI rightUri = new URI(uriText);
FREQUENCY : always
- relates to
-
JDK-8131067 (zipfs) Zip File System Provider returns doubly-encoded Path URIs
-
- Closed
-