QUrl vs KURL - here's some benchmark results for you
thiago at kde.org
Thu Jun 2 23:27:00 BST 2005
David Faure wrote:
>I never had any doubts about that. My concern is more for correctness -
> not in terms of the RFC, but in terms of the web. KURL has special code
> for preserving encoding used by websites (Waldo? Can you give more
> details on this?). It also handles absolute-or-relative URLs (the two
> arguments constructor), but that's possibly something we can add on top
> (making KURL derive from QUrl). QUrl might also refuse to parse some
> urls that KURL parses (or vice versa), which would also lead to
> problems on websites [KDE code is easy to fix, websites we can't fix
>Any other kind of missing API we can add there; but the encoding thing
> or parsing differences could be a problem.
The encoding part is somewhat a problem and has to be revised. KURL/QUrl
shouldn't have to know about any encoding except UTF-8. That is because a
URL must be, as the name says, Universal. It should not depend on the
user's locale, or the encoding of its source.
It is actually Konqueror's/khtml's job to properly decode a page into
Unicode, so that the URL can be created.
In other words, the webpage may encode an "é" in the URL with 0xE9 (Latin
1) or é, but it be equivalent to an URL with %C3%A9.
Of course, this doesn't come without problems: local files. A local .html
page could make a reference to <a href="Résumé.pdf">. IRI would mandate
that the file referenced be BASE/R%C3%A9sum%C3%A9.pdf, but if the user
doesn't use UTF-8 for his local filename encodings, this won't work.
Thiago Macieira - thiago (AT) macieira (DOT) info
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel