Comment 45 for bug 510018

(In reply to comment #18)
> Windows and MacOS X are fully Unicode. There's no such thing as broken paths on
> Windows, since it uses UTF-16; on MacOS X, which is UTF-8, Finder shows as
> "C%F3digo" (i.e., URL encoding, which we do support), but simple applications
> like TextEdit crash while trying to use the file.
>
> No, broken encodings are a thing of the past and should be confined to the
> terminal, where it belongs. Applications for the past 5 years have created
> files in UTF-8 encoding. Pen-drives use often VFAT, which is also Unicode
> clean.
>
> It's not like a recent convert will get those broken-encoded files.
>
> I think a 5-year transition period is more than enough. KDE 4 does not support
> non-UTF-8 locales anyways.

I just encountered another example that proves the above wrong. A music download service offers albums via zip-file. Opening that zip-file with ark shows broken filenames -> ark cannot decompress -> user without konsole experience is screwed.

This music is only one year old, so the zip was put togehter in the last months, if not on the fly when demanding the download, hence this is still reality and no matter whether the supplier of that file (a big electronics market) is at fault or not, users are screwed although the issue is known and Qt is ignoring that reality.

I tried unzip, which of course can extract the files, but dolphin cannot handle them afterwards.