Zeichensatz der Datenbankverbindung anzeigen lassen?

Beitrag von **Andreas I.** » 09.03.2010, 23:56

Hallo, wieder mal ein utf-8 Problem...

Wie kann ich mir unter PHP anzeigen lassen, welchen Zeichensatz die gerade aktuelle Verbindung nutzt?

Hintergrund:
Sonderzeichen werden falsch dargestellt.
PHP-Datei ist in utf-8.
Tabelle in der Datenbank ist in utf-8.
PHPMyadmin wird in utf-8 angezeigt und die Daten sind korrekt
Gerenderte Datei im Browser wird in utf-8 angezeigt und die Daten sind kaputt.
Ich schreibe zu Anfang:

Code: Alles auswählen

$link = mysql_connect&#40;$sqlserver,$sqluser,$sqlpwd&#41;;
mysql_query&#40;"SET NAMES 'utf8'",$link&#41;;

Und nun will ich wissen:
Hat MySQL es gerafft, dass ich utf-8 Daten will? (scheinbar nicht...)
In welcher Sprache unterhalten sich PHP & MySQL eigentlich gerade? Kisuaheli? Altgriechisch?

Also ich will schreiben:
echo "";[/code]

von **Anzeige von ABAKUS** »

Beitrag von **800XE** » 10.03.2010, 00:45

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

ist im HTML(Template) auch irgendwo üöäß
ich denke mal "nein" weil ich denke das die dann auch "kaputt" wären
ich denke deine Datei wird vom Apach in ISO-xxxx-1 ausgeliefert

und ich denke, das Apach "seine" Zeichenkodierung ans PHP gibt und PHP das dann an SQL
meine Seiten sind laut http-Header(nicht html-Meta) in iso-xxx-1 und irgendwo hab ich utf-8 SQLs und es funktioniert .... ohne das ich extra irgendwelche Zeichensatzbefehle an SQL gebe

welchen Charset hast du im http-Header (der hat höhere Priorität als der im html-Meta)
www.chegu.de/AWT/HTTP-Header.html
ähm, an den Host wo ich eben gedacht habe, da hab ich garkein Charset im http-Header ... war aber glaub mal

Beitrag von **Andreas I.** » 10.03.2010, 10:42

Laut live http-headers wird beides akzeptiert:
...
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html, */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
...

Also ISO-8859-1 und utf-8 gleichermaßen. Aber das sagt ja nichts aus, was nun tatsächlich versendet wird.

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.

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **Mork vom Ork** » 10.03.2010, 11:25

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.

Beitrag von **nerd** » 11.03.2010, 01:08

loest vielleicht ein

Code: Alles auswählen

header&#40;"Content-type&#58; text/html; charset=utf-8"&#41;;

dein problem (ganz am anfang deiner seite)?

Beitrag von **Andreas I.** » 11.03.2010, 11:53

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:

Code: Alles auswählen

echo"<!-- charset in ajax_proxy.php&#58; ".mysql_client_encoding&#40;$link&#41;." -->";

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

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....

Beitrag von **nerd** » 11.03.2010, 21:48

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

Code: Alles auswählen

show full columns from TABELLE

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...

Beitrag von **Mork vom Ork** » 11.03.2010, 22:20

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.

Beitrag von **nerd** » 11.03.2010, 23:59

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?

Beitrag von **Mork vom Ork** » 12.03.2010, 09:54

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.

Beitrag von **Bauchladen** » 12.03.2010, 10:05

Code: Alles auswählen


utf8_decode&#40; .. &#41;
utf8_encode&#40;. . &#41;