[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems
thiago.macieira at intel.com
Wed Mar 22 22:50:12 CET 2023
On Wednesday, 22 March 2023 09:48:05 HST Volker Hilsheimer via Development
> Even if one Qt 5 application and one Qt 6 application exchange data over a
> local socket, unwisely using to/fromLocal8Bit for the purpose - if the Qt 5
> application continues to run with the system code page, then the Qt 6
> application starting to sending UTF-8 encoded data will break this.
QLocalSocket is very rare on Windows. And any decent socket code that is
prepared to work over networks has either used proper 8-bit tagging to
indicate the encoding (since 2001) or plain UTF-8 (since 2003).
The console is already a mess on Windows because it's not just the ACP for
Win32 "A" API, but also the legacy DOS encoding (the mess that renders my
middle name JosÚ or JosΘ). Since that is already a mess, I don't particularly
find it problematic to see JosÃ© now... wouldn't be the first time. Most Windows
applications aren't console applications so this is a limited issue. It's also
time-limited: those issues should smooth out easily with proper terminal
applications, which is how we solved it in the Unix world too.
No, the far more likely scenario is interchange via files and via pipes to
child processes. So yes, finding out what the legacy ACP is might be a useful
piece of information. It shouldn't be the toLocal8Bit encoding, but it should
be available should the need arise.
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5152 bytes
Desc: not available
More information about the Development