[la-finest]

HeyHo,

habe gerade das Problem, das meine Daten aus der DB, welche äöü enthalten diese nicht angezeigt werden sonder stattdessen eine Raute mit Fragezeichen (FF). Hab dann in meinen mysql Tabellen nachgeschaut und gemerkt, dass dort die Kollation aus welchem Grund auch immer auf latin1_swedish_ci steht. Habe es nun auf latin1_german2_ci umgestellt aber die laute werden immer noch nicht angzeigt. Habe dann gesehen, dass die Tabellen vom Kollation auf latin1_swedish_ci stehen. Kann ich das bei den Tabellen nachträglich ändern und warum ist sowas überhaupt voreingestellt?

Greetz,
la-finest

[Jann Hendrik]

Ist das nur der Fall, wenn du mit deiner eigenen Anwendung drauf zugreifst, oder ist das auch der Fall, wenn du mit phpmyAdmin die Daten betrachtest?

[sgmalex]

Probier mal:

latin1_general_ci

Das klappt bei mir auf jeden Fall.

[la-finest]

Ich hab im FF eingestellt unter Ansicht -> Zeichenkodierung -> Westlich ISO ...-1. Dann läuft es. Egal wo ich mir die Datenanzeigen lasse sind die Umlaute mit dabei. Nur bei diesem Script springt er mir von der Ansicht auf UTF-8 und zeigt mir keine Umlaute an, sogar wenn ich in den Metadaten ausdrücklich ISO angebe.

Vllt. werde ich eine parser Klasse bauen und dann äöü mit den HTML-Tags ersetzten. Aber ich denke das is dann relativ "Zeitintensiv" das Script.

Greetz,
la-finest

[Ben]

Zitat von la-finest

Habe dann gesehen, dass die Tabellen vom Kollation auf latin1_swedish_ci stehen.

Das ist die Standardeinstellung von phpMyAdmin, wenn ich das richtig im Kopf habe.

Eventuell hast du die Daten aus einer anderen Datenbank exportiert und dort aus Versehen als Kodierung UTF-8 angegeben?
Das Problem hatte ich nämlich erst gestern!

[Victorious]

Ich habe das Problem nun auch, aber bei mir ist alles auf latin1_german2_ci eingestellt in der DB. Wenn ich so Umlaute verwende werden die richtig angezeigt nur nicht aus der DB?So wohl lokal, wie auf dem webspace. Komischerweise lief auf meinen Webspace sonst alles gut. Aus den alten Tabellen kann ich noch umlaute darstellen lassen. Nur bei neuen Tabellen geht das nicht.(Webspace) Hab schon alles probiert, aber nix hat geholfen.

[MrNiceGuy]

Zitat von Ben

Das ist die Standardeinstellung von phpMyAdmin, wenn ich das richtig im Kopf habe.

Eventuell hast du die Daten aus einer anderen Datenbank exportiert und dort aus Versehen als Kodierung UTF-8 angegeben?
Das Problem hatte ich nämlich erst gestern!

Indeed! Leider ist es bei MySQL so, dass die Standard-Collation auf latin1_swedish_ci steht. Um dem Abhilfe zu schaffen muss man allerdings in der my.cnf (normalerweise unter /etc zu finden) lediglich im Bereich [mysqld] den Eintrag:

default-collation=latin1_german2_ci

hinzufügen. Wenn etwas anderes gewünscht ist (z.B. UTF-8 ), dann muss das eben entsprechend angepasst werden. Somit braucht man jedenfalls nicht mehr darauf achten, die richtige Collation beim Erstellen von Datenbanken/Tabellen auszuwählen.

Nur für den Fall, dass das hier noch nicht beantwortet wurde :
Um die Frage nochmal zu beantworten, ob das nachträglich umgestellt werden kann: Ja! In der Datenbank-Übersicht kannst du in PMA unter "Operationen" die Collation der DB ändern, ebenso in der Tabellen-Ansicht auch unter "Operation" und bei den Feldern eben durch bloßes Editieren.
Du musst allerdings bedenken, dass MySQL keine Konvertierung der Daten vornimmt, sondern die Daten, die vorhanden sind einfach beibehält und lediglich die Collation der Tabelle / des Feldes verändert. Es ist also durchaus möglich, dass die Umlaute hinterher immernoch falsch angezeigt werden.

