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

[Lars Knoll]

> On Wednesday 10 July 2002 02:05 pm, Hetz Ben Hamo wrote:
> > I did - here it is again:
> >
> > http://chat.tapuz.co.il/newchat/main.asp?regUser=no&shower=1&room=30%20ôì
> >åñ %20àéëåúé&nick=fasdfasd This URL lets you go into a Java hebrew based
> > chat.
> >
> > With MSIE (and suprisingly Netscape 4.x) - the gybrish stuff is being
> > feed into the server as parameters which room.
> >
> > the fasdfasd stuff is my test to put a nick name. if I put a hebrew nick
> > the chat java client will get it as "????????" in konqueror. Actually if
> > you'll try this URL on konqueror with Java enabled, you'll get into the
> > chat to a room named "30 ????? ??????" - the ? should be of course hebrew
> > letters ;)
>
> The problem seems to be related to the fact that the javascript construct
> "location.href = ...." fails to pass on the encoding.
>
> E.g. there is:
> KURL KHTMLPart::completeURL( const QString &url )
> {
>   if ( !d->m_doc ) return url;
>
>   if (d->m_decoder)
>     return KURL(d->m_doc->completeURL(url),
> d->m_decoder->codec()->mibEnum());
>
>   return KURL( d->m_doc->completeURL( url ) );
> }
> which correctly informs KURL about the encoding but which is too late
> because m_doc->completeURL() has already ruined it.

Hmmm... why does KURL loose information at all? To me the fundamental flaw 
seems to be that KURL can do lossy conversions earlier than needed. 

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.

All strings in KURL should be stored in Unicode, and the conversion should 
only be done in the end to avoid exactly these problems. In that case you 
wouldn't loose anything when constructing a url, and could then set the 
encoding whenever you want. This might be difficult because of some inlined 
methods in KURL, but IMO that's how the class should behave.

Cheers,
Lars