SQL Umlaute aus Datenbank nicht korrekt dargestellt

[Jesterfox]

Eigentlich dürfte es doch egal sein, was da steht, wenn die eigentliche Tabelle doch auf utf8_unicode_ci steht, oder?

Wie die Daten in der Tabelle gespeichert sind ist eine Sache... in welcher Codierung sie von der DB an die Anwendung weiter gegeben wird eine andere.

 

[Dsimon24]

Wie die Daten in der Tabelle gespeichert sind ist eine Sache... in welcher Codierung sie von der DB an die Anwendung weiter gegeben wird eine andere.

Verstehe. Also ist die Server-Zeichenkodierung die, wie die Daten an die App weitergegeben werden?

 

[Jesterfox]

Das nehme ich an. Das Problem ist das man diese Einstellung an den verschiedensten Stellen vorgeben und auch noch überschreiben kann.

 

[PHuV]

Verstehe. Also ist die Server-Zeichenkodierung die, wie die Daten an die App weitergegeben werden?

Jein, Das kommt darauf an, wer wie auf die Datenbank zugreift. An sich sollte jeder Client, der sich mit der Datenbank verbindet, eine entsprechend korrekte Konvertierung im Ziel kümmern. Wie der Server das speichert, ist eigentlich egal, wenn der Client weiß, wie die Daten auf dem Server vorliegen, und wie das Zielformat lokal lauten soll. Man sollte auf dem Server natürlich eine "besseren" und weiteren Zeichensatz verwendet, wie eben UTF8/UTF16, und die Clients können es dann nach lokalen Zeichensätzen wie Ansi und Co. umsetzen. Du kannst übrigens auch beim Export und Importieren der Datenbanktabellen Zeichensätze zum korrekten Konvertieren angeben.

https://www.24x7serversupport.com/b...database-with-correct-character-set-on-linux/

 

[EyeSeaTee]

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

Sorge lieber für durchgehend utf8, alles andere ist Gefrickel und Unfug!

 

[gymfan]

Sorge lieber für durchgehend utf8, alles andere ist Gefrickel und Unfug!

Das hängt halt vom Altbestand der Daten ab. Wenn man die Altdaten sowieso migrieren muss, kann man sie auch konvertieren.
Und dann bleibt natürlich zu beten., dass nicht in 2-3 Jahren MariaDB, PHP oder sonstwer auf UTF16 umsteigt.

Das Chaos hat man immer, wenn man nicht an jeder Stellen, an der man Daten liest oder schreibt, selber definiert, welche Kodierung man nutzen möchte.

Ich komme jedenfalls nicht auf die Idee, mal eben 120k Datensätze zu konvertieren weil mal wieder ein Update meint, die Standardkodierung ändern zu müssen. Da schreibe ich lieber die nächsten 100k Einträge auch noch mit Kodierung "latin1" (=cp1252) und gebe die Webseite mit dem passenden charset aus wenn ich weiss, dass mir dies auch weiterhin genügen wird.

 

[EyeSeaTee]

Ich komme jedenfalls nicht auf die Idee, mal eben 120k Datensätze zu konvertieren weil mal wieder ein Update meint,

Dann lebe weiter im letzten Jahrtausend!

Ich komme jedenfalls nicht auf die Idee, mal eben 120k Datensätze zu konvertieren weil mal wieder ein Update meint,

Suche dir ein anderen Beruf! Dringend!

 

[PHuV]

Ich komme jedenfalls nicht auf die Idee, mal eben 120k Datensätze zu konvertieren weil mal wieder ein Update meint, die Standardkodierung ändern zu müssen. Da schreibe ich lieber die nächsten 100k Einträge auch noch mit Kodierung "latin1" (=cp1252) und gebe die Webseite mit dem passenden charset aus wenn ich weiss, dass mir dies auch weiterhin genügen wird.

So eine Konvertierung kostet doch heute nix mehr? Ich verstehe das Problem hier nicht. Auf Arbeit konvertiere ich täglich permanent Daten in irgend einer Form per Scripte und anderen Möglichkeiten automatisiert von einem Datenbereich in einen anderen.

Wenn Du Deine Datenbank nicht gescheit aufbereitest, wirst Du die Probleme immer und immer weiter ziehen. Daher hat der Kollege schon recht, einmal die Daten gescheit aufbereitet, und man hat weniger Ärger.