Bug 212243 - FileLocator.toFileURL does not properly handle spaces (or other escape characters)
Summary: FileLocator.toFileURL does not properly handle spaces (or other escape charac...
Status: RESOLVED DUPLICATE of bug 145096
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.4   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: platform-runtime-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-07 02:42 EST by Michael Lossos CLA
Modified: 2008-08-11 10:06 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lossos CLA 2007-12-07 02:42:07 EST
Problem behavior: the URL returned from FileLocator.toFileURL() can contain spaces. This causes URL.toURI() to fail because spaces should be escaped as %20.

Suggested fix: at the very least, doc the toFileURL and getEntry methods to suggest where spaces and other special characters should be escaped. I'm not sure you could introduce correct escaping in toFileURL or getEntry without breaking existing code.


To reproduce:
BundleContext bundleContext = ...;
Bundle bundle = bundleContext.getBundle();
URL bundleUrl = bundle.getEntry( "/resource path with spaces" );
URL fileUrl = FileLocator.toFileURL( bundleUrl );
// fileUrl contains spaces
File resourceFile = new File( filUrl.toURI() );

// boom:

Caused by: java.net.URISyntaxException: Illegal character in path at index nn: file:/C:/xxxxxx/resource path with spaces
	at java.net.URI$Parser.fail(URI.java:2809)
	at java.net.URI$Parser.checkChars(URI.java:2982)
	at java.net.URI$Parser.parseHierarchical(URI.java:3066)
	at java.net.URI$Parser.parse(URI.java:3014)
	at java.net.URI.<init>(URI.java:578)
	at java.net.URL.toURI(URL.java:918)


Cheers,
Michael Lossos
Software Goodness Limited
Comment 1 Remy Suen CLA 2007-12-09 09:16:15 EST
Looks like a friend of bug 145096.
Comment 2 Oleg Besedin CLA 2008-08-11 10:06:30 EDT
Yes, seems like the same as the bug 145096.

*** This bug has been marked as a duplicate of bug 145096 ***