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 Gruß, Bernd Gary Gregory wrote on 16. Apr 2025 17:02 (GMT +02:00): > Hi all, > > We probably need a general review of the API to see if we have an overall > consistency issue RE encoded vs decoded. > > I prefer us to be considerate before adding APIs here and there. > > We could at least document what is expected for methods that return a > String or consume a String. > > I wonder what the default expected behavior should be? Encoded URI Strings > are more usable. Decoded String seem to make sense for pretty printing and > display in UIs. > > WDYT? > > Gary > — https://bernd.eckenfels.net --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
