how Windows browsers encode URL [Re: why the % cruft?]

[Waldo Bastian]

On Saturday 13 July 2002 03:48 am, Lars Knoll wrote:
> > On Friday 12 July 2002 03:37 am, Lars Knoll wrote:
> > > So putting a Unicode URL into KURL, then setting the encoding to
> > > latin1, and afterwards to eg. utf8 should not result in any operation
> > > that looses data.
> >
> > I fail to see why it is so hard to set the encoding right the first time.
> > You don't read HTML pages as "latin1" first and then later change the
> > QStrings to correct for the fact that the encoding should have been utf8,
> > do you?
> >
> > If you set the wrong encoding then KURL::url() will return the wrong
> > result. If you continue to work with those wrong results then things will
> > not automagically correct themselves after you throw them into a KURL
> > with another encoding set.
>
> I think you misunderstand me. Sure that KURL::url() returns a wrong result
> with a wrong encoding. My point is more that we actually should never need
> to call url() before actually sending it out over the wire in a request as
> it can be an operation where we loose information.

Tell that to khtml which converts back and forth between KURL and QString.

Take e.g. DOM::DocumentImpl: 
QString completeURL(const QString& url) 
{ return KURL(baseURL(),url,m_decoderMibEnum).url(); };

(I added the proper encoding yesterday, so now it works)

> When constructing one URL from another, we should probably use the decoded
> variants so no information is lost. KURL should provide all means to do
> that, so you can set arbitrary unicode strings and only when sending it out
> as part of a request will it get transformed into an encoding.

That's waht happens if you do:
KURL u;
u.setPath(path_str);

But if you do
url_str = textCodec->toUnicode(url_cstr);
KURL u(url_str);

it is important to preserve the original encoding of url_cstr and for that we 
need to know what it was.

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com