[Development] Should we change the default codec of QTextStream to UTF-8?

lars.knoll at nokia.com lars.knoll at nokia.com
Fri May 25 11:26:17 CEST 2012


On 5/25/12 9:37 AM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On sexta-feira, 25 de maio de 2012 06.27.05, lars.knoll at nokia.com wrote:
>> On 5/24/12 11:38 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
>> 
>> wrote:
>> >On quinta-feira, 24 de maio de 2012 13.15.16, 1+1=2 wrote:
>> >> If we want to bootstrap tool such as qmake support utf8
>> >
>> >Why would we want to?
>> 
>> One reason could be paths/filenames that are encoded in the .pro file.
>>If
>> we interpret it as latin1, we can't support international filenames.
>
>If we are reading the .pro file as Latin 1 and we encode the filenames as
>Latin 
>1 when calling the POSIX functions, it will work just fine. So I don't
>see a 
>problem on Linux.

You're right, since toLocal8Bit() is equivalent to toLatin1() in bootstrap
mode.

>As for Windows, writing an 8-bit path is a mess anyway. Is the .pro file
>supposed to be encoded in UTF-8 or in the Windows legacy ANSI encoding?

Yeah, this is somewhat messy, as the Win32 APIs take wchar's (ie. utf16).

>> And we are now assuming utf8 for all our C++ and QML source code. One
>> could argue that assuming the same encoding for .pro files would be only
>> consistent.
>
>I agree: we'd assume that the encoding of the .pro file is UTF-8.
>
>However, at this point I'd simply recommend ignoring the problem. Let's
>not 
>try and modify qmake any than we really must for getting 5.0 out.

Ok, agree with that. It's certainly not worse in 5.0 than it has been for
years :)

Cheers,
Lars




More information about the Development mailing list