Need to correct myself a bit: the change which prompted for my initial mail is not about escaping blanks in getPath(), getPath() (Depending on the provider) only escapes % (and ? and !). So the missing decode Variant of getRelativeName is limited to those.
The escaped blanks happen in getURL and getURI, but might also need some adjustments: The comment of RESERVED_URI_CHARS fails to explain why blank is to be escaped: https://github.com/apache/commons-vfs/blob/ccf9df52f505fc0c9f7daf29bab6ff0ce1e78286/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileName.java#L43 I think the comment is also explain wrongly why ? Is not escaped: it’s a perfectly fine unix filesystem character and not reserved, so it probably needs to be escaped (although I am not sure sure if query param ever can end up there and why it only cares about local file names?) Gruss Bernd Bernd Eckenfels wrote on 16. Apr 2025 18:47 (GMT +02:00): > > I think the encoding caused a lot of confusion with people (and also I > dont see how it is user friendly - besides if the calling Convention > required it), but I dont think we can change that now. So I agree with > Review and documenting. > > Maybe we need to provide at least a UriParser.decode() public method as > well? (If I want to fix the relative name I would need access to it) > > I was also thinking about not encoding blank, since those %20 are the only > issue i had in practice, but that would somehow manifest the limbo that > many use it wrong and not recognize it - but it is relative uncritical, > more Compact and better to read in most cases. Maybe global Option? > Specials since it was older behavior --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
