nicht angemeldet
Hi!
Wenn A auf Englisch eingestellt ist, B aber deutsch redet, wessen Problem ist es dann? A's, weil er von B nicht mitgeteilt bekommt, dass die Daten deutsch sind, oder B's, weil er falsche Daten von A bekommt?
Ähm -super. Erklär mir bitte, wie ein Problem nicht datenbankseitig sein soll, wenn auf immer gleiche Abfragen für gewisse Rows die Ausgabe wunderschön geschieht, bei anderen (immer gleichen) aber Zeichenfehler auftreten? Dann muss dies doch gezwungenermasse an fehlender "Zeichenkodierungskonsistenz" auf Seite der DB liegen.
Entsprechende Felder präsentieren sich übrigens auch in phpMyAdmin mit ?, während dies andere nicht tun...
Eine Erklärung wäre, um ein Beispiel ähnlich dem obigen zu verwenden, wenn A mit dem DBMS englisch spricht, und dies auch ordnungsgemäß jedes Mal mitteilt. Das DBMS weiß nun über die Sprache des Textes Bescheid und kann ihn ordentlich in andere Sprachen übersetzen, wenn diese von irgendjemandem angefordert werden. Wenn B nun allerdings ständig deutsch redet, aber dem DBMS dies nicht mitteilt, geht das DBMS von seiner Default-Einstellung englisch aus und bekommt nun ein Problem beim Interpretieren und übersetzen in andere Sprachen.
Ein Mischmasch tritt dann auf, wenn A und B an der selben Tabelle arbeiten. Dann sind einmal die Daten aus A-Sicht richtig, und ein anderes Mal aus B-Sicht. Wieso sind aber B's deutsche Daten richtig, wenn B sie abfragt, obwohl die Verbindungskodierung auf englisch steht und das DBMS intern Übersetzungen zwischen Verbindung und Feld vornimmt? Nun, in dem Fall hinkt das Beispiel. Mit Zeichenkodierungen ist das in gewissen Konstellationen zwar ohne Datenverlust möglich, jedenfalls wenn B allein arbeitet. Eine Möglichkeit wäre: B sendet UTF-8 (ä=C3A4), MySQL denkt Latin1 (C3=Ã,A4=¤), interpretiert jedes Byte der UTF-8-Bytesequenz eines Zeichens als jeweils eigenes Zeichen und umkodiert das nach UTF-8 (Ã=C383,¤=C2A4) zur Ablage in den Feldern. Auf dem Rückweg zu B wird das wieder nach Latin1 zurückkodiert (C383(UTF-8-Ã)=>C3(Latin1-Ã),C2A4(UTF-8-¤)=>A4(Latin1-¤)), B denkt, es sei UTF-8 (C3A4=ä), und alles scheint richtig. Dass etwas falsch läuft, sieht man erst mit A (bekommt UTF-8: C383=Ã,C2A4=¤ => ä) oder wenn man Sortieren möchte, oder mit CHAR_LENGTH() seitens MySQL die Anzahl der Zeichen zählen will.
Danke für den Link, da steht genau was ich gesagt habe: "Sie kann auch nachträglich geändert werden, wobei die bereits enthaltenen Daten umcodiert werden. "
Das betrifft den Fall, dass Daten in Feldern stehen und die Feldkodierung geändert wird. Dann werden die darin stehenden Daten umkodiert. Das kann natürlich nur dann fehlerfrei stattfinden, wenn zum einen die Daten "damals" beim Einlesen richtig interpretiert werden konnten, jetzt also richtig kodiert abgelegt sind, und zum anderen mit der Zielkodierung alles Zeichen kodiert werden können.
Lo!