Russian Qt Forum

наверно FAQ-овый вопрос, если обсуждалось, просьба ткнуть, поиском не нашел

для ввода строки в приложении используется QLineEdit, строка вводится, получена QString

потом надо преобразовать в С-строку, поскольку используется библиотека, написанная на С, для этого сделано так (S это полученная в редакторе QString):


в win все работает,

приложение портируется в lin, но в чистой системе пока некогда проверить, делалось в VMWare Player на XP, в KUbuntu 10.10

оказалось, что после преобразования toLocal8Bit() полученный массив содержит испорченный текст, как при открытии в lin UTF-8 текста, созданного в win

если же сделать так:


то массив ba и соответственно строка s получаются в эмуляторе читабельные

я так понимаю, 1251 кодировка вылазит из-за того, что это все происходит в эмуляторе, работающем в windows, если нет, то поправьте

очевидно, что привязывать к конкретной национальной кодировке нет смысла - во-1ых, в lin должно быть все нормально (завтра только смогу проверить), во-2ых программа может использоваться и с другими национальными кодировками

есть ли какое-то кошерное решение для случая запуска программы в эмуляторе, чтобы в подобных случаях строка декодировалась корректно, или надо просто учесть это в документации и предупредить, что в виртуальной машине под управлением ОС с отличающейся кодировкой неизбежна проблема при вводе строк на национальном алфавите?

VMWare тут ни при чём, на реальном железе будет работать так же. В Ubuntu 10.10,  как и в большинстве современных дистрибутивов, системной кодировкой является UTF-8. Поэтому надо преобразовывать не в национальную восьмибитную кодировку, а в UTF8 (в зависимости от твоей библиотеки, строка может представлять массив char-ов или wchar-ов).

для библиотеки нужны char, а не wchar

но если VMWare ни при чем - то откуда появляются символы в кодировке 1251, почему при конвертировании с этим кодеком текст правильный??

но софт должен работать и в win, без изменений - а там работает toLocal8Bit(), хотя можно конечно, условной трансляцией...

результат совпадает с вариантом


во всех этих случаях получаю одинаковую строку, являющуюся char-представлением Unicode строки

Не знаю, откуда берутся, но toLocal8Bit(), по-идее, в linux  с utf8 не должно работать, поскольку utf8 не является 8-битной кодировкой. Я в подробности этого дела не вдавался, но QTextCodec * QTextCodec::codecForLocale () не помогает?
Ещё могут быть нюансы с той библиотекой, может она не умеет корректно работать с utf8.

библиотека тут совершенно ни при чем, ее функции используются потом, надо для этого сформировать строку в текущем системном 8-и битном эквиваленте unicode-представления, поскольку работать она умеет только с 8-и битными символами

toLocal8Bit, согласно документации, возвращает строку в 8-и битной кодировке, в чистом Linux это, по идее, должна быть koi8-r - а в виртуальной машине похоже это 1251...

завтра проверю на Kubuntu 10.10 на обычной машине, правда там памяти очень мало, компиляция медленная из-за свопинга

2 Гурман
А у тебя в main есть подобные строки:
QTextCodec::setCodecFor...

а черт... и правда есть, другой программист main() писал больше года назад... спс, вопрос снят

:D

олол, покажите мне тот линупс, где кодировка не utf-8?
Даже винда вся из себя юникодовская внутрях, но все старательно используют убогие cp1251 и иже с ними

>>поскольку utf8 не является 8-битной кодировкой.
а сколькиж она битная, если не 8-ми?