Linux за българи: Форуми

не съм вярвал, че ще опра до такъв проблем с Qt, но ...
каквато и да е кирилица, вкарана директно в сорса, излиза в апп-а на гущери и маймуни, в момента в който мине през транслатор - всичко е наред ...
Енкодинга на сорса е 1251, под FreeBSD бачка напълно коректно, опън сорс под М$ с mingw - не ..
Вече съм къс от към всякакви идеи, ако и от тук не дойдат някакви ... ще се дебъгва цялото qt под windows явно ...
Благодаря предварително.
Поздрави,

Ами, не ползвай cp1251. По принцип не го ползвай въобще, освен ако нямаш някой много специален случай, като речника на програма английско-български речник, където unicode-а е разхищение на памет. Иначе предтави си какво ще стане като, под win32 някой с чужда регионална настройка си пусне програмата ти и се учуди на "текста". Ако пък въпросния човек е запознат с кодовите таблици, ще трябва да си рестартира компютъра по два пъти всеки път когато се ползва програмата ти.
Unicode.

Ами мисля имаше нещо общо с езиковите/регионалните настройки (локал) - да не би случайно да НЕ ти е БГ :-) иначе другото спасение е Уникод както бе посочено вече...
Аз не съм имал такива проблеми, но пък от друга страна винаги съм си настройвал правилно "локал"-а

...и ДА - естествено че през транслатор ще става то оставаше и това да не работи!?

П.П. Предполагам под FreeBSD си с правилно настроен локал (БГ) а под win32 - не. А под win32 има и още една чавка (там нейде) за не-Уникод програми (ДОС) каква да е кодовата таблица ама... не вярвам да пишеш конзолно приложение  ;)

Locale е сетнато като хората навсякъде, проверено неколкократно преди да постна въпроса ...
с fromLocal8Bit нещата минаха, но това, от където стигнах до този проблем още не мога да го подкарам ...
Основния проблем - QComboBox се пълни от mysql база данни, кирилицата там си е наред - базата е utf8, всичко е вкарано коректно ...
Посмъртно не мога да го накарам обаче да я вкара в читав вид в комбо бокса. До тук тествани какви ли не игри с QTextCodec::setCodecForLocale и QTextCodec::setCodecForCStrings, единственото което се променя са вида на йероглифите ...
Включително вкарване на ръчно написана кирилица от там в базата - нито влиза читаво в базата, нито може да си я прочете обратно след това като хората ...
Почвам да се съмнявам в самия драйвер на mysql-а, почвам да копая натам по темата :<

Я покажи малко код, де.
Как инициализираш връзката с, как четеш от и пишеш в базата данни?
Как го инициализираш този QComboBox?
Аз под Win XP/Vista не съм имал проблем с кирилицата (основно ползвам PostgreSQL).

@goose: Като гледам коментираш два проблема едновременно. Те може би са свързани, но по този начин би объркал хората, които могат да ти дадат отговор.

Принципно в qt всичките стрингове се съхраняват в unicode. Така че ако имаш проблем с кодировките е много важно да се види как наливаш данните в QString. За кирилицата по интерфейса на програмата вземи и дай малко код да се ориентираме какво правиш. По отношение на достъпа до mysql е интересно каква ти е стандартната кодировка на клиента. Ако mysql сървъра стандартно set-ва нещо, което не поддържа кирилица, то ще е напълно нормално да не може да четеш или пишеш на кирилица в базата.

Почвам наред:
Отварянето на базата - стандартно до болка:

QSqlError err;
QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", QString("XXX"));
db.setHostName(dbhost);
db.setUserName(dbuser);
db.setPassword(dbpass);
db.setDatabaseName(dbname);
if (!db.open())
{
   err = db.lastError();
   db = QSqlDatabase();
   QSqlDatabase::removeDatabase(QString("XXX"));
}
db.exec("set names utf8");

