trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2016

Re: Re: TQString::fromUtf8 vs TQString::fromLatin1

From: deloptes <deloptes@...>
Date: Wed, 23 Mar 2016 22:55:41 +0100
Fat-Zer wrote:

> 2016-03-23 10:47 GMT+03:00 Fat-Zer
> <fatzer2@...>:
>> 2016-03-23 10:34 GMT+03:00 deloptes
>> <deloptes@...>:
>>> Michele Calgaro wrote:
>>>
>>> Thank you for the explanations. This confirms my understanding of the
>>> matter, but does not explain why I get mangled characters at the end.
>>>
>>> The old Nokia phone (5530) seems to be Latin1 (ISO-8859-15). So I get on
>>> syncrequest std::string data. I do
>>>         TQString data = TQString::fromUtf8(item.data(), item.size());
>>>
>>> With my N9 or the filesync (TDE filesystem) it works fine, but with the
>>> 5530 I get the german �/�/� mangled.
>>>
>>
>> Sorry about that, my mistake... fromUtf8() is safe to use instead of
>> fromAscii() off coarse. for upper part of latin1 table it will give
>> different result... You are supposed to manually set encoding (and
>> likely let the user to choose it in this case), and use TQTextCodec to
>> decode strings
>>
>>> There seems to be something I do not understand correctly - or indeed I
>>> should use fromLocal8Bit(). I read about this time ago and compared the
>>> way KDE4 handles it. Now they are tricky using QByteArray and I was
>>> wondering if TQByteArray could do the work.
>>>
>>> I'll ask also the syncevo team, if one could pass the encoding to the
>>> config. This way we'll be able to handle it properly.
>>>
>>> regards
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>>
trinity-devel-unsubscribe@...
>>> For additional commands, e-mail:
>>>
trinity-devel-help@...
>>> Read list messages on the web archive:
>>> http://trinity-devel.pearsoncomputing.net/ Please remember not to
>>> top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
>>>
> 
> Forgot a 1-line snippet:
> 
> TQString data = TQTextCodec::codecForName("ISO-8859-15")->toUnicode
> (item.data(), item.size());
> 
> Haven't tested but should work...

Thank you, this was very good direction pointer!