Hi João
On Fri, Dec 23, 2011 at 6:31 PM, <joao.abeca...@nokia.com> wrote:
> [ Re-trying after the previous massive quoting and line-wrap fail :-/ ]
>
> Denis Dzyubenko wrote:
>> 2011/12/9 João Abecasis <joao.abeca...@nokia.com>:
>> >> inline QUuid QUuid::createFromName(const QUuid &ns, const
>> >> QString &name)
>> >> {
>> >> return createFromName(ns, name.toUtf8());
>> >> }
>> >
>> > would only be updated to call the right implementations, as
>> > appropriate.
>>
>> I like the current status of the patch very much.
>>
>> However I have one question - where utf8 comes from? Shouldn't it be
>> defined by rfc, and if not imo we shouldn't arbitrary choose
>> encodings, and maybe leave the default one in - which is utf-16 for
>> QString
>
> This is my reasoning:
>
> 1) As you mention the RFC doesn't specify encodings. In fact, it says
> the owner of a namespace is free to decide how it should be used. For
> this reason it's important that we support QByteArray as the canonical
> form and let users make conscious decisions.
absolutely agree with that. I would even add an overload that takes
(char *, int len) to avoid mallocing a d-pointer for QByteArray.
> 2) In Qt, strings of text are represented as QString so it would be nice
> to support QString-based names. This is the reason for adding those
> overloads as convenience API, but doesn't tell us how QString-based
> names should be translated to "a canonical sequence of octets" (quoting
> the standard).
>
> 3) The point of name-based UUIDs is that you can regenerate the UUIDs
> knowing only the namespace UUID and a particular name. If you use the
> QByteArray version, it's up to you to ensure this. When using the QString
> version Qt needs to ensure it for you.
>
> This excludes locale- and system-dependent conversions, like
> toLocal8Bit(), it also excludes straightforward utf16() as it is
> dependent on endianness, and thus platform.
>
> 4) UTF-8 is a good candidate because it is one possible "canonical
> sequence of octets". But it's mostly that, a good candidate.
that is a very good reason indeed! I didn't think about endianness of utf-16.
Another alternative would be to always use utf-16 little endian (since
this is the most common system) in a canonical form (e.g. D-form to
make it cheap on mac).
> So, there isn't a reason why it *has* to be utf-8, but I haven't seen
> better alternatives. Other alternatives are toAscii or toLatin1, but
> they're lossy encodings. Network-byte order UTF-16?...
Denis.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
