MySQL-Dump eingespielt, Umlaute auf Website falsch (das übliche Problem...)

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    MySQL-Dump eingespielt, Umlaute auf Website falsch (das übliche Problem...)

    Ich habe mit folgendem Befehl einen MySQL-Dump erstellt (wird auch direkt gepackt):
    mysqldump --opt --no-create-db --skip-extended-insert --user=abc --password=xyz mydb | gzip -c -9 > mydb.sql.gz

    Die Tabellen haben allesamt als Charset "latin1".

    Der Dump enthält Zeilen wie die folgenden:
    /*!40101 SET NAMES utf8 */;
    /*!40101 SET character_set_client = utf8 */;

    Importiere ich nun diesen Dump via Konsole (via mysql-Programm) oder per phpMyAdmin, so habe ich im Endergebnis auf der Website, die die Daten anzeigt, fehlerhafte Umlaute und Sonderzeichen. In phpMyAdmin sind diese aber korrekt.

    Woran könnte das liegen? An welcher Stelle ist der Fehler? Eine Anpassung des PHP-Skripts, was die Daten ausliest und anzeigt, ist keine Lösung, denn vorher klappte es schließlich auch.

    Warum zeigt phpMyAdmin alles richtig an? Die Tabellen sind doch auf latin1 (latin1_swedish_ci) und somit dürften die Daten doch, wenn es nun wirklich UTF8 wäre, nicht korrekt dargestellt werden, oder doch? Ich habe auch beim Import via PMA schon diverse Charsets ausprobiert, es wird maximal schlimmer, nicht besser
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Ohje, das ist kein einfaches Thema, das kann an so vielen Stellen klemmen.

    Ich hatte bei mir ein ähnliches Problem, die Konfiguration der Anwendung auf dem Zielserver war minimal anders, die hat nämlich beim herstellen der Verbindung zur DB gesagt "Hey, ich will latin1", auf dem Quellserver war aber alles auf utf8mb4/utf8 konfiguriert. Es geht also nicht nur darum wie die Daten gespeichert sind, beim herstellen der Verbindung kann die Anwendung sagen welches Encoding sie sprechen möchte (SET NAMES ...).

    Eventuell hilft dir folgender "Artikel" weiter: The Umlaut Problem - How To Successfully Back Up And Restore MySQL Databases With Special Characters Using MySQLDumper

    Welche Version von MySQL wird hier verwendet?

    In der 5.7 hat MySQL die schwachsinnige Standardeinstellung von latin1 für charset bzw. latin1_swedish_ci für collation.
    In der My.ini auf Windows bzw. My.cnf für andere Systeme kann man das umstellen auf utf8 oder noch besser utf8mb4 wenn man auch China usw. supporten möchte.

    Hi,

    ggf. könntest du konvertieren zu utf8mb4 (also das "echte" UTF-8 mit variable width character encoding (MySQL "utf8"=="utf8mb3")).

    Aber egal, also wenn die Daten in der DB gut sind, müsste dann beim connect via Skript entsprechend der SET NAMES Befehl ausgeführt bzw. das Encoding im DSN übergeben werden. Zusätzlich soll natürlich auch das Encoding auf Ausgabeseite korrekt gewählt sein (<meta charset="..."> falls es HTML ist). Wenn auf tieferer Ebene keine expliziten Einstellungen zum Zeichensatz vorgenommen wurden, wird von oben aus runterpropagiert, also Server, Datenbank, Tabelle und dann eben bis auf die Tabellen-Spalte, was dann die höchste Prio hat.

    In seltenen Fällen könnte es bei PHP möglicherweise noch zu Problemen kommen in Verbindung mit setlocale und LC_CTYPE, aber das schließe ich hier mal vorsichtig aus..

    und somit dürften die Daten doch, wenn es nun wirklich UTF8 wäre, nicht korrekt dargestellt werden, oder doch?

    Ganz richtig, das dürfte und wird auch nicht gehen, latin1 ist ein single-byte-character-set (ISO-8859-1) und kann mit den Continuation-Bytes für Multibyte-Zeichen nix anfangen, entsprechend interpretiert er ungültige Byte-Sequenzen und zeigt Matsch an. Die meisten Sonderzeichen (wie z.B. auch "€"), Umlaute und Akzent-Zeichen funktionieren hier, weil sie innerhalb von 8 Bit noch Platz haben (quasi im ASCII-Extended Bereich, 80-FF), wohingegen die Unicode-Tabelle für z.B. das "€" einen ganz anderen Codepoint vorsieht.

    Ist der Import eigentlich auf dem gleichen System gemacht worden wie der Export?

    Link :thumbup:
    Hello World

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „Link“ ()

    Bevor ich mich ans weitere Testen mache, hier ein paar Fakten:

    MySQL-Version auf dem alten System (wo der Dump erstellt wurde): mysql Ver 14.14 Distrib 5.5.62, for debian-linux-gnu (x86_64) using readline 6.3
    MySQL-Version auf dem neuen System (wo der Dump importiert wird): mysql Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
    PHP-Version auf beiden Systemen: 5.6.40

    EDIT: In dem von @slice verlinkten Artikel ist von character_set_connection die Rede, was in MySQL als Standardwert utf8mb4 und in MariaDB utf8 hat.

    Siehe:
    dev.mysql.com/doc/refman/8.0/e…_character_set_connection
    mariadb.com/kb/en/server-syste…#character_set_connection
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Marcus Gräfe“ ()

    also hast du praktisch von MySQL 5.5 auf ne mischung aus 5.6 udnd 5.7 geupgradet mit MariaDB 10.1

    Die Doku von MySQL gehört zur Version 8.0, die von 5.5 haben die bereits eingestampft...
    daher hier mal die Doku für 5.6:
    dev.mysql.com/doc/refman/5.6/e…_character_set_connection

    Wir hatten mit fehlenden Umlauten bei unseren Kunden ebenfalls Probleme, und haben eben dafür gesorgt, das in der my.cnf entpsrechend alle diese Werte character_set_xyz UND collation_xyz auf utf8mb4 bzw. utf8mb4_unicode_ci standen.

    Ich habe nun in das PHP-Skript, welches für die Ausgabe verantwortlich ist, direkt hinter dem Aufbau der Datenbankverbindung das hier gemacht:

    SQL-Abfrage

    1. SET NAMES 'latin1';

    Nun geht es!
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

Facebook
Telefonspende