Dass die unterschiedlichen Zeichensätze immer wieder gerne Probleme bereiten, ist ja bekannt.
Neu ist für mich, dass innerhalb von Lazarus derartige Probleme auftreten können, und ich habe keine Idee, wo ich den Fehler suchen könnte.
procedure debug(const txt: string);
const
SB_BOTTOM=7;
First: Boolean = True;
InDebug: boolean=False;
var
f: text;
begin
if not DebugOn then exit;
frmMain.LogBox.Items.add(txt);
....
debug('GetMemberlist Query für Set '+Setname+', SetNr: '+inttostr(SetNr));
Tja und mit welchem Zeichensatz ist das in der Datenbank gespeichert (Setname). Meistens das Problem das in der DB irgend ein WIN Zeichensatz verwendet wird und in Lazarus UTF8. Jetzt hängt es von den Verbindungsschicht (SQLDB oder ZEOS) ab, ob man das in der Verbindung konvertiert, oder gleich am Server richtig macht, oder im Programm konvertieren muß.
Bei Lazarus würde ich in der DB bei der Erstellung der Tabellen immer UTF8 angeben.
Prior to MariaDB 11.6.0, the default character set is latin1 and the default collation is latin1_swedish_ci. From MariaDB 11.6, the default character set is utf8mb4 and the default collation is utf8mb4_uca1400_ai_ci. This may differ in some distros, see for example Differences in MariaDB in Debian.
So kann es passieren, das du im Programm mit UTF8 arbeitest, vom Server aber Latin1 schwedische Ausprägung kommt
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
, die an Debug als Parameter übergeben und beim Erstellen des Source Codes in Lazarus richtig angezeigt wird.
Der String Setname ist auch nicht in der Datenbank gespeichert, sondern kommt genauso von Konstanten im Pascal Source Code.
Zuletzt geändert von braunbär am Di 4. Feb 2025, 15:21, insgesamt 2-mal geändert.
Keine Ahnung, hast du was verstellt?
Check mal: Rechtsklick auf dem Editor -> Dateieinstellungen -> Zeichenkodierung. Da sollte UTF-8 stehen
Oder bei der Listbox das Font.Charset. Auf Linux spielt das zwar keine Rolle, aber vilt. auf Win, das weiss ich nicht.
Ich bin mir zumindest nicht bewußt, irgendwas an den Einstellungen in dem Bereich verändert zu haben. Die Zeichenkodierung der Datei ist UTF-8, Der Zeichensatz des Listbox-Fonts ist DEFAULT_CHARSET.
PS.: In einem TLabel, dessen Caption ebenfalls von einer Stringkonstante zur Laufzeit generiert wird, kommen die Umlaute richtig an.
Hmm. also wenn du ein neues Projekt machst nur mit einer Listbox und das Gleiche da reinschreibst und und das Problem wieder auftritt, dann würde ich einen Bug-Report machen.
Vorausgesetzt du hast eine aktuelle Version.
Auf Linux tritt das Problem vermutlich nicht auf?
theo hat geschrieben: Di 4. Feb 2025, 15:02
Keine Ahnung, hast du was verstellt?
Check mal: Rechtsklick auf dem Editor -> Dateieinstellungen -> Zeichenkodierung. Da sollte UTF-8 stehen
Oder bei der Listbox das Font.Charset. Auf Linux spielt das zwar keine Rolle, aber vilt. auf Win, das weiss ich nicht.
Du hast Recht.
Jetzt habe ich noch einmal geschaut: Alle anderen Units haben die Zeichenkodierung UTF-8, aber die eine Unit, in der der Debug Aufruf steht, hatte die Kodierung CP1252. Ich verstehe nicht wie, weil ich habe an der Zeichenkodierung sicher nichts gefummelt, ich wusste gar nicht, dass es das Kontextmenü gibt.
Danke, es hätte mich viel Zeit gekostet, da selbst draufzukommen.
PS: Meine folgende Antwort hat sich zeitlich überschnitten mit der vorherigen Antwort, wo CP1252 gefunden wurde.
Hi!
Kommt denn Setname aus einer Datenbank und hat womöglich eine andere Codepage als UTF-8?
Ich glaube, FreePascal stolpert beim Verbinden zweier Strings mit unterschiedlicher CodePage, also bei: 'GetMemberlist Query für Set '+Setname.
Jorg3000 hat geschrieben: Di 4. Feb 2025, 16:25
Kommt denn Setname aus einer Datenbank und hat womöglich eine andere Codepage als UTF-8?
Ich glaube, FreePascal stolpert beim Verbinden zweier Strings mit unterschiedlicher CodePage, also bei: 'GetMemberlist Query für Set '+Setname.
Unabhängig davon, dass der Fehler ein anderer war, aus Interesse - Speichert denn das Laufzeitsystem überhaupt die Codepage eines Strings? Ich dachte, ein String ist nur eine Folge von Bytes, die entsprechend der im Kontext aktuellen Codepage interpretiert werden.
braunbär hat geschrieben: Di 4. Feb 2025, 21:39
Unabhängig davon, dass der Fehler ein anderer war, aus Interesse - Speichert denn das Laufzeitsystem überhaupt die Codepage eines Strings? Ich dachte, ein String ist nur eine Folge von Bytes, die entsprechend der im Kontext aktuellen Codepage interpretiert werden.
Nein, mittlerweile werden bei Strings eben die Codierung und auch Referenzzähler mitgeführt. Ausserdem sind es bei UTF-x Bytefolgen die es zu interprtieren gibt. UTF-8, UTF-16, UCS-2,... verhalten sich da unterschiedlich. UTF-8 kann Bytefolgen bis zu 4 haben. Strings sind ziemlich schwer verständliche Dinger mit sehr viel eigenleben, wenn man es nicht kapiert hat (ich hab es noch immer nicht ganz drauf)
Verein
Links
Suche