crondump.pl und utf-8?

**knows MySQLDumper** Joined: 28 Aug 2006 Posts: 6

Hi!

Ich habe den Perl-Cronjob eingerichtet und dieser funktioniert auch wunderbar. Aber bei der Kontrolle der Dumps habe ich nun festgestellt, dass diese bei mir in latin1 abgespeichert werden.

Kann mir jemand sagen was ich konfigurieren muss, damit die Crondumps in utf-8 gespeichert werden (genauso wie die PHP-Dumps)?

Grüße
Willi

Posted: 2008-01-14, 21:41 (No subject)

Jup, nimm die neueste Version 1.23. Wink

**knows MySQLDumper** Joined: 28 Aug 2006 Posts: 6

Ja, mit der crondump.pl aus Deinem aktuellen Posting hat es funktioniert. clap

Ich hatte nur zuerst das Perl-Skript aus dem REV 257-Package genommen. Da steht auch als Versionsangabe die 1.23 drin...

**MSD-Professional** Joined: 30 May 2004 Posts: 61

Hallo,
habe leider das gleiche Problem, wobei ich die aktuellen Dateien nutze. Habe heute erst das Update gemacht. Perl klappt auch alles super, aber eben als Latin1. Noch ein Tipp?
Gruß

**uses MSD regulary** Joined: 31 Mar 2007 Posts: 11

Hallo DSB,

mit der Vers. 1.23 habe ich ja heute ein Problem lösen können.
Nun habe ich aber das gleiche Problem wie ts201

Posted: 2008-02-23, 23:36 (No subject)

Nee, ihr versteht das alle falsch. Wink

Das ist kein Problem. Wieso sprecht ihr von einem Problem?

PHP setzt die Verbindugn selbst auf utf8, deshalb wird anschließend als Kodierung der Verbindung des Servers auch utf8 erkannt.
Eigentlich macht es das Pelrscript richtig und ermittelt die Standardkodierung des Servers vor dem Festlegen der Kodierung der Verbindung richtig.
Es ist aber gehupft wie gesprungen - beides ist richtig.
Also lasst den Dumper einfach machen. Egal, ob das Backup nun in latin1 oder in utf8 gespeichert wird - beides lässt sich einwandfrei wieder einspielen.

**uses MSD regulary** Joined: 31 Mar 2007 Posts: 11

**knows MySQLDumper** Joined: 13 Mar 2008 Posts: 2

@DSB: Interessant - ich stehe vor dem gleichen "Problem" (Ok ich weiß nun, dass es kein's ist.) wie die anderen hier. Via php auf utf-8, Perl latin1.

Kannst Du kurz und ohne großen Aufwand erklären warum dasso ist bzw. v.a. warum es egal ist?

Posted: 2008-03-13, 08:28 (No subject)

Steht doch in meinem Posting. Smile

**knows MySQLDumper** Joined: 13 Mar 2008 Posts: 2

Das würde aber heissen, dass es (das Cronscript) die Standardkodierung des Servers als "latin1" ermittelt, richtig?

Woher nimmt es die Info? Im Environment des ausführenden Users ist de.DE.UTF-8 als Locale aktiv, der MySQL Server läuft ebenfalls auf UTF8 - bezieht sich dieser Standard dann evtl. auf ein Perl setting?

Posted: 2008-03-13, 10:38 (No subject)

Schau mal unter home/MySQL-Variablen/Variablen

Die Kodierung character_set_connection kann durch vom jeweiligen Script vorgegeben werden.
Die Standardkodierung des MySQL-Servers steckt in character_set_server.

**knows MySQLDumper** Joined: 02 Nov 2004 Posts: 7

Ich finde es ebenfalls etwas verwirrend. In der neuen Version wird bei Perl in latin1 und bei php in utf8 abgespeichert.

In der alten Version gehen beide (PHP/Perl) korrekt mit utf8.

Spielt man die latin1 Version als Backup ein, gibt es anschliessend keine Verbindung mehr zur Datenbank wegen <#1273 - Unknown collation:>. Solange, bis man herausgefunden hat, das die Leerung des Browsercache den Fehler auflöst. Nichts für schreckhafte Naturen.

Doch lieber die alte Version verwenden.

Gruss
ATLAS

**MSD-Professional** Joined: 19 Oct 2004 Posts: 59

Frage:
Muss das Backup dann auch mit der aktuellen REV257 erstellt worden sein, oder ist das egal?
Unser Backup wurde mit 227 erstellt.
Wenn ich die Datei öffne steht auch Latin1 drin.
Das Zurückspielen mit REV257 macht bei den Umlauten dann aber Probleme.
Kann ich den crondump.pl nicht direkt auf UTF-8 stellen?

Posted: 2008-05-25, 13:46 (No subject)

Hallo onkel b,

die Kodierung wird seit Version 1.22 richtig gesetzt. Ab 1.22 aufwärts ist es also egal mit welcher Version das Backup erstellt wurde.

Wenn nach dem Rückspielen Umlautprobleme auftauchen, dann war entweder beim Sichern oder beim Wiederherstellen der Daten die berüchtigte MySql-Version 4.0.x, die den Befehel "SET NAMES" nicht richtig ausführt und trotz des Befehls die Standardkodierung des MySQL-Servers benutzt, im Einsatz. Hier könnte eventuel mein Tool DUK im Nachhinein die Daten korrigieren.

Die andere Möglichkeit die Kodierung des Perlskripts richtig einzustellen findest Du im Perlskript selbst. Dort steht eine Variable am Anfangsbereich, die die Kodierung enthält und die Du leicht anpassen kannst. Schau mal rein in das Skript. Wink

Diese Anpassungen sind aber nur nötig wenn ein MySQL-Server Version 4.0.x im Spiel ist! Deshalb rate ich jedem dringend zu einem Update der MySQL-Version! Lasst uns Version 4.0.x aus dem Netz verbannen - es gibt in Bezug auf Zeichensätze immer wieder Ärger damit.

**MSD-Professional** Joined: 19 Oct 2004 Posts: 59

Hallo,

also wir hatten die MySQL (auf dein Anraten) mal updaten lassen weil es Probleme gab Backups zu erstellen.
Jetzt haben wir Version MySQL 4.1.21 und die Backups werden zumindest wieder erstellt.
Das Zurückspielen funktioniert so aus dem Dumper bei uns zumindest nicht.
Zumindest nicht mit dem von Perl erzeugten Dump (latin1).
Wenn ich diesen Dump entzippe im Wordpad öffne und wieder speicher,
klappt das Einspielen wieder.

Also im crondump.pl steht in Zeile 80: my $character_set="utf8";

Irgendwie finde ich das alles extrem verwirrend und ich weiss jetzt nicht was ich machen muss, damit ich die Dumps direkt zurück spielen kann, ohne diese vorher mal im Wordpad wieder geöffnet zu haben.