ABAKUS

Andreas I. hat geschrieben:PHP-Datei ist in utf-8.

Prinzipiell egal, wichtig ist, was das Skript ausgibt. Enthält das Skript reine Datenbereiche (außerhalb von <?php und ?>), dann sollten diese zwar in der vom Skript bzw. Server gemeldeten Kodierung vorliegen oder kompatibel sein (us-ascii und die jeweils ersten 128 Zeichen der iso-8859-Familienmitglieder sind kompatibel mit utf-8), beim eigentlichen PHP-Code kommt es aber immer darauf an, wie die auszugebenden Texte verarbeitet werden.

Tabelle in der Datenbank ist in utf-8.

Vollkommen egal. Die Zeichensätze der Tabelle bestimmen nur die Sortierung und die speicherbaren Zeichen. In welcher Kodierung die Datenbank die Zeichen liefert, ist alleine von der Verbindung abhängig, von nichts anderem, insbesondere nicht von den Tabellen- und Spaltenzeichensätzen, das kannst du im Grunde beliebig kombinieren (auch wenn es natürlich wenig sinnvoll ist, über eine Verbindung, die nur japanische Zeichen transportieren kann, Inhalte einer Tabelle senden zu wollen, die einen kyrillischen Zeichensatz nutzt und dementsprechend nur kyrillische Zeichen enthält).

Die Verbindungskodierung setzt du mit mysql_set_charset() und erfährst sie mit mysql_client_encoding() (mit einem kurzen Blick in die Funktionsübersicht hättest du das auch selbst herausgefunden).

PHPMyadmin wird in utf-8 angezeigt und die Daten sind korrekt

Das zeigt zwar, dass die Zeichen in der Datenbank richtig abgelegt sind (und nicht kaputtkodiert, wie es bei alten MySQL-Versionen vorkam bzw. selten auch nötig war), hat aber ansonsten nicht viel zu sagen.

Umlaute tauchen in der fertig gerenderten Seite durchaus auch in richtig dargestellter Art und Weise auf.
Es ist aber so, dass das PHP-Script mehrere Dateien includiert und am Ende läuft auf der fertigen Seite auch noch AJAX. (Gerade der AJAX-Teil funktioniert utf-8 mäßig nicht ganz richtig und arbeitet aber mit der Datenbank zusammen.)
Andere Teile der Scripts arbeiten auch mit der DB zusammen und geben die Daten korrekt formatiert aus.

Kläre erstmal, welche Teile richtig dargestellt werden (bzw. wo sie herkommen) und welche nicht. Dann kannst dir überlegen, wo da der Unterschied besteht. Es bringt nichts, wenn du im Seitenskript rumprobierst und der Fehler befindet sich in einem ganz anderen Skript, das sich um die Ajax-Sachen kümmert.

loest vielleicht ein
dein problem (ganz am anfang deiner seite)?

Habe jetzt alles auprobiert. Jede Einstellung auf utf-8 gesetzt, die nicht bei 3 auf den Bäumen ist und es funktioniert immer noch nicht.

Ich lasse in den diversen script-Teilen, die includiert werden, jetzt immer als HTML-Kommentar ausgeben: und entsprechend in den anderen Scripten. Tatsächlich wurde an einigen Stellen noch latin-1 verwendet. Das habe ich so korrigiert, dass jetzt überall in den HTML-Kommentar ausgegeben wird: "<!-- charset in config.inc.php: utf8 -->"

Einziger Verdächtiger ist jetzt noch jquery. Im generierten Quelltext ist zu sehen, dass irgendwie in jquery der Wurm drin ist. JavaScript-Kommentare werden falsch ausgegeben usw.

Na, mal sehen....

hast du deine einstellungen in der db auch genau ueberprueft? charset kann man in mysql per datenbank, per tabelle und per spalte festlegen; allerdings wird davon nix vererbt - soll heissen wenn ich bei tabellen optionen utf8/utf8_general_ci angebe kann es sein das die spalten trotzdem noch als latin behandelt werden.
versuch mal hast du die php header angabe versucht? damit sagst du dem browser explizit das der inhalt als utf-8 behandelt werden soll, das ist notwendig sobald du deine verbindung mit "SET NAMES UTF8" setzt...

nerd hat geschrieben:hast du deine einstellungen in der db auch genau ueberprueft? charset kann man in mysql per datenbank, per tabelle und per spalte festlegen

Neinneinneinneinneinundneien. Die Zeichensätze in Datenbank, Tabelle und Spalte haben nichts, nichts, nichts mit dem zu tun, was bei einer Abfrage geliefert wird.

hm was ist dann der unterschied oder zweck dieser einstellung? oder ist das nur fuer die sortierung wichtig...? 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...

oder anders gefragt: woher weiss mysql wie es die zeichen interpretieren soll wenn es irgendwas exotisches (umlaute oder asiatische schriftzeichen) in einer abfrage bekommt?

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.