Klaus1: Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt

Hallo,

nach dem Upgrade von MySQL 5.7 auf 8.0 werden auf den Webseiten die deutsche Umlaute jetzt im UTF8 angezeigt (z.B. ü anstelle eines ü), obwohl sowohl die Kollation aller Tabellenfelder auf latin1_general_ci steht und in jedem HTML/PHP-Script

header("Content-Type: text/html; charset=iso-8859-1")
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

Über ut8_decode() bekomme ich zwar wieder die deutschen Umlaute korrekt angezeigt, aber kann ich das vielleicht generell einstellen, damit die Anzeige der deutschen Umlaute wieder direkt funktioniert?

LG Klaus

  1. Ich denke, ich habe selber herausgefunden:

    In der my.cnf habe ich folgende Zeilen hinzugefügt:

    [client]
    default-character-set=latin1
    
    [mysql]
    default-character-set=latin1
    
    [mysqld]
    init-connect='SET NAMES latin1'
    character-set-server = latin1
    
    

    Jetzt funktioniert es wieder.

    LG Klaus

    1. Ich denke, ich habe selber herausgefunden:

      In der my.cnf habe ich folgende Zeilen hinzugefügt:

      [client]
      default-character-set=latin1
      
      [mysql]
      default-character-set=latin1
      
      [mysqld]
      init-connect='SET NAMES latin1'
      character-set-server = latin1
      
      

      Jetzt funktioniert es wieder.

      LG Klaus

      Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…

      1. Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…

        Wobei es nur sehr wenige akzeptable Gründe gäbe, das nicht zu tun.

        Auch bestehende Textdateien lassen sich automatisch umbauen und in Skriptsprachen, ich sag mal „diesseits von Perl“ ist die Nutzung von UTF sehr einfach, es sind eher keine Umbauten mehr nötig.

        1. Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…

          Wobei es nur sehr wenige akzeptable Gründe gäbe, das nicht zu tun.

          Auch bestehende Textdateien lassen sich automatisch umbauen und in Skriptsprachen, ich sag mal „diesseits von Perl“ ist die Nutzung von UTF sehr einfach, es sind eher keine Umbauten mehr nötig.

          Hmmm… da habe ich durchaus schon andere Erfahrungen gemacht, wie viel Aufwand es werden kann, bis man „Altsysteme“ durchgehend stabil auf UTF-8 gebracht hat. Das lag sicher nicht in der Datenbasis. Die Konvertierung von DBs oder auch Textfiles ist dabei geschenkt. Aber im Code kann das, wie Dedlfix ja schon schrieb, eine ganz schön fiese Friemelei werden, bis man alles „erschlagen“ hat.

          Wenn man also ein bestehendes System hat, „was tut“ und sich gar kein (oder nur geringes mittels anderer Behelfsmittel erreichbarer) Bedarf nach einem großen Zeichensatz stellt, kann man durchaus zum Schluss kommen, sich den Aufwand zu sparen.

          Klar, wenn man jetzt was Neues aufsetzt, wäre es dämlich den Aspekt zu vernachlässigen.

  2. Tach!

    nach dem Upgrade von MySQL 5.7 auf 8.0 werden auf den Webseiten die deutsche Umlaute jetzt im UTF8 angezeigt (z.B. ü anstelle eines ü), obwohl sowohl die Kollation aller Tabellenfelder auf latin1_general_ci steht und in jedem HTML/PHP-Script

    header("Content-Type: text/html; charset=iso-8859-1")
    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    

    Die HTTP-Header-Angabe ist keine Anweisung für PHP, "das richtige zu tun". Die Angabe ist nur ein Hinweis für den Empfänger, welche Kodierung vorliegt. Dass sie tatsächlich vorliegt, liegt in deiner Verantwortung als Progammierer. Du musst bei allen Handlungen mit Daten darauf achten, in welcher Kodierung sie vorliegen, und dem Zielsystem mitteilen, in welcher Kodierung du sie zu ihm zu senden gedenkst. Einfach gesagt, aber der Teufel steckt im Detail.

    Generell ist zu sagen, dass es sinnvoll ist, auf UTF-8 zu wechseln, und andere Kodierungen nur zu verwenden, wenn man einen zwingenden Grund dafür hat.

    Du hast den Tabellenfeldern zwar gesagt, in welcher Kodierung die Daten zu speichern sind. Dazu kommt aber, dass du auf der Verbindung zu MySQL separat angeben musst, in welcher Kodierung du die Daten sendest. MySQL kodiert das gegebenenfalls um, wenn das zur Feldangabe nicht passt. Damit es dabei keine Probleme gibt, ist Voraussetzung, dass die Verbindungskodierungsangabe zu den Daten passt. MySQL erkennt nicht von sich aus, wenn du UTF-8 sendest, wenn du das als ISO-8859-1/Latin1 deklarierst, oder der Default-Wert ist. Anscheinend ist es hier der Fall, dass die Daten als Latin1 erwaetet, jedoch als UTF-8 gesendet wurden. Ich vermute, dass du beim Übertragen nicht auf die Kodierungsangabe geachtet hast und die Systeme unterschiedliche Default-Werte hatten.

    Als erstes muss nun geschaut werden, was konkret vorliegt. Schau dir die Daten mit phpMyAdmin an. Wenn er die Umlaute richtig anzeigt, sind die Daten in der Regel passend zur Feldkodierung gespeichert. Zeigt er die Umlaute nicht korrekt an, sind die Daten kaputt und müssen repariert werden. Oder neu eingespielt, mit Beachtung und Angeben der tatsächlichen Kodierung.

    dedlfix.

  3. Hallo Klaus,

    ja, das Problem ist gelöst (bzw. umgangen), nur als Hintergrund warum das gerade bei dem Update passiert:

    nach dem Upgrade von MySQL 5.7 auf 8.0 werden auf den Webseiten die deutsche Umlaute jetzt im UTF8 angezeigt (z.B. ü anstelle eines ü), obwohl sowohl die Kollation aller Tabellenfelder auf latin1_general_ci steht […]

    Die Kollation ist für die Kodierung erstmal nicht relevant (damit werden nur die Sortierregeln vorgegeben) wobei damit als Charset latin1 eingestellt ist. Das alles ist aber für das Abfragen von Daten nicht wichtig, da ist wichtig was für die Verbindung zur Datenbank als Charset eingestellt ist – und da kommt das Upgrade MySQL 5.7 → 8.0 ins Spiel: während der Standardwert unter 5.7 noch latin1 war, ist er unter 8.0 jetzt utf8mb4. Du hast vermutlich an der Standardeinstellung nichts geändert (und auch kein Charset für die Verbindung gesetzt) und damit gilt der neue Standardwert und die Datenbank liefert dir UTF-8-Daten. Da du die im Script verarbeitest als wären sie latin1-kodiert und auch de Browser mitteilst dass das so wäre, bekommst du natürlich nur Zeichensalat angezeigt.

    Statt die Einstellungen des Servers zu verändern wäre es besser beim Aufbau der Verbindung immer anzugeben welcher Charset verwendet werden soll:

    Und auch wenn es schon gesagt wurde: verwende nicht latin1 sondern immer und überall UTF-8.

    Gruß,
    Tobias