Изпечатай

[goose]

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

[lastcyrol]

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

[remotex]

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

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

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

[goose]

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

[kolio_kolev]

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

[dvasilev]

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

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

[goose]

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

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-а, така и на комбото ...

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

[dvasilev]

@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. не обещавам, че ще ти отговоря веднага, тъй като тези дни ми е малко натоварено.

[remotex]

Значи най-вероятно БД е утф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

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

[goose]

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 го има по горе ..
 
Но си признавам, че вече гадая, логичните ми идеи май се изчерпаха.
Поздрави,

[remotex]

Между другото вече има по нови издания: 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 поне)

Такааа сега вече варианта проблема да е в сървъра отпада (освен ако не си забравил да го от-пачнеш ). Не ми се вярва и проблема да е в твоите локални опити за конверсия... остава значи само едно място - драйвера
Виж там (че съм ги позабравил)
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

[goose]

Аз продължавам да дебъгвам ...
#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, ефекта е умопомрачително еднакъв ... Явно проблема е някъде в драйвера, сядам да копая по сериозно там ...

[remotex]

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

[goose]

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

Поздрави,

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

[remotex]

В момента нямам много време но направих една бърза проба - при мен по подразбиране си работи - 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)