I think arguments could be made both for and against unescaping URIs in create().
I vaguely recall a design choice (at least on my part) being made about Standards.URI not rewriting the URIs in any way unless provoked to do so, in order to facilitate comparison with other URIs.
(Looking at the implementation of java.net.URL I see the same behavior.)
Maybe addding a normalize method and overloading the comparison operator would be a better way to accomplish this.
/ Johan Schön (Firefruit)
Previous text:
2004-05-26 17:20: Subject: Quoting in Standards.URI
Seems like Standards.URI do neither encoding nor decoding according to rfc 2396:
True; it is kind of dumb that way; it just gives you the tools to take an URI apart and put it together again. We never got as far as setting an API for how to handle quoting, encoding and decoding issues for a higher level API; it was left out for possible future improvement.
I think it's pretty clear that it should handle this detail too.
Agreed. I do not think there would be any problem with compatibility, though, adding something now to do the trick, but then I also do not think encoding and decoding should happen automagically. Adding some additional primitives to the class should pose little problems, IMO.
Hmm, I just realized that it strictly speaking isn't possible to decode the path without splitting it at the same time. Is this true for the other uri parts too?
I'm not sure I followed that, but Standards.URI does all the splitting it can do based on its understanding of the URI format and all parts you get from it can then be decoded using tools elsewhere. The query part, for instance, can not contain an unquoted # character, nor can (assuming HTTP GET variable semantics) HTTP URL variable names contain an unquoted = character (which I believe might answer your question).
What are you trying to do? :-)
/ Johan Sundström (Achtung Liebe!)