KConfigGroup read/write bug for QByteArray

[Andreas Hartmetz]

On Sunday 16 September 2007 14:41:27 David Jarvie wrote:
> Using KConfigGroup::writeEntry() to write a QByteArray and then
> KConfigGroup::readEntry() to read it back in again can result in a value
> which is different from the original value, because the value written to
> the config file is converted to UTF8 when it is read back, so that all byte
> values >= 0x7F are changed to multi-byte values.
>
> If this is the desired behaviour (which I doubt), it's difficult to convert
> back from UTF8 since calling QString::fromUtf8 truncates the value as soon
> as it encounters a null byte. In data arrays, null bytes are common.
>
> The conversion occurs at the KConfigINIBackEnd level - reading from the
> config file using QFile seems to automatically convert the input to UTF8.
> Since at this level the config entry type is unknown, the solution looks
> like KConfigGroup::writeEntry() should write all QByteArray byte values >=
> 0x7F in hex representation. That way, the QFile read won't change them, and
> the correct value will be accessible to KConfigGroup for conversion.
>
> I'll produce a patch if my proposed solution is acceptable. Comments
> please.

Its going to be very inefficient for strings making use of UTF-8 and it's 
going to be very ugly, too. Most text editors can handle Unicode just fine so 
they could be used to easily edit the Unicode config files. No more with hex 
encoding.
Please look for ways to prevent Qt from messing up the data in the first 
place. I mean, it sure does have the possibility to write binary data. You 
might need to make your own readLine() if that is needed, or, if all else 
fails, use the C library which is at least as cross-platform as Qt.
I can probably help in finding a solution, but then I'd need a unit test that 
fails. You could take the existing unit test for KConfig[IniBackEnd] and just 
add some more test strings. That would have the added benefit of better 
testing for KConfig[IniBackEnd] in the future.