И снова про кодировки...

[Bepec]

QColor будет примерно как

QRGB(00,ff,ff)

Меняем кодировку и получаем
џ|nу(00,ff,ff)

Парсер QVariant охреневает

[Гурман]

Да черт с ними, с цветами...

В приложении Linux глухо не работает UTF-8 при загрузке настроек. В QString загружаются байты, без декодирования. В приложении Windows глухо работает как надо. Исходники идентичны. Разница в ОС, и в разрядности ОС - Windows 32 бит, Linux 64 бит. Сборка Qt и сборка самого приложения в Linux тоже 64 бит.

Но тестовый пример работает. Уже два бубна протёр в поисках что может влиять... Даже выносил setIniCodec() из конструктора на после создания объекта - не помогает.   Может в Qt 64 есть какая-то дыра?
...
Вроде кое-как добился загрузки в QString из UTF-8 в Linux. Но toLocal8Bit всё равно почему-то не работает без явной установки кодировки с помощью setCodecForLocale().

[Racheengel]

Наличие/отсутствие byte order mark (BOM) рассматривалось?

[Гурман]

Нет. А толку? Это же всё инкапсулировано в QSettings. Хотя я могу точно сказать, что bom там не записывается.

[Bepec]

приводите версию и ветку линуха, мб и поможем.

PS зачем вам toLocal8Bit? при использовании utf8 он нафиг не нужен )

[Гурман]

приводите версию и ветку линуха, мб и поможем.

PS зачем вам toLocal8Bit? при использовании utf8 он нафиг не нужен )

Linux Kubuntu 14.04. Я сам думаю, что с системой что-то не так. В Linux строки из QString, которые были загружены QSettings в UTF-8, читаются только после... установки кодировки локали Windows.

На самом деле, это не смертельно - локаль пользователю всё равно придётся выбирать, потому что она нужна для загрузки в QPlainText 8-и битных текстов данных, там в UTF-8 перейти пока нельзя. Значит я могу перед преобразованием менять локаль, затем возвращать System. Но такой поведение выглядит странно... Кроме как при загрузке в QPlainText и setCodecForTr(), "Windows-1251" нигде в приложении не используется.

Зачем toLocal8Bit я раньше писал - нужны const char* варианты строк для работы со старыми С-библиотеками. Вот тут в Linux и лезут косяки с кодировками. В Windows нет проблем.

[Гурман]

Локальная проблема была найдена - при сборке плагинов не выполнялись действия в QMAKE_POST_LINK из-за того, что там остались двойные кавычки в групповом имени файлов для удаления. То есть, в Linux сборке было

Код:

QMAKE_POST_LINK = $$QMAKE_DEL_FILE \"$$DESTDIR/$${TMPFILE}*\"

вместо

Код:

QMAKE_POST_LINK = $$QMAKE_DEL_FILE $$DESTDIR/$${TMPFILE}*

Соответственно старые файлы не удалялись, новые поэтому не создавались, и всё ехало... И причем ведь, qmake честно генерит команду

rm -f ....

В результате всё проскакивает молча, шито-крыто, а потом очень странно не работает.
Но глобально проблема не решена - пришлось делать вызовы для принудительной установки кодировки, в которой были сохранены настройки, и для возврата System после toLocal8Bit. Поэтому тэг РЕШЕНО в заголовок не добавляю.