I ran into this behavior when I wanted to make use of URIEditor's feature that it can resolve classpath: URLs. If the classpath contains spaces or other characters that need to be escaped in URLs, then the resulting URI contains double escaped % signs.
My current workaround is to extend URIEditor and override createURI to always return new URI(value). when registered as custom editor for URIs, this PropertyEditor returns the proper URI.
Currently the URIEditor relies on the java.net.URI, specifically using the following constructor for URI prefixed with a schema:
URI(String scheme, String ssp, String fragment)
From the Java API:
This constructor first builds a URI in string form using the given components as follows:
1. Initially, the result string is empty.
2. If a scheme is given then it is appended to the result, followed by a colon character (':').
3. If a scheme-specific part is given then it is appended. *Any character that is not a legal URI character is quoted*.
4. Finally, if a fragment is given then a hash character ('#') is appended to the string, followed by the fragment. Any character that is not a legal URI character is quoted.
By using this constructor the URIEditor assumes that the provided URI might contain illegal URI characters, and always applies URI character encoding.
Alternatively, the editor could accommodate for already encoded URIs. This could be accomplished by initially searching for escaped characters in the source URI, and if present then simply call the static create(String str) method.
I've attached a patch to the URIEditor and URIEditorTests
Detecting whether a given URI is encoded or not is a tricky path. Basically, there is no way to know whether a % followed by two hexadecimals signifies an escape sequence, or is just a % with two characters behind it.