kaputte Umlaute beim Einsatz von COMPRESS()

[Dave_Bowman]

Hallo,

ich möchte in einer Tabelle XML-Dokumente speichern, allerdings komprimiert mit der MySQL-Funktion COMPRESS(). Dabei fällt mir auf, dass der Server bei den dekomprimierten (UNCOMPRESS()) Werten die Umlaute falsch darstellt. Was kann ich tun? Es wird als Spaltenformat VARBINARY oder BLOB empfohlen, ich habe beide probiert, es ändert sich jedoch nichts. Auch diverse Kollationen bei einer VarChar-Spalte bin ich durch. Ohne COMPRESS() speichert er die Angaben anstandslos, aber irgendwie scheint hier das COMPRESS() zu stören bzw. nicht korrekt mit Umlauten umgehen zu können.

Was kann ich tun? Bin für jeden Tip dankbar ...

Dave

[dibo33]

Kann ich nicht bestätigen, dein "Fehler" muss woanders liegen.

[Falk Prüfer]

Hallo,
bei COMPRESS auf BINARY-Ebene dürften Umlaute überhaupt keine Rolle spielen. Die Daten werden 1:1 wieder hergestellt. Umlaute kommen hier erst bei den Charsets der Clientverbindung und deiner Applikation ins Spiel. Hier wäre also interessant, WIE die Daten gespeichert und ausgelesen werden und welche Charsets die MySQL-Client-Verbindung und deine Applikation verwenden.

Gruß Falk

[Dave_Bowman]

Hallo Falk,

ich weiß nicht genau, was Du meinst, WIE die Daten gespeichert und ausgelesen werden. Es ist eine .NET-Applikation über einen Konnector (weiß gerade nicht, ob ODBC oder .NET, da wir für Datenbankaufrufe ein separates Framework benutzen). Ich weiß nur, dass, wenn ich normalen Text mit Umlauten in der DB speichere, dieser korrekt ankommt. Behandle ich ihn stattdessen mit COMPRESS, erhalte ich bei UNCOMPRESS kaputte Umlaute zurück. Nach meinem Verständnis wäre doch dann der Übertragungsweg egal, da ja das COMPRESS erst auf DB-Server-Seite zum Tragen kommt, und dort kommen ja auch augenscheinlich die Umlaute korrekt an, zumindest in normalen VARCHAR-Feldern. Allerdings hat auch dibo recht, speichere ich komprimierten Text direkt auf dem Server mit der Workbench, wird der auch korrekt wieder entpackt.
Ich verstehe nicht, wo der Fehler liegen soll.

[Falk Prüfer]

Hallo Dave,

...Ich verstehe nicht, wo der Fehler liegen soll.

ich vermute den Fehler in deiner Zugriffsschicht. Im Endeffekt sind bei einer Datenbankoperation drei "Partner" beteiligt, die ggfs. jeder einer andere "Sprache" (Charset) sprechen können. Da ist zum einen deine Anwendung, zum Zweiten die MySQL-Clientverbindung und als Dritter die eigentliche DB-Tabelle. Bei unterschiedlichen Charsets von Zweitem und Drittem führt MySQL automatisch eine Zeichensatzkonvertierung durch. Um Erstens musst du dich als Programmierer selbst kümmern.
Von Interesse wäre jetzt also, welches Charset die DB, die betroffene Tabelle, die MySQL-Clientverbindung und deine Anwendung verwenden. Gibt es da Unterschiede, dann müsstest du dir ansehen, wie an den "Schnittstellen" mit diesem Unterschied umgegangen wird.

Frage: Wenn du mit deiner Anwendung Umlaute normal in der DB speicherst und diese mit einem anderen Programm (z.B. Workbench) ausliest, sind die Umlaute dann korrekt?

Gruß Falk

[Dave_Bowman]

Frage: Wenn du mit deiner Anwendung Umlaute normal in der DB speicherst und diese mit einem anderen Programm (z.B. Workbench) ausliest, sind die Umlaute dann korrekt?

Ja, das sind sie. Wir haben beim Speichern nie Probleme dieser Art gehabt, nur eben jetzt, und nur während der Benutzung des COMPRESS().
Die Tabellen bzw. die betreffenden Spalten haben latin1_german1_ci, außer natürlich der Spalte, die die komprimierten Inhalte aufnehmen soll, dort habe ich als Datentyp BLOB eingestellt, aber auch andere Datentypen und mit VARCHAR() diverse Kollationen versucht.

Ich habe mich um Zeichensätze noch nie kümmern müssen, alles wurde und wird korrekt gespeichert. Es ist nur das erste Mal, dass ich COMPRESS benutzen will, und das funktioniert plötzlich nicht wie erwartet. Ich nahm an, dass der zu komprimierende Text wie anderer Text auch per SQL zum Server gelangt und erst dort, nachdem quasi die Übertragung beendet wurde, vom Server komprimiert und abgelegt wird. Der Client verarbeitet oder komprimiert da ja noch nichts, nehme ich an. Dagegen spricht aber eben, dass anderer Text korrekt gespeichert wird und auch, dass das COMPRESS mit UNCOMPRESS, manuell in der Workbench ausgeführt, auch korrekt klappt.

...

Hah, ich habe jetzt mal in meiner Anwendung einen komprimierten Wert ausgelesen (CONVERT(UNCOMPRESS(fieldname), CHAR)), und dieser ist wieder korrekt! "Nur" in der Workbench dagegen nicht.

...

Jetzt habe ich es, glaube ich. Es sind tatsächlich unterschiedliche Zeichensätze, die hier, vermutlich erst beim Komprimieren, zugrunde gelegt werden. Auf jeden Fall habe ich in der Anwendung bei den dekomprimierten Daten korrekte Umlaute, und in der Workbench auch, wenn ich dort explizit konvertiere: CONVERT(UNCOMPRESS(fieldname), CHAR CHARACTER SET latin1). Ist wohl standardmäßig utf8. Aber dann stimmt jetzt dort auch alles. Und dann passt das doch.

Vielen Dank für Deine Hilfestellung, Falk ...