Hello,

Das mit den Schriftsätzen habe ich noch lange nicht verstanden ;(

Schriftsätze gibt's, glaube ich, beim Rechtsanwalt...
Aber verstanden habe ich genau diese Sache bei MySQL auch noch nicht.
Hatte ich gestern nämlich auch und viiiile viele Andere im Web auch. Und die Lösungsansätze scheinen alle falsch zu sein. Nur irgendwann heute Nacht dachte ich dann: Was 30mal falsch im Web steht (und kein einziges Mal richtig), das könnte ja vielleicht soch zutreffend sein und _ich_ bin derjenige, der es verkehrt versteht...

Es war aber trotzdem falsch, auch wenn ich frustiert anfing zu glauben, was da sooft beschreiben stand...

Und nachher hatte ich soviel im Kreis rum geändert, dass sich das Problem von alleine gelöst hat - oder?

siehe https://forum.selfhtml.org/?t=162572&m=1057987

Wäre als ganz klasse, wenn sich nochmal jemand dieses Phänomens annehmen könnte.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)

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";

Hallo Tom, hallo Dedlfix,

vorab 1000 Dank für die sehr gut erklärten, für mich dennoch
erschlagenden bg-Infos zum Thema Schriftsätze. Mir ist bewusst,
dass ich mich da nochmal reinsteigern muss, wenn ich gaaaaanz
ausgeglichen bin ;)

Das Problem hatte ich in diesem Projekt zum ersten Mal. Angefangen
hat alles mit einem Metatag in dem 'charset=utf-8' steht. Zum
Problem wurde es, als nachdem ich endlich meine Entwicklung auf den Live-Server übertragen habe, nicht ein Sonderzeichen mehr richtig
dargestellt wurde und sich dann herausstellte, dass der DB-Server
sich grundlegend von dem meiner Entwicklungsumgebung unterschied,
nämlich < MySQL 4.1 war.

Mit euerer Hilfe hab ich das alles so hingebogen bekommen, dass
es funktionierte und ich glaube ich habe zu dem Zeitpunkt sogar,
ein verschwommenes Bild davon gehabt, was da das Thema ist.

Was, wenn ich die Zusammenhänge richtig verstehe, jetzt zum Problem führt, ist folgender Umstand:

In meiner Datenbank (> MySQL 4.1) sind Daten, die aus einem Dump
der Live-Datenbank (< MySQL 4.1) stammen. Ich habe versucht, dass
SQL-Statement, dass zum Fehler führt, mit PHPmyAdmin abzusetzen.
Ich kann mir vorstellen, dass die Verbindung, die PHP mit MySQL
unter meinem PHPMyAdmin herstellt, von UTF8 ausgeht.

Ich werde mal versuchen, das Statement direkt auf dem Liveserver
abzusetzen.

beste gruesse,
martin