QUrl in KDE 4
Andreas Aardal Hanssen
ahanssen at trolltech.com
Mon May 23 16:14:24 BST 2005
Some more stuff here..
On Thursday 19 May 2005 22:38, Thiago Macieira wrote:
> >> - convert a hostname back from ACE automatically (fromPunycode is
> >> never called)
> >That's a bug; I've made a task of it. Of course QUrl should call
> >fromPunycode :-).
> Good. Just make sure we can get both "forms" of the URL: the presentation
> form (ToUnicode) and the internal form (ToASCII). Currently
> KURL::prettyURL also converts %20 into spaces, and the printable high
> characters are decoded.
QUrl has a QString and a QByteArray representation. You will probably see from
the API that you can basically encode or decode whatever you like. The
default encoding is the minimal encoding necessary.
> By the way, the "proper" names for the IDNA transformation are ToUnicode
> and ToASCII. Punycode is a Unicode encoding, just like UTF-7, UTF-8,
> UTF-16 or UCS-4. Punycode would probably be better named if it were a
> QTextCodec (I'm not sure if it's been assigned a MIB number).
We would never call the punycode functions ToASCII and ToUnicode; we don't
require people to read the IDNA RFCs to understand the signature. Besides,
those names completely clash with the rest of the API.
> >>> Apparently, QUrl accepts file:/path URLs (no ///)
> >I don't understand this. Both file:/path and file:///path are allowed
> >according to the spec.
> Which one does it generate? The other-desktop developers will yell at us
> if we start generating file:/path URLs again.
Just have them use QUrl. The path() function always returns /path anyway.
> >The spec says nothing about what comes after mailto:. So you are free to
> >call toPunyCode() and fromPunyCode() when generating mailto urls.
> True. mailto: isn't a URL, so QUrl doesn't have to handle it.
But it does. :-)
Andreas Aardal Hanssen - andreas . hanssen @ trolltech.com
Trolltech AS - Waldemar Thranes gt. 98, NO-0175 Oslo, Norway
More information about the kde-core-devel