Ein weiterer Punkt, der noch Beachtung finden sollte ist die Verbindung zwischen PHP und MySQL, diese kann nämlich auch in der Collation verändert werden! Die Collation der Verbindung sollte immer die gleiche sein, wie die Collation der Datenbank / Tabelle / Feld! Die Collation kann von PHP zur Laufzeit mittels mysql_set_charset() angepasst werden.

Achso, noch was: Ich glaube aber, dass es auch so ist, dass wenn ich eine Datenbank mit einer anderen als der Standard-Collation anlege, alle Tabellen und Felder in dieser Datenbank standardmäßig die Collation der Datenbank annehmen, statt wieder auf die Server-Einstellung zurück zu fallen. Das war auch mal eine Zeit lang anders. Allerdings weiß ich jetzt nicht, ob das eine Feature-Erweiterung von PMA oder MySQL direkt ist... Es ermöglicht jedefalls auf einfache Weise eine andere Collation zu verwenden, ohne bei jeder Tabelle und bei jedem Feld nochmal explizit drauf achten zu müssen.

[Victorious]

habs eingestellt gehabt das die collation auf latin1_german2_ci steht. Hat auch nix gebracht. Zeichensatz / Kollation der MySQL-Verbindung: das habe ich auf utf8 gestehlt, sowohl auch auf latin1_german2_ci, aber auch da keine abhilfe. Das einzige was geholfen hat war das hier mysql_set_charset().
Sonst nichts.

[MrNiceGuy]

Nachdem du die my.cnf editiert hast musst du natürlich den MySQL-Server neu starten, sonst wird das auch nichts. Prüfen kannst du das dann im PMA über die Systemvariablen, da darf dann bei der Collation kein swedish mehr stehen.

Aber dass du nun sagst, dass das mysql_set_charset() geholfen hat, stellt sich mir die Frage: Welche Teile deiner DB haben denn jetzt welche Collation und wann kommt es zu dem Problem mit den fehlerhaften Umlauten und wann nicht?

[Victorious]

Hab den SQL server neugestartet xD. Das Problem tritt überall auf, egal welche Tabelle und es haben wirklich alle die selbe Collation.
Hab sogar die DB gelöscht gehabt und neu angelegt, da ned so viel drin ist, da es eine test DB ist.Im Live System habe ich da nix gemacht, da ich da sowieso kein zugriff auf die configs habe.

Dachte auch erst es liegt daran wie ich die Datei abspeichere, aber auch daran liegt es nicht.In PMA wird auch alles korrekt angezeigt. Hab auch schon verschiede Browser ausprobiert bzw OS, aber alle das selbe Problem. Schon verrückt irgendwie.

[Basti]

Was soll denn die „Collation“ mit der Darstellung der Zeichen zu tun haben? „Collation“ ist einfach nur die Sortierfolge, also z.B. ob bei einem ORDER BY `name`der Herr Möller vor dem Herrn Muh kommt oder danach.

Jedes Zeichen wird in deiner Datenbank sozusagen durch eine Zahl repräsentiert. Welche Zahl hier welchem Zeichen zugeordnet wird, hängt davon ab, welchen Zeichensatz du verwendest. Die ersten 128 „Zeichen“ sind bei praktisch allen Zeichensätzen identisch. Das ist der ASCII-Zeichsetz, dem z.B. alle Buchstaben des englischen Alphabets, die Ziffern, die „gewöhlichen“ Satzzeichen etc. angehören.

Bei allen übrigen Zeichen, wie z.B. den deutschen Umlauten, den Anführungsstrichen oder dem Gedankenstrich ist der Zeichensatz relevant. Wenn du eine Raute und ein Fragezeichen siehst, dann scheint es so, als ob du die Zeichen in UTF-8 kodiert hast (dort werden Zeichen nämlich auch in mehreren Bytes abgebildet), sie aber z.B. als Latin-1-Zeichen interpretierst (ISO-8859-1), oder mit diesen Windows Codepage-Sätzen. Kann aber natürlich auch sein, dass die Zeichen vorher falsch umgewandelt wurden.

