Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt – SELFHTML-Forum Forum als Ergänzung zum SELFHTML-Wiki und zur Dokumentation SELFHTML https://forum.selfhtml.org/self?srt=yes Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 08:48:07 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789321?srt=yes#m1789321 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789321?srt=yes#m1789321 <p>Hallo,</p> <p>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 <code>latin1_general_ci</code> steht und in jedem HTML/PHP-Script</p> <pre><code class="block">header("Content-Type: text/html; charset=iso-8859-1") <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </code></pre> <p>Über <code>ut8_decode()</code> 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?</p> <p>LG Klaus</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 09:00:48 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789322?srt=yes#m1789322 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789322?srt=yes#m1789322 <p>Ich denke, ich habe selber herausgefunden:</p> <p>In der my.cnf habe ich folgende Zeilen hinzugefügt:</p> <pre><code class="block">[client] default-character-set=latin1 [mysql] default-character-set=latin1 [mysqld] init-connect='SET NAMES latin1' character-set-server = latin1 </code></pre> <p>Jetzt funktioniert es wieder.</p> <p>LG Klaus</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 09:05:50 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789324?srt=yes#m1789324 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789324?srt=yes#m1789324 <p>Tach!</p> <blockquote> <p>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 <code>latin1_general_ci</code> steht und in jedem HTML/PHP-Script</p> <pre><code class="block">header("Content-Type: text/html; charset=iso-8859-1") <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </code></pre> </blockquote> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>dedlfix.</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 15:35:20 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789332?srt=yes#m1789332 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789332?srt=yes#m1789332 <p>Hallo Klaus,</p> <p>ja, das Problem ist gelöst (bzw. umgangen), nur als Hintergrund warum das gerade bei dem Update passiert:</p> <blockquote> <p>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 <code>latin1_general_ci</code> steht […]</p> </blockquote> <p>Die Kollation ist für die Kodierung erstmal nicht relevant (damit werden nur die Sortierregeln vorgegeben) wobei damit als Charset <code>latin1</code> eingestellt ist. Das alles ist aber für das Abfragen von Daten nicht wichtig, da ist wichtig was für die <em>Verbindung</em> zur Datenbank als Charset eingestellt ist – und da kommt das Upgrade MySQL 5.7 → 8.0 ins Spiel: während der <a href="https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html#charset-connection-client-configuration" rel="nofollow noopener noreferrer">Standardwert unter 5.7</a> noch <code>latin1</code> war, ist er <a href="https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-client-configuration" rel="nofollow noopener noreferrer">unter 8.0</a> jetzt <code>utf8mb4</code>. 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.</p> <p>Statt die Einstellungen des Servers zu verändern wäre es besser beim Aufbau der Verbindung immer <a href="https://www.php.net/mysqlinfo.concepts.charset" rel="nofollow noopener noreferrer">anzugeben</a> welcher Charset verwendet werden soll:</p> <ul> <li>mit PDO über <code>charset=latin1</code> im <a href="https://www.php.net/ref.pdo-mysql.connection" rel="nofollow noopener noreferrer">DSN</a> beim <a href="https://www.php.net/pdo.construct" rel="nofollow noopener noreferrer">Aufbau der Verbindung</a></li> <li>bei der mysqli-Erweiterung über <a href="https://www.php.net/mysqli.set-charset" rel="nofollow noopener noreferrer"><code class="language-php"><span class="token function">set_charset</span><span class="token punctuation">(</span><span class="token punctuation">)</span></code></a></li> </ul> <p>Und auch wenn es schon gesagt wurde: verwende nicht latin1 sondern immer und überall UTF-8.</p> <p>Gruß,<br> Tobias</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 09:03:47 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789323?srt=yes#m1789323 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789323?srt=yes#m1789323 <blockquote> <p>Ich denke, ich habe selber herausgefunden:</p> <p>In der my.cnf habe ich folgende Zeilen hinzugefügt:</p> <pre><code class="block">[client] default-character-set=latin1 [mysql] default-character-set=latin1 [mysqld] init-connect='SET NAMES latin1' character-set-server = latin1 </code></pre> <p>Jetzt funktioniert es wieder.</p> <p>LG Klaus</p> </blockquote> <p>Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Fri, 18 Jun 21 17:34:07 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789335?srt=yes#m1789335 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789335?srt=yes#m1789335 <blockquote> <p>Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…</p> </blockquote> <p>Wobei es nur sehr wenige akzeptable Gründe gäbe, das nicht zu tun.</p> <p>Auch bestehende Textdateien lassen sich automatisch umbauen und in Skriptsprachen, ich sag mal <em>„diesseits von Perl“</em> ist die Nutzung von UTF sehr einfach, es sind eher keine Umbauten mehr nötig.</p> Nach MySQL Upgrade von 5.7 auf 8.0 Darstellung von Umlauten kaputt Sat, 19 Jun 21 10:35:01 Z https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789351?srt=yes#m1789351 https://forum.selfhtml.org/self/2021/jun/18/nach-mysql-upgrade-von-5-7-auf-8-0-darstellung-von-umlauten-kaputt/1789351?srt=yes#m1789351 <blockquote> <blockquote> <p>Zukunftsfähiger wäre wohl eine komplette Migration auf utf8. Das muss aber fallabhängig entschieden werden…</p> </blockquote> <p>Wobei es nur sehr wenige akzeptable Gründe gäbe, das nicht zu tun.</p> <p>Auch bestehende Textdateien lassen sich automatisch umbauen und in Skriptsprachen, ich sag mal <em>„diesseits von Perl“</em> ist die Nutzung von UTF sehr einfach, es sind eher keine Umbauten mehr nötig.</p> </blockquote> <p>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.</p> <p>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.</p> <p>Klar, wenn man jetzt was Neues aufsetzt, wäre es dämlich den Aspekt zu vernachlässigen.</p>