[jcifs] Re: SMB URL encoding/decoding
Christopher R. Hertel
crh at ubiqx.org
Sun Feb 24 17:01:09 EST 2002
Michael B Allen wrote:
> > MIME may decode the "+" at the MIME level, before it becomes visible
> > as a URL string... I'm just guessing. I don't have a lot to go on,
> > just that I looked through and found examples in the RFC where a space
> > was translated to %20 but no mention of "+" being used.
> Actually it's important that we do not use Java's URLDecoder then. Since
> we have to run all paths through a decoder routine any '+' would have
> to be escaped if we used java.net.URLDecoder. We should provide our
> own decode() that' *does not* decode '+'. If of course a user uses '+'
> they will get File not found or create files with '+' but that would be
> user error because a) they shouldn't be enoding path components b) it's
> not defined by the spec and c) they should use the jCIFS provided
> decode(). I wonder why Java didn't stop encoding the '+'. I guess if
> they decode it they have to encode it too and either way they start to
> ruin backwards compatability.
I'm going to weigh in with a big "I haven't a clue" on this one.
The problem with path components (and I think that this is a problem in
the RFC) is that the permitted character set is different than in other
parts of the URL. Eg:
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
userinfo = *( unreserved | escaped |
";" | ":" | "&" | "=" | "+" | "$" | "," )
So the problem is that you need to escape a ';' if you want to use it in a
path, but not if you use it in <userinfo>, and you have to escape an '@' if
you want to use it in <userinfo> but not in the path.
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
More information about the jcifs