[Development] Deprecating QFile::encodeName/decodeName
lars.knoll at nokia.com
lars.knoll at nokia.com
Mon May 14 14:26:53 CEST 2012
Full support from my side for it.
On 5/14/12 1:11 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
>I'd like to deprecate those two functions, as well as the setters
>QFile::setEncodingFunction and setDecodingFunction. I'd like to go
>make the setters no-op, and the actual functions be just an inline
>QString::to/fromLocal8Bit. However, I'll leave the encode/decodeName
>as part of the Qt 5 API.
>Those two functions have been present in Qt since at least Qt 2 (see 
>). Their purpose was to convert the UTF-16-based QString filenames to
>local filesystem encodings on Unix systems. Back in those days, some
>file names encoded with a different encoding than the locale -- for
>UTF-8 for the file names and Latin 1 or 15 for the data, or vice versa.
>For that reason, Qt developers should use QFile::encodeName when
>QString for use in the POSIX C function calls, and similarly use
>QFile::decodeName when converting data from the POSIX calls to QString.
>That concept is broken.
>The POSIX calls are not the only source of strings. There are more, like
>example the command-line and data found in files. When parsing the
>line, QCoreApplication applies QString::fromLocal8Bit indiscriminately,
>it doesn't know which arguments refer to files and which ones don't. If
>reading from a file, you're likely to do the same or to use QTextStream,
>amounts to the same problem.
>Moreover, if you're going to print a file name to a file, what do you
>communicating with other programs, what encoding should be used? How
>reporting information on the terminal (stdout and stderr)? Similar to
>QCoreApplication, when you set file names as part of the arguments in
>indiscriminately applies toLocal8Bit, since it doesn't know what is a
>and what isn't.
>Therefore, I call this concept broken. There's only one possible encoding
>the file system and it's the locale's encoding.
>I will make the change and submit for approval. I will not wait for the
>discussion on the mailing list because, quite frankly, I do not expect
>If you *do* disagree, please speak up and make sure you have very
>arguments on why we should keep this functionality and how developers
>address the problems I described above. If the community agrees to
>them, we can revert my patches.
>Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> Intel Sweden AB - Registration Number: 556189-6027
> Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
>Development mailing list
>Development at qt-project.org
More information about the Development