Dringend: Nach 64-Bit-Umstellung UFT-8 funktioniert nicht mehr?!

[Anton Korduan]

Hallo!

Gestern Nacht war die Umstellung auf meinen Tarif MagagedHosting64.

Jetzt sehe ich, dass die Daten aus der gesamten MySQL-Datenbank plötzlich falsch ausgegeben werden:
Statt ä erscheint ä etc.

Das ist ein großes Probelm, denn meine laufende Anwendung (an der Kunden hängen) basiert natürlich darauf, dass das richtig läuft.

Ich habe nichts geändert - weder im PHP noch in der Datenbank:

• In der DB ist nach wie vor z.B. beim Feld "Nachname" als Kollation "utf8_general_ci" drin - das passt, war vorher schon so.
• Auch in PHP ist nach wie vor die Ausgabe mit "utf8_encode()" geregelt - passt auch, das ist auch wie vorher schon.
• Und die gespeicherten Datensätze sind auch unverändert - also ist der Nachname beispielsweise als "Müller" abgespeichert.

Ich weiß nicht, wo ich ansetzen soll.
Vielleicht in irgendwelchen PHP.inis bzw. in der neuen user.ini?

Bitte dringend um Hilfe,
Danke und herzliche Grüße,
Anton Korduan

[Anton Korduan]

Nachtrag:

Ich glaube mittlerweile nicht, dass es an der PHP.ini bzw User.ini liegt.
Da waren auch vorher kaum / keine Einstellungen von mir getätigt worden.

Vielleicht sind in der MySQL-Datenbank (neue Version, upgedatet von 5.6 auf 5.7) bzw. im phpMyAdmin irgend welche neuen Eintellmöglichkeiten?

Beim Datenbank-Server habe ich den Zeichensatz nun umgestellt, weil ich überall in meinen Datenbanken utf8_general_ci verwende:



