QLineEdit
-
Ok I check the Qt6 way.
QByteArray gives "\xC3\x83\xC2\xBC", the raw editor in DBeaver shows "C3 BC" two byte utf
-
-
QString::fromUtf8 gives me the correct umlaut at qDebug, the QLineEdit stays with ü
I move to Qt6, let's see...
@Erni42-0 Again: qDebug() does not say anything on windows - the windows console is just crap wrt.
Please output the exact QByteArray hex values, with QByteArray::toHex() and the qDebug().Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@Erni42-0 Again: qDebug() does not say anything on windows - the windows console is just crap wrt.
Please output the exact QByteArray hex values, with QByteArray::toHex() and the qDebug().I am going to make a couple observations, which might help guide the OP in a productive direction.
Many of us have learned the hard way to distinguish "unicode codepoint" from "UTF-8 character." I can certainly say that I learned it the hard way.
The unicode codepoint for ü is: FC
However, the utf8 encoding for ü is: 0xC3 0xBC
... but guess what?
The unicode codepoint for à is: C3 (notice this relates to "C3 BC" immediately above)
Similarly, in "CP 850", the byte xC3 also indicates Ã
If you believe you are using utf8 encoding to store ü, then the byte sequence of 0xC3 0xBC is great evidence that indeed you are encoding that ü correctly.
So the issue must be in how QString or QLineEdit is handling it. Either QString (on your platform) is not understood to store UTF8 byte sequences, or when deciding to choose written glyphs for the string of bytes, something in QLineEdit (or the underlying native UI control) seems to be using "CP850" or some other encoding to match bytes to glyphs.
www.219design.com
Software | Electrical | Mechanical | Product Design -
I am going to make a couple observations, which might help guide the OP in a productive direction.
Many of us have learned the hard way to distinguish "unicode codepoint" from "UTF-8 character." I can certainly say that I learned it the hard way.
The unicode codepoint for ü is: FC
However, the utf8 encoding for ü is: 0xC3 0xBC
... but guess what?
The unicode codepoint for à is: C3 (notice this relates to "C3 BC" immediately above)
Similarly, in "CP 850", the byte xC3 also indicates Ã
If you believe you are using utf8 encoding to store ü, then the byte sequence of 0xC3 0xBC is great evidence that indeed you are encoding that ü correctly.
So the issue must be in how QString or QLineEdit is handling it. Either QString (on your platform) is not understood to store UTF8 byte sequences, or when deciding to choose written glyphs for the string of bytes, something in QLineEdit (or the underlying native UI control) seems to be using "CP850" or some other encoding to match bytes to glyphs.
I should also note: I agree with @Christian-Ehrlicher 's suggestion to do:
QString::fromUtf8(abfrage->value("name").toByteArray())
-
I am going to make a couple observations, which might help guide the OP in a productive direction.
Many of us have learned the hard way to distinguish "unicode codepoint" from "UTF-8 character." I can certainly say that I learned it the hard way.
The unicode codepoint for ü is: FC
However, the utf8 encoding for ü is: 0xC3 0xBC
... but guess what?
The unicode codepoint for à is: C3 (notice this relates to "C3 BC" immediately above)
Similarly, in "CP 850", the byte xC3 also indicates Ã
If you believe you are using utf8 encoding to store ü, then the byte sequence of 0xC3 0xBC is great evidence that indeed you are encoding that ü correctly.
So the issue must be in how QString or QLineEdit is handling it. Either QString (on your platform) is not understood to store UTF8 byte sequences, or when deciding to choose written glyphs for the string of bytes, something in QLineEdit (or the underlying native UI control) seems to be using "CP850" or some other encoding to match bytes to glyphs.
@KH-219Design said in QLineEdit:
So the issue must be in how QString or QLineEdit is handling it
This is wrong - a QLineEdit can properly show a correctly encoded string. The QString is not correctly encoded due to some conversion problems while retrieving the data from the database.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@KH-219Design said in QLineEdit:
So the issue must be in how QString or QLineEdit is handling it
This is wrong - a QLineEdit can properly show a correctly encoded string. The QString is not correctly encoded due to some conversion problems while retrieving the data from the database.
@Christian-Ehrlicher I agree with you. Thank you for helping dissect this.
I was using "sloppy prose."
I definitely agree that QLineEdit can properly show a correctly encoded string.
In fact, I meant to demonstrate/emphasize that it is currently possible to argue that it is doing just that by showing the Ã
In other words, "correct encoding" is in the eye of the application designer or system designer. 0xC3 0xBC can be a correctly encoded ü. But by some other encoding, it can be argued to correctly encode "ü"
www.219design.com
Software | Electrical | Mechanical | Product Design -
@Christian-Ehrlicher I agree with you. Thank you for helping dissect this.
I was using "sloppy prose."
I definitely agree that QLineEdit can properly show a correctly encoded string.
In fact, I meant to demonstrate/emphasize that it is currently possible to argue that it is doing just that by showing the Ã
In other words, "correct encoding" is in the eye of the application designer or system designer. 0xC3 0xBC can be a correctly encoded ü. But by some other encoding, it can be argued to correctly encode "ü"
One more thing you can try is to use a prepared query - the code path is another than for a simple query in the Qt mysql plugin.
-
In the past I used to transfer texts, files, etc. that were usually only available for Windows to Linux. There were always problems with the coding. Linux already used utf8 but Windows used different ones like iso8859-14, iso8859-15 or ce1252.
The best way to determine whether it was utf8 was to take a Windows text file and edit the file in Linux. When the special characters "ü" appeared then you knew it wasn't utf8.
I would suggest running the SQL command in Windows in the console: "select name from event" then edit the result in Linux. If the special characters appear then the SQL file was not utf8 or Windows has converted the text into its own code. -
QSqlQuery *abfrage = new QSqlQuery(testen); abfrage->exec(QString("SELECT * FROM veranstaltung WHERE prefix = '%1'").arg(ui->listWidget->currentItem()->text()));creates the sql statement and executes them
ui->lineEdit_4->setText(abfrage->value("name").toString());fills the QLineEdit
As was said over and over again: It looks like you cannot just do
abfrage->value("name").toString(). This assumes that the value returned by the SQL query is in the proper encoding for a QString. As you mentioned the encoding of your DB is UTF-8. So, it is not the proper encoding for a QString. You have to explicitly create a QString from the data you queried from the DB and mention that the source encoding is UTF-8. Useui->lineEdit_4->setText(QString::fromUtf8(abfrage->value("name").toByteArray())); -
As was said over and over again: It looks like you cannot just do
abfrage->value("name").toString(). This assumes that the value returned by the SQL query is in the proper encoding for a QString. As you mentioned the encoding of your DB is UTF-8. So, it is not the proper encoding for a QString. You have to explicitly create a QString from the data you queried from the DB and mention that the source encoding is UTF-8. Useui->lineEdit_4->setText(QString::fromUtf8(abfrage->value("name").toByteArray()));@SimonSchroeder said in QLineEdit:
This assumes that the value returned by the SQL query is in the proper encoding for a QString. As you mentioned the encoding of your DB is UTF-8.
No, you're wrong. When the column type is a valid string-type (e.g. text, varchar, ...) then a QString is returned. The problem here is that it's either not a valid column type for a string or (which I assume) the internal conversion to a QString is wrong - but I will not touch Qt5 sources, it all works correct in Qt6.head.
