QLineEdit

[Christian Ehrlicher]

@Erni42-0 said in QLineEdit:

QSqlQuery *abfrage = new QSqlQuery(testen);

Why on the heap? Happy memleak.

abfrage->exec(QString("SELECT * FROM veranstaltung WHERE prefix = '%1'").arg(ui->listWidget->currentItem()->text()));

Hello and welcome SQL-injection.

abfrage->value("name").toString()

What exact column type is name
Which encoding is used for the client? Please make sure it's utf-8. And maybe upgrade to Qt 6 - there were a lot of fixed regarding utf-8 and mysql in Qt6 and it works correct here with Qt6.5

[Erni42 0]

The server charset is utf8mb4, default collation is utf8mb4_general_ci, the column type is varchar(250).
SQL injection isn't possible. The list Widget is nnt editable. Or are there other ways to inject?
I need this Query just for a very short time, so I put them on the heap.

[Christian Ehrlicher]

@Erni42-0 said in QLineEdit:

I need this Query just for a very short time, so I put them on the heap.

Then put it on the stack.

So the encoding looks correct. But 5.12 is really old so I can't say much about it. I would try to convert it to a QByteArray instead QString, then examine the bytes to see what encoding it is (hopefully utf-8) and then convert it to a QString (when utf-8 then QString::fromUtf8()) but you have to do it by your own.

[Erni42 0]

Ok I check the Qt6 way.

QByteArray gives "\xC3\x83\xC2\xBC", the raw editor in DBeaver shows "C3 BC" two byte utf

[Christian Ehrlicher]

@Erni42-0 said in QLineEdit:

QByteArray gives "\xC3\x83\xC2\xBC", the raw editor in DBeaver shows "C3 BC" two byte utf

Directly from abfrage->value("name").toByteArray()?

Then you can try QString::fromUtf8(abfrage->value("name").toByteArray())

[Erni42 0]

QString::fromUtf8 gives me the correct umlaut at qDebug, the QLineEdit stays with ü

I move to Qt6, let's see...

[Christian Ehrlicher]

@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().

[KH-219Design]

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]

I should also note: I agree with @Christian-Ehrlicher 's suggestion to do:

QString::fromUtf8(abfrage->value("name").toByteArray())

[Christian Ehrlicher]

@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.

[KH-219Design]

@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 "ü"

[Christian Ehrlicher]

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.

[sowas]

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.

[SimonSchroeder]

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. Use

ui->lineEdit_4->setText(QString::fromUtf8(abfrage->value("name").toByteArray()));

[Christian Ehrlicher]

@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.