nicht angemeldet
echo $begrüßung;
FIND_IN_SET( '1',
content\_offline.exlinks\_ids)
#1267 - Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation 'find_in_set'
Es sieht so aus, als ob für das Feld content\_offline.exlinks\_ids als Kodierung/Kollation latin1_swedish_ci eingestellt ist, die derzeitige Verbindung, über die das Statement abgesetzt wurde, auf utf8_general_ci steht. Für den String '1' wird die Kodierung/Kollation der Verbindung genommen, für das Feld die dafür eingestellte. Und nun gibt es damit ein Problem, weil MySQL Äpfel mit Birnen vergleichen soll, das aber nicht kann. (Da es mir leider nicht gelingt, den Fehler nachzustellen, bitte ich um die genaue Angabe der Server-Version (SELECT VERSION()) und des CREATE-Statements der Tabelle.)
Es empfiehlt sich, durchgehend mit der gleichen Kodierung zu arbeiten, weil sonst Datenverluste beim Umkodieren entstehen können (wenn die Ziel-Kodierung nicht alle Zeichen der Ausgagskodierung darstellen kann). Ebenfalls wichtig ist, dass alle Beteiligten genau wissen, welche Kodierung vorliegt und dann damit auch umgehen können.
Das mit den Schriftsätzen habe ich noch lange nicht verstanden ;(
Da fehlt erstmal grundlegendes Verständnis über die Darstellung von Zeichen in der elektronischen Datenverarbeitung. Grundlagen kannst du dir anlesen beispielsweise im SELFHTML-Kapitel Computer und geschriebene Sprache oder auch in jenem Forumsbeitrag von mir.
Seit Version 4.1 hat MySQL ein komplexes System der Kodierungen/Kollationen erhalten.
Die Kodierung ist zuständig, den Zeichen bestimmte (Byte-)Werte zuzuordnen, um sie computergerecht speichern und verarbeiten zu können. Eine Kollation gibt Vergleichsregeln an. Jede Sprache hat da mehr oder weniger ihre eigenen Regeln, manchmal auch mehrere (z.B. ß=ss oder ß=s).
In einem MySQL-Server gibt es (wenn ich richtig gezählt habe) 10 verschieden_artige_ Stellen [*], an denen eine Kodierung oder Kollation angegeben werden kann. Die wichtigsten sind die Angaben der einzelnen Felder, denn damit legt man fest, welche Zeichen gespeichert werden können. Beispielsweise lassen sich mit Latin1 keine griechischen Buchstaben abbilden. Nimmt man aber UTF-8 kann man praktisch alle Zeichen der Welt verwenden.
Es nützt aber nichts, diese Zeichen nur speichern zu können, man muss sie auch von und zum MySQL-Server transportieren können. Dafür sollte man für jede eröffnete Verbindung explizit eine Kodierung einstellen und sich nicht auf irgendwelche Server-Default-Werte verlassen. Mit dem Statement SET NAMES utf8 legt man UTF-8 als Kodierung für die Verbindung fest. MySQL erwartet dann alle Werte in Statements in UTF-8-Kodierung, und gibt alle Resultate UTF-8-kodiert an den Client zurück. Wenn für die Abfrage beteiligte Tabellenfelder eine andere Kodierung aufweisen, versucht MySQL selbständig umzukodieren. Das geht aber technisch bedingt nicht immer für alle Zeichen, nur für die, die in der Zielkodierung darstellbar sind. Die restlichen Zeichen gehen verloren.
Weniger wichtig sind die Kodierungs-/Kollationsangaben für Tabellen und Datenbanken, denn das sind nur Default-Werte, die verwendet werden, wenn für Felder keine explizite Angabe gemacht wurde. Die Default-Werte "vererben" sich in dieser Reihenfolge: Server-Defaultwert -> Datenbank-Defaultwert -> Tabellen->Defaultwert -> Feldkodierung.
[*] Alle Stellen zu finden lasse ich mal als Hausaufgabe (besonders für Tom) stehen :-)
Achja, das MySQL-Handbuch wurde die Tage erst umgestrickt, so dass das frühere Haupt-Kapitel Character Set Support nun ein Unterkapitel von Internationalization and Localization geworden ist. Trotzdem empfiehlt es sich, diese(s) Kapitel nicht unbeachtet zu lassen.
echo "$verabschiedung $name";