SQL Umlaute aus Datenbank nicht korrekt dargestellt

[Dsimon24]

Hallo zusammen,

ich habe eine kleine PHP-Anwendung inkl. Datenbank-Anbindung und möchte ein paar Daten aus der Datenbank abrufen. Habe am Wochenende die Wep-App von einem Server (mit CentOS 8) auf einen neuen Server (mit Ubuntu 20.04) übertragen. Beide Server über Plesk administriert. Den Quellcode 1zu1 übertragen, die DB exportiert und importiert.

In beiden DB´s steht bspw. folgender Inhalt in einem Datensatz: Entstörung von Fernseh‑ und Internetanschlüssen

Auf dem alten Server wird es in der PHP-WebApp korrekt inkl. der Umlaute dargestellt. Auf dem neuen Server sieht es wie oben (also fehlerhaft) aus. Habt ihr eine Idee, woran es liegen könnte? Beide Server mit Plesk 18.0.40. Auf dem alten Server MariaDB 10.3.28 - auf dem neuen Server MariaDB 10.3.32 - alles jeweils in utf8_unicode_ci kodiert.

VG

 

[PHuV]

Das Problem tritt immer dann auf, wenn zwischen Client und Datenbank kein einheitlicher Zeichensatz eingestellt wurde. Daher hier mal die Quelldaten per SQL auschauen und ggf. korrigieren, so daß wieder korrektes utf8 vorliegt.

Ansonsten, das kennst Du?
https://www.pixelfriese.de/unterschied-zwischen-utf8_general_ci-und-utf8_unicode_ci/

 

[Madman1209]

Hi,

utf8 decode/encode schon mal versucht? Bei der Datenbankverbindung (welche überhaupt? PDO?) das Coding mit übergeben?

VG,
Mad

 

[DJMadMax]

Die Daten liegen ja hoffentlich nicht in dieser Form vor, sie werden offensichtlich nur so interpretiert, also von deiner Ausgabe so ausgelesen.

PS: @PHuV war schneller

 

[Dsimon24]

Habe utf8-decode/encode als erstes direkt getestet. Bei decode wird es noch unlesbarer, bei encode werden Vierecke mit einem Fragezeichen dargestellt - das ist es leider nicht.

In der Datenbank (PhpMyAdmin) liegen die Daten leider tatsächlich so vor, wie oben im Beispiel genannt. Sind über 15.500 Datensätze, die kann ich leider nicht alle ändern.

Merkwürdig ist nur, dass ich den Quellcode ja 1 zu 1 kopiert habe und die Datensätze in der Datenbank im alten und auf dem neuen Server beide identisch kodiert sind.

Ja, wird mittels PDO realisiert.

 

[hi-tech]

Wenn der Quellcode 1zu1 übertragen wurde, dann würde ich auf die Einstellung in Plesk tippen.

 

[Jesterfox]

Die Daten müsste so schon korrekt als utf8 in der Datenbank stehen, nur die Verbindung ist wohl auf was anderes eingestellt. Oder die Ausgabe als HTML wird mit einer falschen Codierung deklariert.

 

[hi-tech]

Schau mal vielleicht hilft dir das was Peter sagt weiter:
https://talk.plesk.com/threads/encoding-problem.360492/

Wenn Plesk neu augesetzt wurde könnte dort eine default Einstellung gesetzt sein.

 

[bog]

ist auch moeglich, dass bspw. in der php.ini zwischen host 1 und host 2 unterschiedliche default encodings stehen.

 

[RalphS]

Das ist ansi. Fehlerhaftes Unicode sieht anders aus.

 

[Dsimon24]

Plesk wurde tatsächlich aufgesetzt, aber alles, was ich auf Anhieb vergleichen kann, sieht in den Settings auch identisch aus. UTF8 ist in den HTML-Files auch hinterlegt.

Schau mal vielleicht hilft dir das was Peter sagt weiter:
https://talk.plesk.com/threads/encoding-problem.360492/

Wenn Plesk neu augesetzt wurde könnte dort eine default Einstellung gesetzt sein.

Die php.ini habe ich mal verglichen, da ist auch alles soweit identisch in diesem Bereich.

ist auch moeglich, dass bspw. in der php.ini zwischen host 1 und host 2 unterschiedliche default encodings stehen.

Das würde bedeutet, dass wir mit Unicode auf dem falschen Weg sind? - Oder wie kann ich mir das vorstellen?

Das ist ansi. Fehlerhaftes Unicode sieht anders aus.

 

[Jesterfox]

Es ist als ANSI ausgegebenes utf8. Passt auch zu der Aussage dass die Datenbank utf-8 enthält. Die Verbindung zur Datenbank dürfte wohl auch auf utf-8 laufen. Es wurde ja am Quelltext nichts geändert und ansonsten würde die DB das auch konvertieren.

