[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Al-Khanji Louai]

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.


-- Louai


________________________________
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>>:
Hi Julien,

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
system).

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.

Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141009/becd8745/attachment.html>