[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
louai.al-khanji at theqtcompany.com
Thu Oct 9 08:16:26 CEST 2014
It's not a platform bug. It's an application/framework (Qt) bug.
Unix paths are just a byte array, where certain bytes have special meaning (mostly just '/'). Passing around those byte arrays from/to platform functions will always work correctly.
The problem is that Qt tries to interpret those byte strings by converting them to unicode for use inside QString. There's no guarantee that this conversion will succeed using the current system encoding, as the file name may have previously been encoded with a different encoding.
On Unix, the "correct" way to handle paths is to never encode/decode the byte array.
Showing a path in a UI is a separate issue from just passing it around and/or modifying it.
From: development-bounces+louai.al-khanji=theqtcompany.com at qt-project.org <development-bounces+louai.al-khanji=theqtcompany.com at qt-project.org> on behalf of Konstantin Ritt <ritt.ks at gmail.com>
Sent: Thursday, October 9, 2014 3:44 AM
To: Marc Mutz
Cc: development at qt-project.org
Subject: Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
2014-10-09 3:57 GMT+04:00 Marc Mutz <marc.mutz at kdab.com<mailto:marc.mutz at kdab.com>>:
On Tuesday 07 October 2014 14:30:59 Julien Blanc wrote:
> However, i agree that changing this would :
> * break a lot of code
No, it cannot, if, as I propose, it's added to Qt 5.
> * permit only to solve really lower level / corner case issues
The value lies _also_ in being able to iterate over "weird" filenames (where
weird simply means plugging in a USB stick into an otherwise UTF-8-only
Qt doesn't mount that USB stick, Qt doesn't manage mounting [and whatever else system-wide] flags and settings; so should Qt ever care about some platform/misconfiguration issues?
IMO, issues like this one should (or even must) be fixed at a platform level, whilst high-level frameworks should not even try to workaround them. This is exactly what we were decided to do with the "space character(s) at the end of file name" issue on Windows, BTW.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development