Am geschicktesten ist, dein komplettes System auf einen Zeichensatz festzulegen, z.B. UTF-8. Probleme sind dabei die Schnittstellen mit anderen Systemen, z.B. den E-Mail-Programmen der Benutzer des Systems, die oft noch kein UTF-8 verstehen und daher Latin-1-Zeichen brauchen.

Dazu musst du nun jede Seite, die du an den Browser schickst in UTF-8 kodieren und diese Info mit angeben. Dazu reicht ein Meta-Tag nicht, du musst auch explizit den entsprechenden Header mitsenden. Damit wedern auch alle Eingaben, die ein Benutzer in ein Formular macht automatisch in UTF-8 kodiert. Auf dem Server musst du dann auch berücksichtigen, das du Multybyte-Funktionen anwendest, z.B. um die Länge einer Zeichenkette herauszufinden (ab PHP 6 wird sich das ändern).

Die Datenbank stellst du auch auf UTF-8 und dann kann eigentlich nichts schief gehen.

Konkret also nochmal:

Zum Client:

header('Content-Type: text/html; charset=utf-8');
<?xml version="1.0" encoding="UTF-8" ?>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Zur Datenbank:

CHARACTER SET utf8 COLLATE utf8_general_ci
SET NAMES 'utf8'

Bastian

[MrNiceGuy]

Die Collation hat - neben der Aufgabe der Sortierung - auch die Aufgabe den Zeichensatz anzugeben. Wird also statt latin1 utf8 verwendet, werden die Sonderzeichen nicht richtig dargestellt. Ebenso kann dies der Fall sein, wenn Zeichensätze verwendet werden, in denen kein ä, ö oder ü vorkommt.

[Basti]

Zitat von MrNiceGuy

Die Collation hat - neben der Aufgabe der Sortierung - auch die Aufgabe den Zeichensatz anzugeben.

Nein. Es ist nur so, dass der Zeichensatz entsprechend der Collation ausgewählt wird, falls dieser nicht explizit gesetzt wurde. Aber das ist auch schon der einzige Zusammenhang (soweit ich weiß).

Bastian

[MrNiceGuy]

Ich konnte das Phänomen bei einer Datenbank (utf8_general_ci) in einer Tabelle (utf8_general_ci) in einer Spalte (latin1_german2_ci) beobachten, dass die Zeichen eben auch falsch formatiert waren. Nachdem die Spalte auch auf utf8_general_ci geändert wurde (und alle in ihr enthaltenen Daten konvertiert wurden) ging es dann. Deswegen vermute ich, dass neben dem Charset eben auch die Collation verantwortlich für den entsprechenden Zeichensatz ist. Sonst würde es in meinen Augen auch keinen Sinn machen den Zeichensatz in der Collation mit drin stehen zu haben (Beispiel: latin1_swedish_ci statt einfach nur swedish_ci)!?

[Basti]

Zitat von MrNiceGuy

Ich konnte das Phänomen bei einer Datenbank (utf8_general_ci) in einer Tabelle (utf8_general_ci) in einer Spalte (latin1_german2_ci) beobachten, dass die Zeichen eben auch falsch formatiert waren. Nachdem die Spalte auch auf utf8_general_ci geändert wurde (und alle in ihr enthaltenen Daten konvertiert wurden) ging es dann.

Laut Dokumentation müsste das auch genau so sein, solange du keinen Wert für den Zeichensatz der Spalte angibst. In dem Fall wird der eben nach der Sortierfolge eingestellt.

Ich kanns aber grad nicht reproduzieren.

Sonst würde es in meinen Augen auch keinen Sinn machen den Zeichensatz in der Collation mit drin stehen zu haben (Beispiel: latin1_swedish_ci statt einfach nur swedish_ci)!?

Intern musst du ja eh pro Kombination eine eigene Tabelle führen, also werden die eben auch entsprechend benannt. Das macht schon Sinn.

Bastian