nerd hat geschrieben:ist das nur fuer die sortierung wichtig...?
Die Kodierungseinstellung bei Datenbank, Tabelle und Spalte bestimmt die Sortierung und den Umfang der speicherbaren Zeichen. Kann die Tabelle bzw. die Kodierung nur kyrillische Zeichen, kannst du keine arabischen reinschreiben. Oder …
ich hatte jedenfalls immer mal probleme mit "kaputten" zeichen beobachtet wenn leute osteuropaeische zeichen in eine db geschieben haben die mit default charset (latin_1/...) lief...
Latin1 hat keine osteuropäischen Zeichen. In einer Tabelle, die nur westeuropäische Zeichen kennt, osteuropäische Zeichen speichern zu wollen, ist, als wenn du versuchst, einen eckigen Bauklotz ins runde Loch zu kloppen. Daher die (tatsächlich oder vermeintlich) kaputten Zeichen – garbage in, garbage out.
Zwar lässt sich zB das Byte 205 eines osteuropäischen Zeichens in einer westeuropäischen Tabelle speichern, Byte ist Byte, nur behandelt die Tabelle dieses Byte 205 dann halt als westeuropäisches Zeichen. Das geht solange gut, wie die aus der Tabelle gelesenen Bytes von einer Anwendung verarbeitet werden, die auf die falsche Kodierungsangabe gefasst ist.
Wechselt man zu einer anderen Anwendung, zum Beispiel um mit phpmyadmin irgendwas manuell nachzugucken, zeigt diese Anwendung natürlich kaputte Zeichen, denn laut Tabelleinformation sollen die Bytes ja als westliche Zeichen interpretiert werden.
woher weiss mysql wie es die zeichen interpretieren soll wenn es irgendwas exotisches (umlaute oder asiatische schriftzeichen) in einer abfrage bekommt?
Weil für die Verbindung eine eigene Kodierung gilt, nur deswegen benutzt du doch SET NAMES (die zu bevorzugenden PHP-Funktionen hatte ich oben schon genannt). Mit dieser Anweisung erzählst du MySQL, in welcher Kodierung du deine Bytes schickst bzw. empfangen möchtest.
Die Umsetzung Verbindung/Tabelle übernimmt MySQL für dich. Du kannst dich ohne weiteres mit MySQL in Latin1 unterhalten, während du in einer Unicode-Tabelle arbeitest (oder auch umgekehrt). Einzige Einschränkung ist dann natürlich, dass über die Verbindung nicht alle Zeichen transportiert werden können, die in der Datenbank stehen, sondern nur diejenigen, die die Verbindung zulässt. Diese kommen dann aber auch korrekt an, ein ö bleibt ein ö, egal aus welcher Tabelle es kommt – man muss es nur richtig reinschreiben.
Siehe auch
Verbindungszeichensatz in der MySQL-Anleitung.