Пълненето на комбото става в коструктора на наследен от QComboBox клас:
db=QSqlDatabase::database("XXX");
this->setInsertPolicy(QComboBox::InsertAlphabetically);
QSqlQuery query (db);
query.exec("select cdname from cards");
if (query.isActive())
{
   this->addItem("");
   while (query.next())
   {
   
      QString string = query.value(0).toString();
      this->addItem(string);
      this->addItem(string.toLocal8Bit());
      this->addItem(string.toUtf8());
   }
}
this->setAutoCompletion(true);

Както се забелязва, накрая тръгнах и с рогата напред, вкарвам стринга с 3 различни енкодинга ... Разликата е само във вида на маймуните в интерфейса.

Самата база: mysql> show create database gym;
+----------+--------------------------------------------------------------+
| Database | Create Database                                              |
+----------+--------------------------------------------------------------+
|XXX        | CREATE DATABASE `XXX` /*!40100 DEFAULT CHARACTER SET utf8 */ |
+----------+--------------------------------------------------------------+
1 row in set (0.09 sec)

резултата от show create table cards;
| cards | CREATE TABLE `cards` (
  `cdid` int(11) NOT NULL auto_increment,
  `cdname` varchar(45) character set utf8 collate utf8_unicode_ci NOT NULL,
  `cdcardtype` int(11) default NULL,
  PRIMARY KEY  (`cdid`),
  UNIQUE KEY `idx_cdname` (`cdname`),
  KEY `fk_cards_cardtypes` (`cdcardtype`),
  CONSTRAINT `fk_cards_cardtypes` FOREIGN KEY (`cdcardtype`) REFERENCES `cardtyp
es` (`ctid`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |

mysql> show variables like '%character%';
+--------------------------+---------------------------------------------------------+
| Variable_name            | Value
     |
+--------------------------+---------------------------------------------------------+
| character_set_client     | cp1251
     |
| character_set_connection | cp1251
     |
| character_set_database   | utf8
     |
| character_set_filesystem | binary
     |
| character_set_results    | cp1251
     |
| character_set_server     | latin1
     |
| character_set_system     | utf8
     |
| character_sets_dir       | C:\Program Files\MySQL\MySQL Server 5.0\share\charsets\ |
+--------------------------+---------------------------------------------------------+

и последно:
mysql> select * from cards;
+------+----------+------------+
| cdid | cdname   | cdcardtype |
+------+----------+------------+
|    3 | кирилица |          1 |
+------+----------+------------+
1 row in set (0.00 sec)

insert-а по последното е направен от конзола на бсд с utf-8 локал, както се забелязва mysql-а безгрижно си работи с него и го прехвърля в каквото му трябва. Пробвах и с пачнат драйвер:
qsql_mysql.cpp:
static QTextCodec* codec(MYSQL* mysql)
{
#if MYSQL_VERSION_ID >= 40113
    mysql_set_character_set(mysql, "utf8");
    return QTextCodec::codecForName("utf8");
#endif
...
Резултат от пача - нулев :>

дъмп=а на show variables like '%character%' от сорса дава utf8 навсякъде, с изключение на character_set_server, там си е latin1 ... Това и при пачнатия, и при чистия драйвер ...

QLocale дава Bulgaria, Bulgarian за локала както на main window-а, така и на комбото ...

На теория трябва да работи ... е явно съчетавам теорията с практиката, нищо не бачка и идея си нямам от какво :>
Благодаря предварително.

@goose: Можеш ли да кажеш, коя версия на qt ползваш и коя версия на mysql, за да хвърля поглед на mysql драйвера, защото са различни в отделните версии. Тъй като стандартно qt за windows не идва с компилиран драйвер, може да кажеш и как си го компилирал. На база на нещата, които си показал мога да направя следните коментари:

1. От редовете
this->addItem(string.toLocal8Bit());
this->addItem(string.toUtf8());
няма никакъв смисъл.

2. В драйвера за mysql QTextCodec, който се използва за обработка на стринговете, се инициализира при отваряне на базата. Така че редът
db.exec("set names utf8");
най-вероятно обърква положението, тъй като ако изобщо ти работи разпознаването на кодировката (възможно е да ти е изключена) то ще се зареди кодиране за cp1251, а след това сървъра ще връща utf8. Разбира се, при пачнатия драйвер нещата няма да седят така, което права мистерията още по-голяма.

Пробвай да настроиш сървъра стандартно да има character_set utf8 на резултати, връзка и клиент. А другото, което ми е интересно string.toUtf8() и string.toLatin1() какво ти връща, когато резултатът би трябвало да е 'кирилица'.

p.s. не обещавам, че ще ти отговоря веднага, тъй като тези дни ми е малко натоварено.

Значи най-вероятно БД е утф8 обаче това
character_set_server ..направи го и него утф8 (или поне 1251)
(ако текста е САМО на кирилица няма нужда и character_set_client/connection да са утф8 но е хубаво и те да са утф8) Предполагам "грешката ти е точно от character_set_server
Защото сървъра си чете от утф8 БД, после си конвертира в latin1 и после още един път при пращане на клиента към 1251 и познай къде се губи кирилицата
А и махни пача преди да пробваш тези неща
обик. set names оправя само *_*_connection-а, но пък тогава прекодирането става при *_*_client който също ти е 1251, а за това как точно да укажеш кодировката на клиента чрез QSqlDatabase db не съм сигурен точно за този драйвер как ставаше, но би трябвало да си работи утф8 по-подразбиране ако оправиш  всички останали настройки откъм страна на сървъра
Забележка: При прекодиране утф8->1251 нищо не се губи ако утф8 текста е само в 1251 целия (на 100% си става същия но в 1251 и тогава там изпълненията с транслаторите трябва да ти работят), но за да работят без подобни изпълнения сложи всичко на утф8

П.П. Извинявам се за първоначалното объркване с локала - не разбрах че става дума за четене от БД - в сл. той няма нищо общо...

qt 4.4.3, mysql 5.0.67
Default за сървъра навсякъде вече utf8
Компилацията: g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -
DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII -DQT_DLL -DQT_PLUGIN -DQT_SQL_LIB -
DQT_CORE_LIB -DQT_THREAD_SUPPORT

Това set names utf8 се появи по трасето със сляпото налучкване, ефекта от него е никакъв, току-що тествах и без него ...

Нещо ме навежда на мисълта за проблеми с утф-а в комбо бокса, резултата от .toUtf8 в него подозрително прилича на опит да дисплейне utf-а в нещо друго ... (ЄЁаЁ«Ёж копи-пейст от бокса)

ето ги и резултатите от конверсиите:

чистия стринг:ЄЁаЁ«Ёж 
toLocal8Bit: ª¨à¨«¨æ 
toLatin1: ????«?? 
utf-a го има по горе ..
 
Но си признавам, че вече гадая, логичните ми идеи май се изчерпаха.
Поздрави,

Между другото вече има по нови издания: GA 5.0.77 и GA 5.1.31 твоето е стара версия mysql 5.0.67 , ама като знам какво прекомпилиране ще падне.. между другото имат там някакви относно
"Queries of the form SELECT ... WHERE string = ANY(...) failed when the server used a single-byte character set and the client used a multi-byte character set."
(предимно япончетата се оплакали
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-77.html )
 - ама ти това го оправи и вече нямаш "server used a single-byte character set and the client used a multi-byte character set." по-скоро сега си мисля че при теб е обратния вариант сървъра е мулти а при теб клиента по-подразб. е 1251
и... най-добре да обновиш (ако имаш възможност до 5.0.77 поне)

Такааа сега вече варианта проблема да е в сървъра отпада (освен ако не си забравил да го от-пачнеш ;D ). Не ми се вярва и проблема да е в твоите локални опити за конверсия... остава значи само едно място - драйвера
Виж там (че съм ги позабравил)
QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", QString("XXX"));
db.setHostName(dbhost);
db. няма ли някакъв начин да му се задава подразбиращата се кодова таблица т.е. client_character_set Предполагам този който ползва драйвера (дали указан явно отнякъде или по-подразбиране != SHOW VARIABLES LIKE 'client_character_set' на сървъра

П.П. Тък ато гледам сега не ще да е в void QSqlDatabase::setConnectOptions ( const QString & options = QString() )
а по-скоро
enum QSqlDriver::DriverFeature
...
QSqlDriver::Unicode
или пък тук (за всички други има обяснено за уникод само на mysql няма)
http://doc.trolltech.com/4.4/sql-driver.html#qmysql-for-mysql-4-and-higher

Аз продължавам да дебъгвам ...
#if (MYSQL_VERSION_ID >= 40113 && MYSQL_VERSION_ID < 50000) || MYSQL_VERSION_ID >= 50007
    // force the communication to be utf8
    mysql_set_character_set(d->mysql, "utf8");
#endif
това е парче от open() на драйвера, при моята версия комуникацията винаги е юникод ...
Коректно се сетва, коректно се задавя и кодека ...

Проблема определено не е от сървъра, спретнах набързо едно пхп което го вади коректно ...
Интересното е, че току-що го тествах със sqlbrowser-а от демотата на Qt, ефекта е умопомрачително еднакъв ... Явно проблема е някъде в драйвера, сядам да копая по сериозно там ...

А бе пич, да не си случайно с някой дърт Уиндоус 95/98/Меее?  ;)
Това в рамките на шегата. Да не бии случайно проблема само да е във визуализирането - контрола стандартен ли е или си бърникал и по него.
Ако запишеш на файл едно поле само или през дебъгер вярно ли го показва - в смисъл опитвам се да разбера гешката само при показване ли е (историята познава и такива случай свързани най-вече кофти и/ли прецакани шрифтове)

Де да беше ...
В момента съм на виста хоум, специално за тестове изсипах едно чисто XP, тествано и на лаптопа с легално XP и без съмнения за проблеми със шрифтовете ...
По принцип мразя да търся помощ за решение на проблемите ми и преди да стигна до това положение правя каквото е възможно, за да стигна соло до решението, с компове се занимавам сериозно от 1989-та (това просто за инфо, да не се лъжеш по пресния ми акаунт тук) и май за сефте ми се налага да ескалирам въпрос извън приятелския ми кръг... Въртял съм го с какви ли не идеи преди да постна въпросите тук ..

Поздрави,

п.с. В момента вдигам от нула нова щайга и ще изкомпилясам всичко ръчно от мингв-то нагоре, ще видя на чиста моя компилация какво ще излезе ... До тук ползвах байнъри пакетите на тролтеч и само компилирах драйвера на mysql-а ...

В момента нямам много време но направих една бърза проба - при мен по подразбиране си работи - XP SP2 подразбираща се инсталация и Qt SQL Browser си чете/пише без проблеми ако сървъра е UTF8 -(пробвах и с 1251 пак се чете) само на един стар mysql 4.0.27 дето всичко му е 1251 има проблем.

mysql съм го компилирал като плъгин (не е статичен) и то май не за текущата версия точно на съвръра с който съм но и така пак ми ги изкара на кирилица
мисля че го компилирах за 5.1.30 (или 5.0.51 не съм сигурен), а сега го тествах набързо (без прекомпилация че няма време) със сървър 5.1.31
с утф8 си ги изкара нормални

mysql 4.0.27 на едната таблица с 1251 ги изкара нечетливи но сега нямам време да закача един транслатор да го оправя а (не бяха по 2 символа на знак а по един само не бяха транслирани правилно вероятно са latin1)

@goose: Явно не е тривиален проблема, пък нямам някакво разумно обяснение. Аз бих заложил, че mysql сървъра праща кофти неща. На твое място щях да наблюдавам какво става в
функцията и по специално следния ред
Тъй като да се дебъгва plugin май не е много приятно бих го модифицирал, така че да пъха нещата във файл. d->row[field] трябва да е указател към char така че един fprintf добре ще му се отрази, а val бих го записал като fprintf(file, val.toUtf8()). След това с един hex редактор ще ги сравнявам двете неща, така че да видя къде се чупи работата.