On 2016/03/23 02:51 PM, Fat-Zer wrote:
> 2016-03-23 5:31 GMT+03:00 Michele Calgaro <michele.calgaro@...>:
>> On 03/23/2016 09:39 AM, Fat-Zer wrote:
>> I disagree with Alex on point 2). I would still go for TQString::fromUtf8() if I am handling strings from the OS, just
>> in case ;-)
> Just a thought experiment:
> Imaging a spherical user in a vacume, on an island free of friction
> far far away. For simplicity let's say his system has some single
> imaginary locale (LC_ALL=xx_XX.NON_UTF).
> A user types in the terminal: "touch 'ટેસ્ટ' ". And it creates a file
> "ટેસ્ટ" with name encoded in NON_UTF. Exactly the same record will be
> on the filesystem since nor touch, nor the linux kernel, nor extX
> driver don't do any encoding conversions.
> Then he desires to open that file with a tqt program. Somewhere deep
> inside TQDir it gets a string from readdir() that contains exactly
> "ટેસ્ટ" encoded in the same NON_UTF encoding... What should be next?
> TQString::fromUtf8(), which makes so simple string "ટેસ્ટ" look like
> some gibberish and causing the angry user to loose his belief in
> humanity and become a serial killer? Or use TQString::fromLocal8Bit()
> so he could be happy and see the "ટેસ્ટ" in his TQOpenFileDialog.
> Luckily, now systems with non-utf8 locales are mostly extinct at least
> on linux and desktops...
Uhm, makes sense, good point.
Interestingly my disagreement with you came from the other way around: what if the filesystem is using a 16bit or 32bit
encoding? How would TQString::fromLocal8Bit() interpret that?
Anyhow it was just my 2 cents :-)