nicht angemeldet
Hallo,
Wenn du vorher eine Version kleiner als 4.1 hattest, dann ist beim Übernehmen der Datenbank-Dateien zu beachten, dass die Default-Einstellung des neuen MySQL-Servers zunächst einmal wieder genauso eingestellt werden muss wie beim alten. Hierzulande wird das latin1 gewesen sein. Nun muss man mindestens einmal für jedes Feld die Kodierung/Kollation ändern. Dabei ist es fast egal, wohin man umstellt, Hauptsache die neue Kodierung kann alle verwendeten Zeichen aufnehmen. Es reicht, wenn man innerhalb der Kodierung bleibt und nur die Kollation eine andere ist. Man kann es auch gleich wieder zurückstellen. Die Änderung führt dazu, dass diese Information in die Tabellendateien eingetragen wird. Bis einschließlich Version 4.0 stand sie nicht drin, da es nur eine generelle Kodierung für den gesamten MySQL-Server gab. Hat man das für die Felder getan, kann man das auch noch für die Tabellen und Datenbanken machen. Danach kann man auch problemlos die Defaulteinstellung des Servers ändern.
Ich glaube, die alte Version war 4.0.12. Sicherlich aber ohne die Kodierungsangaben ...
Was zeigt der PMA auf seiner Startseite an, welche Kodierung er verwendet? Was ist im Server eingestellt (Was zeigt die Seite System-Variablen für die "character set ..."-Werte an?)
In der My.cnf steht
character-set-server = latin1
collation-server = latin1_general_ci
Die Tabellen stehen alle auf latin1_general_ci.Du hast den ersten Teil der Frage nicht beantwortet. Davon ausgehend, dass der PMA UTF-8 verwendet, kann ich mir schon vorstellen, dass er Grund für eine Konvertierung hat. Bisher hatte er immer Recht und der Fehler lag woanders.
Seltsamerweise steht jetzt auf der Startseite des PMA beim MySQL-Zeichensatz UTF8, aber bei der MySQL-Verbindung steht latin1_general_ci.
Ich werd wohl mal alle DBs, Tabellen und Felder auf UTF8 ändern, nachdem was ich so gegoogled habe, ist UTF8 empfohlen.
Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.
Die deutschen Umlaute werden mit Sonderzeichen dargestellt (das 'ü' ist beispielsweise eine kleine schwarze Raute mit einem Fragezeichen drin)BLOB-Felder werden als Binärdaten behandelt. Wenn du darin Text stehen hast, solltest du einen der TEXT-Feldtypen verwenden.
Welches Feld sollte ich anstatt Blob nehmen? Wäre Longtext besser?
Vielleicht hast du auch nur nicht beachtet, die auf deinen Datenbankverbindungen zu verwendende Kodierung explizit auszuhandeln (SET NAMES ... oder besser mit der Funktion mysql_set_charachter_set() bzw. deren Pendant in der verwendeten Umgebung (beispielsweise mysqli in PHP5)).
Die meisten meiner Tabellenabfragen funktionieren wunderbar und
Da die Scripte nie auf einem fremden Server laufen werden, sollte ich den Zufall eigentlich ausschalten können. Es ist sehr aufwendig, wenn ich bei allen Scripten bzw. Tabellenabfragen die Kodierung explizit angeben müsste. Die Scripte sind alle historisch gewachsen und meine Programmierkenntnisse erstreckten sich noch nicht über Programmierung von Services ...
Sicherlich habe ich etwas leichtgläubig angenommen, die Portierung auf einen neuen Server würde nachwievor per Click&Copy funktionieren.
Sollte ich vielleicht im Zuge der Anpassung aller Tabellen etc. auch gleich auf BDB-Tabellen wechseln? Soviel ich verstanden habe, würde sich die Transactionssicherheit erhöhen und auch die Performance steigern??
Klaus