Unklarheiten mit Umlauten Collation usw

[Karli1969]

Hallo zusammen,

wenn ich in phpMyAdmin eine MySQL Tabelle anlege und auch dort Daten eingebe, die Umlaute enthalten, dann werden die Daten in phpMyAdmin korrekt angezeigt.

Erstelle ich eine php-generierte HTML-Tabelle mit charset=UTF-8 mit den Daten, dann werden die Umlaute falsch dargestellt.
Sende ich in einem Formular mit charset=UTF-8 Daten an die Tabelle und lasse sie nachher in meinem eigenen HTML-Formular anzeigen, sind die Umlaute korrekt, aber in der Datenbank stehen sie falsch.

Ich habe schon vieles versucht.
Die Daten werden entweder immer in phpMyAdmin korrekt angezeigt und in meinem Formular falsch, oder umgekehrt.
Ich habe auch schon Versuche mit Kollation in phpMyAdmin gemacht. Also z.B. die varchar-Spalten mit Kollation UTF8-general-ci und auch mit Latin1-german2-ci versucht. Auch habe ich UTF8-general-ci in der Datenbank im Reiter Operationen/Kollation ausgewählt. Es Hilft alles nichts.

Gibt es noch weitere Stellen, wo ich irgendwas einstellen muss, dass mir die Umlaute sowohl in phpMyAdmin, als auch in meinen eigenen Formularen und eigenen HTML-Tabellen die Umlaute korrekt dargestellt werden?
Und am besten auch so, dass das Sortieren auch richtig funktioniert mit den Umlauten.

Danke schon mal für eure Hinweise
und
viele Grüße
Karl

 

[akretschmer]

Du erwartest zu viel. Zumindest von MySQL You got what you paid for. Und ja: PMA ist Müll. So wie auch MySQL. Viel Spaß noch damit.

 

[Karli1969]

Danke für deine Antwort. Ich fürchte, mein 6,99€-1&1 Server kann nichts anderes als mySQL, und selbst damit kann ich glaube ich noch froh sein.

Bedeutet deine Antwort, dass es bei PMA und MySQL nicht geht, dass sowohl hier wie dort die Umlaute richtig dargestellt werden?
Wenn ich weiß, dass das so ist, dann könnte ich notfalls damit leben. Dann würde ich es eben so machen, dass meine Ein- und Ausgabeformulare die Daten korrekt darstellen. In PMA mache ich mit meinen Daten ja eh nichts. Wäre halt nur schön gewesen.

Aber dann wäre da noch das Problem mit der Sortierung der Umlaute.
Ich habe in meiner Abfrage schon versucht collate und UTF8-general_ci einzubauen.

SELECT * FROM test order by varcharSpalte COLLATE utf8_general_ci ASC

Hat die Sortierung aber in keinster Weise beeinflusst.

 

[akretschmer]

Keine Ahnung, TBH. Ich nutze den Krams nicht. Aber MySQL und Umlaute: das ist eine ewig währende Hassliebe, seit zig Jahren. Das paßt einfach ned zusammen. Und PMA ist seit ewig langer Zeit als Sammelbecken von Bugs bekannt. Google ist voll mit Opferberichten. Werd glücklich damit - oder auch nicht. Dein Problem.

 

[Karli1969]

Hört sich aber gar nicht gut an.

Trotzdem Danke für die Info.

 

[akretschmer]

Danke für das Like. Macht mich ja fast etwas betroffen jetzt, nach meinen, ähm, harschen Worten.

Der Punkt ist: MySQL prüft nix. Es prüft nicht die Daten, die es bekommt. Du kannst sagen: das soll in Charset XYZ sein - es wird MySQL egal sein. Du kannst sagen: das ist ein INT, der soll nicht größer als 100 sein (Check-Constraint) - MySQL sagt zwar okay, kümmert sich aber einen Dreck drum. Du kannst sagen: diese Spalte ist ein DATE, Du kannst aber lustig einen 31. Februar eingeben. All das kann man beliebig fortsetzen. MySQL ist das Windows unter den Datenbanken.

 

[Karli1969]

Ich like ja nicht den etwas enttäuschenden Inhalt deiner Antworten, sondern dass du mir überhaupt geantwortet hast und dass du mir ein bisschen die Augen geöffnet hast, dass ich nicht zu viel erwarten darf. Ich dachte, mySQL wäre zwar beschränkt, aber die vorhandenen Funktionen wären ausgereift. Und wenn mal was nicht klappen würde, dann müsste es an mir liegen.

 

[akretschmer]

Da muß ich Dich von einem Irrtum retten. MySQL ist so beschränkt, daß selbst ein Anfänger da schnell an die Grenzen kommt. Und es ist auch nicht Anfängerfreundlich, im Gegenteil. Zum Beispiel reagiert es teilweise auf syntaktische Fehler nicht, wie man es erwarten sollte, mit einer Fehlermeldung. Sondern es liefert putzmunter ein Resultat aus. Meist ein falsches. Das ist gerade für Anfänger fatal. Ich spiele hier darauf an, daß in Abfragen mit Aggregationen alle Spalten im Resultat entweder aggregiert oder gruppiert sein MÜSSEN. In MySQL kann man diese (logische) Regel brechen, ohne einen Fehler zu bekommen, man bekommt ein Ergebniss. Welches falsch sein kann. Und oft auch dies ist. Quasi Zufall. Sowas will man eher nicht, und sowas ist für Anfänger eher schlecht. Ganz schlecht.

Why PostgreSQL is better than MySQL |

Übrigens: MySQL akzeptiert Check-Constraints. That's all. Real geprüft werden sie dann nicht. *facepalm*

 

[Karli1969]

Ui! Dass das so lückenhaft ist, hätte ich wirklich nicht vermutet. Falls 1&1 keine Alternativen anbietet, arbeite ich trotzdem erst mal mit mySQL weiter. Weil so im Groben hat es meine Bedürfnisse doch bisher immer erfüllt.