Ich denk mal das Problem liegt in der angegeben Kodierung bei der Auslieferung des HTML. Also entweder php.ini oder Webservereinstellung.

 

[Dsimon24]

So, habe jetzt mal eine HTML-Datei heruntergeladen und von UTF8 über den Notepad++ in ANSI umgewandelt. In sofern ändert sich nicht die Ausgaben aus der Datenbank, die bleiben identisch. Im Gegenteil: Es werden andere Texte, die korrekte Umlaute haben, dann mit schwarzen Rauten mit einem Fragezeichen dargestellt.

EDIT:
Hab gerade noch was im Datenbank-Server gefunden.
Der alte hatte: Server-Zeichensatz: cp1252 West European (latin1)
Der neue hat: Server-Zeichensatz: UTF-8 Unicode (utf8mb4)

So steht es in der Übersicht n PhpMyAdmin.
Die einzelnen Tabellen haben utf8_unicode_ci.

Könnte es daran liegen?
- Kann man das irgendwie anpassen?

 

[Jesterfox]

Ja, das könnte der Grund sein, aber irgend was ist da trotzdem faul, weil eigentlich die alte Einstellung falsch war. Scheinbar wurde da aber nochmal irgend wo was konvertiert was jetzt auf die Füße fällt wenn überall utf-8 genutzt wird...

 

[Dsimon24]

Das kann gut sein. Kann ich denn irgendwie den Server-Zeichensatz auf cp1252 West European (latin1) stellen, damit das Problem erst einmal behoben ist? Gibt es da irgendwelche Möglichkeiten, ohne, die Tabellen ändern zu müssen?

 

[hi-tech]

https://mariadb.com/kb/en/setting-character-sets-and-collations/
etwas weiter unten die my.cnf configuration file vielleicht

 

[Dsimon24]

Schau ich mir mal an, danke dir. Aber mal zum Verständnis für mich... Eigentlich dürfte es doch egal sein, was da steht, wenn die eigentliche Tabelle doch auf utf8_unicode_ci steht, oder? - Oder könnte es dennoch das Problem sein?

cp1252 scheint es auch nicht zur Auswahl zu geben. Nur cp1250, cp1251 und dann geht´s erst mit cp1256 weiter...

 

[hi-tech]

Welche Auswahl? Denke die Datei kann man selbst editieren. Poste mal Screens damit man sieht wo du was änderst.

Egal ist vieles nicht, ist zwar etwas her als ich mit Web Apps zu tun hatte, aber grade bei der Zeichencodierung muss alles Hand in Hand gehen. Hatte mir damals auch regelmäßig Kopfzerbrechen verursacht und musste in allen Settings, config files pipapo richtig gesetzt sein.
Verstehe aber deinen Gedanken, nur wenn verschiedene Technologien miteinander sprechen / zusammenarbeiten um einen Datensatz darszustellen, leuchtet es schon ein dass der genutze Zeichensatz überall korrekt eingestellt sein muss.

 

[RalphS]

MySQL ist ein bißchen.... counter intuitiv.... was encodings angeht. Ja, da steht eine Codierung. Aber man kann eintragen, was man will. Gibt auch keine Fehler.

Es kann also buchstäblich sein, daß dasselbe Textfeld in einer Tabelle mal ein Unicode Ö hat und mal ein Ansi Ö.

Das macht autofix immer etwas schwierig. Du könntest dir zur Sicherheit die betreffenden Spalten angucken, je nach Inhalt kann man die vielleicht gruppieren oder sonst übersichtlich(er) gestalten.
Sonst riskierst Du am Ende 25% reparierte Einträge auf Kosten von vorher intakten und nun defekten 75% anderen Einträgen.

 

[gymfan]

Der alte hatte: Server-Zeichensatz: cp1252 West European (latin1)

Bei meiner eigenen Seite muss ich (mit PHP7) die Verbindung zur Datenbank auf 'latin1' konfigurieren
mysqli_set_charset($db, 'latin1');
damit meine vor vielen Jahren auch so (damals leider mit den Standrdwerten von PHP4 und MySQL) angelegte DB heute noch nutzbar ist.

Egal ist vieles nicht, ist zwar etwas her als ich mit Web Apps zu tun hatte, aber grade bei der Zeichencodierung muss alles Hand in Hand gehen.

Und man darf sich vor allem niemals auf irgendwelch Vorgaben der Datenbank, PHP oder dem Webserver verlassen sondern muss immer alles manuell setzen. Nicht nur PHP ändet garne mal seine Vorgaben bei einem Versionswechsel, wenn ihnen gerde so passt.