Aber das hat auch nichts gebracht :-(

Daher meine Zusatzfrage: Soll ich das wieder zurücksetzen? Nicht, dass ich da jetzt was Wichtiges verstellt habe? Ich weiß garnicht mehr, was da vorher drin war...

[HomerS]

[*]Auch in PHP ist nach wie vor die Ausgabe mit "utf8_encode()" geregelt - passt auch, das ist auch wie vorher schon.

Warum utf8_encode, wenn Daten und Verbindung bereits utf8 sind?
Haben deine Anwendungen den Zeichensatz der DB-Verbindung festgelegt? (mysqli_set_charset)
UTF8 wird jetzt Standard sein, und auf den alten Sytemen latin1.
Das könnte deinen Einsatz von utf8_encode erklären. Da wäre aber ein Setzen des Zeichensatzes besser/einfacher gewesen.
(ist natürlich nur eine Vermutung)

[Anton Korduan]

Warum utf8_encode, wenn Daten und Verbindung bereits utf8 sind?
Haben deine Anwendungen den Zeichensatz der DB-Verbindung festgelegt? (mysqli_set_charset)
UTF8 wird jetzt Standard sein, und auf den alten Sytemen latin1.
Das könnte deinen Einsatz von utf8_encode erklären. Da wäre aber ein Setzen des Zeichensatzes besser/einfacher gewesen.
(ist natürlich nur eine Vermutung)

Danke, HomerS - das klingt schon richtig gut.

Ich möchte vermeiden, alle Dateien und Programmierungen anpacken zu müssen.
Daher wäre es besser, wenn utf8_encode drin bleiben kann.

Vor der Tarifumstellung (und damit vor der Umstellung von MySQL 5.6 auf 5.7) ging ja alles Jahrelang einwandfrei ...

Jetzt suche ich nach einem Weg, mit geringsmöglichem Aufwand den Zustand wieder herzustellen, dass die Umlaute korrekt dargestellt werden.
Am Besten wäre es natürlich, wenn ich in der MySQL-Datenbank eine entsprechende Einstellung tätigen könnte. Nur gibt's das / und welche wäre das?

[HomerS]

Teste doch erstmal an einer Stelle, ob das das Problem ist.
Als Zwischenlösung kannst du versuchen direkt nach dem Verbindungsaufbau ein mysqli_set_charset mit "latin1" festzulegen.

Das soll aber auf keinen Fall als Empfehlung verstanden sein.
Ich weiß nicht, wie vernünftig es ist die Zeichensätze so zu "mischen", schließlich ist UTF8 wesentlich komplexer.

Falls es dir viel Zeit erspart utf8_encode herauszu operieren, könntest du über Suchen/Ersetzen "utf8_encode(" ersetzen mit zB. "myfake_utf8_encode(".
Die myfake_utf8_encode gibt dann einfach den String unbearbeitet zurück.

[Anton Korduan]

Teste doch erstmal an einer Stelle, ob das das Problem ist.
Als Zwischenlösung kannst du versuchen direkt nach dem Verbindungsaufbau ein mysqli_set_charset mit "latin1" festzulegen.

Das soll aber auf keinen Fall als Empfehlung verstanden sein.
Ich weiß nicht, wie vernünftig es ist die Zeichensätze so zu "mischen", schließlich ist UTF8 wesentlich komplexer.

Falls es dir viel Zeit erspart utf8_encode herauszu operieren, könntest du über Suchen/Ersetzen "utf8_encode(" ersetzen mit zB. "myfake_utf8_encode(".
Die myfake_utf8_encode gibt dann einfach den String unbearbeitet zurück.

Bin schon dran - hier die Screenshots, die Zeigen, wie es aktuell aussieht:

Auf der Webseite (die von der Datenbank gespeist wird) sieht die Begrüßung so aus - da stehen sollte "Andön":


Der betreffende PHP-Codeshnipsel sieht so aus:



Hier siehst Du, wie der Datensatz in der Datenbank abgespeichert ist (Nicht über den Nachnamen wundern, ist die Testumgebung...):



Und das ist die Tabellen-Definition:




Entscheidend ist (ich wiederhole, das ist aber wichtig, denke ich):
Vor der Umstellung des Tarifs bzw. der Datenbank von MySQL 5.6 auf 5.7 hat ja alles funktioniert.

Also muss doch bei der Tarif/Datenbank-Umstellung etwas geändert worden sein.
DAS herauszufinden wäre glaube ich die Lösung.

So oder so - danke für Deine Unterstützung, HomerS!

Anton

[Gast]

Mach och mal das, was Dir hier geraten wird und nimm testweise das utf8_encode raus aus dem PHP Code. Zumal Du eine Testumgebung hast...
Das sollte bei dem von Dir beschriebenen Setup der richtige Weg sein. Wenn das klappt, dann musst Du eben alle Stellen, an denen das genutzt wird, anpassen. Kommt leider vor, dass sich alte Programmiersünden bei Updates rächen.

[Anton Korduan]

Mach och mal das, was Dir hier geraten wird und nimm testweise das utf8_encode raus aus dem PHP Code. Zumal Du eine Testumgebung hast...
Das sollte bei dem von Dir beschriebenen Setup der richtige Weg sein. Wenn das klappt, dann musst Du eben alle Stellen, an denen das genutzt wird, anpassen. Kommt leider vor, dass sich alte Programmiersünden bei Updates rächen.

Sorry, Du hast Recht. Ich hatte das schon gemacht und nur noch keine Rückmeldung gegeben:

Ja, wenn ich das utf8_encode rausnehme funktioniert alles.

Soweit, so gut.
Fast.

Denn es ist nicht so einfach, alle Vorkommen zu ersetzen.

Die Anwendung ist komplex, besteht aus hunderten von Dateien und da kann ich nicht einfach so alles mal via Suchen & Ersetzen austauschen lassen.
Das zieht einiges an Aufwand, Test-Arbeit und Risiko nach sich.

Daher hoffe ich, dass es einen einfacheren Weg gibt.

Ich denke darüber nach, die Daten in der Datenbank via Script zu konvertieren oder ähnliches.

Jedoch:

Da es ja vor der Umstellung funkioniert hat, habe ich noch immer die große Hoffnung, dass es sich durch einen einfachen "Trick" innerhalb der MySQL-Datenbank lösen lässt.

Ohne, dass ich die Anwendung oder Datensätze verändern muss.

Danke und herzliche Grüße,
Anton

PS: Und ist es doch keine pauschale Programmiersünde, utf8_encode zu verwenden, oder?

[Micha M.]

Bin nicht sicher, aber ich glaube mich trifft ein ähnliches Problem:
Wurde gestern umgezogen und seitdem kommen zig Mails zurück. Einige davon weisen auf eine ähnliche Problemstellung hin:
Die Emails werden von verschiedenen Webs erzeugt. Teils per PHPMailer, teils per SMTP. Es waren z.B. Bestellbestätigungen darunter.
Zurück geschickt wurden die allesamt mit einem SPAM-Vermerk von Google.
Teilweise waren die Betreffzeilen zudem extrem verunstaltet.
Ein Beispiel (XXX_YYYY habe ich eingefügt, da dort ein Domain-Name stand):
=?UTF-8?Q?Deine_Bestellung_bei_XXXX_YYYY_vom_5._M ?= =?UTF-8?Q?=C3=A4rz_2022_ist_eingegangen.?=
Vorher sah das mal so aus:
Deine Bestellung bei XXXX.YYYY vom 5. März 2022 ist eingegangen.

Ich nehme an, dieses Einfügen von "UTF-8" und verändern der Betreff-Zeile hat die gleichen Ursachen?!
Falls ja; wäre ich an einer globalen Lösung ebenfalls interessiert, da ich auch unmöglich sämtliche bei mir gehosteten Webs durchforsten und abändern kann, bzw. das auch nicht meinen Kunden aufbürden kann.

[Lukas M.]

Teils per PHPMailer, teils per SMTP. Es waren z.B. Bestellbestätigungen darunter.
[...]
Ich nehme an, dieses Einfügen von "UTF-8" und verändern der Betreff-Zeile hat die gleichen Ursachen?!

PHPMailer kann auch per SMTP versenden. Mails über den Webserver verschicken war früher zwar eine einfache Möglichkeit, aber noch nie empfehlenswert und wird afair auch in den neuen Tarifen gar nicht mehr unterstützt.
Die Veränderung des Betreffs hat technische Gründe und ist relativ normal.

[Micha M.]

PHPMailer kann auch per SMTP versenden. Mails über den Webserver verschicken war früher zwar eine einfache Möglichkeit, aber noch nie empfehlenswert und wird afair auch in den neuen Tarifen gar nicht mehr unterstützt.

Ja, ich habe das inzwischen gelesen, dass das wohl nicht mehr unterstützt wird... nun wird es nur schwer von jetzt auf gleich alles um zu stellen, weil das teilweise in z.B. Wordpress aktive Plugins sind, die dann ggf. sogar ersetzt werden müssten...
Aber gut; das ist dann (teilweise) Sache der Kunden...

Die Veränderung des Betreffs hat technische Gründe und ist relativ normal.

Diese Veränderung... wo kommt die her? Also von GMAIL? Oder vom PHP-Mailer? Oder woher sonst?
Anders gefragt; kann ich das irgendwie beeinflussen?

[Lukas M.]

Aber gut; das ist dann (teilweise) Sache der Kunden...

Ist zwar nervig, aber eben sauberer Mails über SMTP zu verschicken und seit Jahren eigentlich Standard.

Diese Veränderung... wo kommt die her? Also von GMAIL? Oder vom PHP-Mailer? Oder woher sonst?
Anders gefragt; kann ich das irgendwie beeinflussen?

Vom Versender. Ob das PHPMailer oder der Mailserver macht weiß ich gerade nicht.
Aber was willst du da beeinflussen? Das ist Standard nach RFC 1342.

[Micha M.]

Vom Versender. Ob das PHPMailer oder der Mailserver macht weiß ich gerade nicht.
Aber was willst du da beeinflussen? Das ist Standard nach RFC 1342.

Das ist Standard, dass der Betreff so vermurkst ist!? Wieso war er das bisher nicht? Und wieso ist er das nicht bei jedem Web dann?

[Lukas M.]

Das ist Standard, dass der Betreff so vermurkst ist!? Wieso war er das bisher nicht? Und wieso ist er das nicht bei jedem Web dann?

Ja, das ist Standard. RFC hatte ich dir ja gesagt.
Und ist nicht "vermurkst" sondern halt einfach entsprechend kodiert. Wie auch jeder Anhang in einer Mail in Base64 kodiert ist und nicht im Klartext.
Ich weiß nicht wie lange du Mails schon verschickst, aber hier ist halt ein Umlaut drin. "März". In "Februar" z.B. ist kein Umlaut drin.
Umlaute gehören halt nun mal nicht zum ASCII-Standard, der Betreff muss also kodiert werden.

[Micha M.]

Also bei mir kamen die bisher in korrekter Schreibweise an... jetzt sieht man diese Kodierung. Das mag ja sein, dass das im Mailheader so steht, aber im Betreff selbst? Das finde ich seltsam...