Ist utf8 nicht gleich utf8?

  • Hi liebe Forenmitglieder,


    bin gerade nach netcup migriert und habe meine 3 Homepages nebst Datenbanken auch schon auf dem Webspace abgelegt. Das Problem ist meine gebastelte interaktive Karte. Diese will auf einmal nicht so wie früher - und das ist definitiv ein Kollationsproblem. Bloß kenne ich mich mit den utf8-Derivaten nicht so ganz aus. Meine alte Datenbank habe ich einfach hier in die neu angelegte Datenbank migriert.


    Hier mal die Einstellungen der alten SQL-db:

    Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8_general_ci

    Operationen: utf8_unicode_ci

    besagte Tabelle: utf8_general_ci


    Das wurde in die netcup-db migriert, welche diese Einstellungen hatte (und natürlich immer noch hat:

    Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8mb4_unicode_ci

    Operationen. utf8_general_ci

    besagte Tabelle: utf8_general_ci


    Wie man sieht hat die besagte Tabelle also bei netcup die gleiche Kollation wie bei meinem alten Hoster. Sollte also hinhauen - weit gefehlt. Die HTML-Seite wurde zwar angezeigt, aber die Datenbankabfrage (Marker werden auf eine Landkarte gesetzt) funktionierte nicht. Dabei werden die Datensätze in eine XML-Datei geparsed und ich habe schnell herausfinden können, wann der Parser abgebrochen hat. Das war an einem Umlaut (ü). Damit war klar was das Problem war, und da ich mit dem mistigen Kollationen immer auf Kriegsfuß stehe, habe ich mein Script angepasst (an den Kommentaren ersichtlich was umgestellt wurde).

    Hier das Script: phpsqlinf_result.php


    So, nun wurden alle Marker wieder angezeigt. Leider bleibt ein Kollationsproblem beim Editieren der Marker - besser gesagt beim wieder reinschreiben in die Datenbank. Auch hier ist das php-Script mit einem Kommentar versehen. Geschrieben wird mittels HTML-Post-Methode. Meta-Tag und auch Header stehen auf utf8.

    Hier das Script: edit_reg.php


    ...da ich die Seite schon vor langer Zeit gemacht habe, bin ich nun etwas eingerostet. Wie gesagt, es ist ein Kollationsproblem, weil ja von Anfang an das Einlesen aus der Datenbank an Umlauten scheiterte - ich seh vor lauter utf8 Tags aber nicht den Fehler. Vielleicht könnt Ihr mir helfen.


    Ihr könnt gerne mal selber ein paar Marker setzten und das Ergebnis überprüfen (rausholen funktioniert / reinschreiben da verhaut er die Umlaute).

    Hier die Seite (die vorher funktionierte): www.palmenstandorte.de


    -volker-

  • Welche PHP-Version lief beim alten Hoster und welche hast Du bei netcup ausgewählt? Für mich klingt das nicht nach einem Problem mit der DB, eher nach einem Problem mit dem Standardzeichensatz von PHP bzw. Deiner Website.


    Die mysql_* Funktionen gibt es übrigens ab PHP 7.0 nicht mehr, Du wirst das Script somit früher oder später sowieso anpassen müssen: http://php.net/manual/de/migration55.deprecated.php

  • killerbees19 ,


    keine Ahnung, ich habe jedenfalls mittels .htaccess php5.6 eingestellt (AddHandler x-httpd-php56 .php). Und dieses .htaccess ist auch im netcup-Verzeichnis enthalten. Dann müsste doch auch hier 5.6 laufen - oder nicht? :)

    Ich habe mal gerade auf palmenstandorte ein phpinfo() abgesetzt - die Einstellung wurden also mit .htaccess übernommen. PHP-Version ist 5.6.36


    H6G ,

    mein Fehler war wohl diesbezüglich bei netcup eine Datenbank anzulegen und sofort zu importieren. Besser wäre es wohl gewesen erst mal alles bei der neuen db auf utf8_unicode_ci umzustellen. Trotzdem, vorm Import und nach dem Import haben beide Tabellen die gleiche Kollation (utf8_general_ci).

    Was ist Deine Empfehlung? Ganze db löschen und neu importieren? Alles auf utf8_unicode_ci einstellen - ich schätze die Tabelle wird dann trotzdem mit ihrem Zeichensatz utf8_general_ci importiert - nur ist dann wenigsten die Verständigung zwischen Client und Server einheitlich.


    -volker-

  • Mal eine kurze Sicherheitswarnung (nicht das 100% ige Thema): ich denke, dass dein Code nicht vor SQL Injektionen geschützt ist, da du nie weißt, ob in $_POST['id'] nicht irgendwie etwas böses steht. -> jemand kann böse Sachen mit der Datenbank anstellen und sie z.B. löschen.

  • Hay,


    unabhängig davon gibt es auch noch einen Umstand, der mir mal auf die Füße gefallen ist. Wenn Du phpMyAdmin dazu benutzt hast, dann würde ich auch mal folgendes überprüfen:


    Es gibt ältere MySQL/phpMySQL-Versionen, bei welcher die Zeichencodierung der Export-Datei noch extra auf UTF-8 umgestellt werden musste. Default war damals ein latin-1 (o.ä.). Wenn nun UTF-8 in eine Exportdatei mit latin-1 geschrieben werden, dann gehts natürlich auch schief. Beim Import und Export muss die Export-Datei auch im selben Zeichenformat geschrieben - gelesen werden. Beim Import kann man das Zeichenformat direkt einstellen, beim Export zeigt phpMyAdmin diese Auswahl nur an, wenn man den "angepassten" Export auswählt.


    pasted-from-clipboard.png


    CU, Peter

  • Hi Peter,


    für den Ex -und Import benutze ich MySQLDumper. An der Benutzung von phpmyAdmin lag es also nicht.


    aNewUser ,

    kann schon sein - bisher (ich glaube seit 10 Jahren steht die Seite im Netz) ist das noch nicht passiert. Außerdem mache ich täglich Backups. Aber Du hast schon recht - ne Profiseite ist das natürlich nicht.


    ...macht mal Vorschläge, wie ich den Kollationsfehler weg bekomme. db komplett löschen und neu importieren?


    -volker-

  • Nachtrag: Ich selber kann meine db gar nicht löschen - auch nicht mittels Konsole und drop-Befehl. Da muss ich wohl ein Ticket für aufmachen.

    Die neue db dann am Besten (vor dem Importieren) so einstellen, wie die alte Datenbank (siehe Eröffnungsthread). Oder soll ich alles auf utf8_unicode_ci stellen.


    Allerdings (fällt mir gerade ein): Die anderen beiden Homepages (sind cms-Systeme) laufen ja anscheinend fehlerfrei mit den Einstellungen der neuen db. Ich werde das mal überprüfen, und auch mal bei einem cms ein Umlaut abspeichern. Jepp, das cms speichert die Umlaute richtig in die db ab und holt sie auch so wieder raus. Dann muss es also doch per Script zu lösen sein. Ich schau mir aber auch noch mal die Tabellen des cms an, unter welcher Kollation das abgespeichert ist.

  • utf8 ist utf8, aber bei (mysql) Datenbanken gibts den Sonderfall, daß dort utf8 historisch nur bis 3 bytes geht, aber neue Zeichen 4 bytes brauchen. und dafür hat die Datenbank dann einen neuen Zeichensatz erfunden, utf8mb4. Was effektiv bedeutet, daß du eigentlich alle Datenbanken auf utf8mb4 umstellen musst, weil utf8 nicht mehr reicht und dann komische Sachen passieren, wenn die Leute mit ihren neumodischen Emojis ankommen.


    Wenn du statt einem Umlaut zwei komische Zeichen siehst, dann hat irgendwas anderes in der Kette utf8 nicht unterstützt sondern z.B. latin1 gesehen und somit den utf8-Umlaut (ein Zeichen zwei Bytes) als zwei Zeichen verstanden. Da muss man dann einfach suchen. Manchmal ist es schon der mysql-Dump selber, der zwar richtig in UTF-8 kodiert ist aber dann trotzdem nicht UTF-8 (als Zeichensatz für die Übertragung) setzt.


    Wenn man mysqldump o.ä. Tools verwendet um die Datenbank zu sichern, müssen das auch neue Versionen sein die utf8mb4 unterstützen, sonst werden alle utf8mb4 Zeichen stillschweigend zu Fragezeichen. Ganz ohne Fehlermeldung, merkt man erst wenns zu spät ist. Das kann passieren wenn man mit altem Debian, CentOS unterwegs ist, für utf8mb4 sich ein MariaDB irgendwo her organisiert hat, aber mysqldump noch das Tool vom alten mysql ist das von utf8mb4 nie was gehört hat...

  • frostschutz ,


    Du bist da 100% auf der richtigen Spur. Genau diesen Einwand habe ich auch schon im Netz gefunden (bei einem anderen ähnlichem Problemfall)


    Zitat:

    "Nach meiner Erfahrung sieht das so aus wenn Strings in einem

    Multibyte-Zeichensatz (z.B. UTF-8) vorliegen und in einer DB-Spalte

    abgelegt werden, die einen Singlebyte-Zeichensatz hat. Zwei oder drei

    Bytes ergeben zusammengenommen eigentlich ein Sonderzeichen – der

    Singlebyte-Zeichensatz interpretiert aber jedes Byte einzeln und

    speichert sie so."


    Ich habe das für mich dann so interpretiert, dass ich das Multibyte-Format der neuen db vor der Migration meiner alten db in die Kollation 'utf8_general_ci' umstelle, um dann erneut ein Migrationsversuch zu starten. Da ich genau auf diese Kollation keinen Einfluss habe (Die allgemeine Einstellung 'utf8mb4_unicode_ci' lässt sich als User nicht verändern - siehe auch hier mein Eröffnungsthread) habe ich mal ein Ticket aufgemacht (nur die 'Operationen' und die Kollationen der Tabellen selber kann man umstellen).


    Der Dump meiner alten db wurde tatsächlich mit MySQLDumper vollzogen, welcher schon länger nicht mehr weiter entwickelt wird. Wenn ich ein Dump bei meinem alten Hoster mit PHPMyAdmin mache (welches hoffentlich dann das Multibyte-Format unterstützt muss ich doch vor dem Dump meine gange db in das Multibyte-Format umwandeln (stimmt doch, oder?). Aber gleichzeitig habe ich von irgenwo auch gehört, dass ich hier mit PHPMyAdmin keine db > 2 MB (komprimiert) migrieren kann. Meine db ist aber > 5 MB. Ich werde mal den netcup-Support hierhin verlinken - vielleicht fällt dem noch was ein.


    -volker-