Hallo,

lang ist es her... und nun bin ich wieder da, mit einer neuen Frage die mich quält.
Diesmal geht es um das Thema Zeichensätze; Im Streit liegen hierbei die drei großen Parteien Browser, PHP und MySQL.
Ich will nun wissen wem von den Dreien ich vertrauen kann, und welcher mich ärgert, sprich: Wer hat Schuld das die Zeichen nicht ordenlich dagestellt werden?

BROWSER:
Ich habe ein Gästebuch gebastelt. Das Gästebuch ist mit überlicherweise (X)HTML erstellt.
Dem zu Folge gibt es auch die Metatags:

<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=UTF-8"/>

Der Browser (Firefox3) switcht auch wunderbar in die Zeichenkodierung utf-8.
Zusätzlich ist im form-Tag das accept-charset="utf-8" vermerkt.

Eine Sache habe ich bemerkt: Switche ich in einen Zeichensatz des Typs ISO-8859
werden die vorher falsch angezeigten Daten richtig angezeigt. Jedoch sollten die Daten in der MySQL Tabelle den Zeichensatz utf-8 zugrunde liegen haben, da:

MYSQL:
Der Tabelle, in welcher die Gästebucheinträge geführt werden habe ich die Kollation utf8_general_ci zugewiesen.
Ich weiß das eine Kollation kein Zeichensatz ist, sondern mehr mit der Sortierung der Daten zutun hat.
Allerdings setzt eine Kollation einen Zeichensatz voraus; bei dem es sich bei diesem Namen her eigentlich um utf8 handeln sollte.
Ich habe nichts an der Konfiguration von MySQL verändert. Es ist jenes MySQL welches Bestandteil des XAMPP 1.7(Linux) ist.
Da man aber viele unterschiedliche Kollationen und damit auch mehrere Zeichensätze auswählen kann, sollte doch die MySQL eigene Konfiguration hier keine Rolle spielen, oder? Ich meine MySQL ist doch eigentlich dafür da, Daten mit unterschiedlichsten Eigenschaften wie etwa Zeichensätze zu verwalten-

Trage ich über phpMyAdmin Umlaute in die Tabelle ein, werden diese auch korrekt wieder ausgegeben. Demnach kann phpMyAdmin also genau das, was auch meine Gästebuch beherrschen soll.

PHP
Mit PHP lese ich die Daten aus der MySQL- Tabelle über eine übliche SELECT-FROM- Anweisung aus. Diese werden in einer Schleife von der Funktion fetchobject() in ein Objekt gepackt und anschließend ausgelesen.
Füge ich die Funktion utf8_encode beim auslesen der Daten ein, werden diese richtig dargestellt, nur wieso brauche ich diese Funktion wenn ich weiß das die Daten in der MySQL-Tabelle utf8- kodiert sind? Wenn etwas bereits utf8-Kodiert ist muss ich es doch nicht in utf8 kodieren um es korrekt darzustellen, oder???
Schicke ich das Formular ab sollten die Daten ja eigentlich durch die Angabe accept-charset="utf-8" utf8-kodiert an php ankommen.
Sende ich die Daten zur Datenbank, zeigt phpMyAdmin Umlaute nicht korrekt an.
Sende ich die Daten mit der Funktion utf8_decode an die Datenbank, zeigt phpMyAdmin Umlaute wieder korrekt an.
Jedoch gibt es dann wieder das Problem mit dem auslesen, wie oben beschrieben.
Ich habe mal gelesen das php für interne Berechnungen und derlei Dinge selber einen ISO-8859 Zeichensatz verwendet. Hat das Auswirkungen auf einen vermeintlichen utf8-kodierten String den man an php schickt und intern verarbeitet, wie etwa Sonderzeichen maskieren?
Wäre dem so, käme ich ja um die beiden Funktionen welche utf8 betreffen nicht herum.

Der Browser befindet sich unter Ansicht->Zeichenkodierung zu 100% im utf8 Modus.
Diese Headersache habe ich auch ausprobiert, jedoch ergebnislos.

Verwenden Sie Funktionen wie utf8_decode oder utf8_encode ?

ich habe mir zwei Klassen gebaut, die eine nutzt MySQL und die andere MySQLi

Derzeit übernehmen die normalen MySQL- Funktionen die Datenbankverwaltung.

Im PHP- Quellcode nutze ich NICHT die Funktionen utf8_de- und utf8_encode
Das tue ich nicht weil ich die Daten via HTML Formular als utf8 versende, zumindest nehme ich das an, da ja unter Ansicht->Zeichenkodierung UTF8 eingestellt ist.

Würde ich die Funktionen verwenden, habe ich festgestellt das dies das bewirkt was ich auch haben will, nur versteh ich dann den zusammenhang nicht..

stimmt! mit der Funktion mb_detect_encoding krieg ich bei meinen POST- Daten ASCII raus.
Das heißt ich verschicke die garnicht als utf-8-

Ehrlich gesagt verwirrt mich das jetzt doch etwas, so habe ich doch im <form>- Tag accept-charset="utf-8" gesetzt.
Ebenso ist auch die Seitenkodierung auf utf-8 gesetzt.

Das alles hat wohl überhaupt keine Auswirkung auf die Formulardaten? Die kommen wohl immer nur als ASCII an?
Wenn dem so ist ist die Lösung ja einfach: Einfach die POST Daten utf8 kodieren.

So das funktioniert, hätte nicht gedacht das, dass so einfach ist, aber naja, wieder was dazu gelernt- das ist die Hauptsache. Ich Danke dir Xaos! :-)

jetzt gibts aber wieder ein kleines Problemchen, nämlich beim auslesen der Daten.
Bemerkenswert ist jetzt folgendes:
Ist der Browser auf utf-8 gestellt zeigt er Daten wie ö,ä,ü mit einem � an. Die Daten sind utf-8 kodiert, das sag auch die Funktio mb_detect_encoding.
Stell ich den Browser nun aber auf ISO-8859-1, so zeigt er mir die utf-8 kodierten Daten korrekt an. Sowohl im Firefox als auch im Opera.

Kodiere ich die utf-8 kodierten Daten mit utf8_encode nach utf8 so ist die Anzeige der Umlaute wieder korrekt.
Warum aber muss ich einen utf8 kodierten String nach utf8 kodieren damit er korrekt angezeigt wird? *confused*
Das ist doch doppelt gemoppelt, oder?

Ob ich den String nun kodiere oder nicht, mb_detect_encoding sagt mir in beiden Fällen der String ist utf-8 kodiert.


default output header
Damit meinst du doch bestimmt die Angabe header('Content-Type: text/html; charset=UTF-8'); ?
die ist gesetzt.

Ach du Allerheiliger...

Jetzt gehts! Was macht diese Datenbankabfrage?
ich meine, meine Datenbank und Tabellen sind doch schon utf8 kodiert; wieso brauch ich da sowas?

LOL, diese eine Anweisung löst all meine Probleme: Ein- wie Ausgabe!!!!

DANKESCHÖN!!!!