AJAX - Datenübergabe und deren Codierung

[Skyman]

Hallo Leute,

nicht gleich meckern, ich weiß, es gibt schon etliche Threads zur Datencodierung etc.

Aber keines davon bringt mich weiter und irgendwie weiß ich derzeit nicht, was ich wirklcih falsch mache oder was ich wie codieren und decodieren soll.

Standardproblem: AJAX-Routine übergibt Datenstring an den Server zu einer PHP Datei und irgendwie passt es mit den deutschen Umlauten nicht, was sich jedoch komischerweise wie folgt äußert:

Ein <input type="text"...> - Feld für den User, der gibt da fleißig Namen ein.
Dieser Feld-Value wird bei onkeyup mal eben per Request an den Server abgesetzt, so weit so gut, klappt prima. Folgende Codierung wurde hierbei als AJAX Standard für "POST" gesetzt:
http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
Der übergebene URI wurde zuvor nicht mit Javascript codiert, also kein encodeURI() für die Datenfolge ausgeführt.

Alles klappt prima, bis man auf die Idee mit Umlauten kommt. Aber was jetzt wie umcodieren?
Denn das Problem ist, das ich nicht weiß, was die PHP Datei auf dem Server nicht versteht?
Denn es ist so, gebe ich einfach mal den String aus den $_POST Variablen aus bzw. sende diesen zurück, dann steht nach Eingabe von "Bäume" im Textfeld auch hinterher "Bäume" in $_POST['textfeld'], also wäre doch eigentlich alles ok, oder wie?
Ich kann encodeURI() benutzen oder nicht, völlig egal.

Die PHP Datei bringt mir den Inhalt immer richtig zurück, damit arbeiten kann sie aber wohl nicht, denn SQL-Aufrufe enden Erfolglos.

Ich kann ja zum Test die PHP Datei direkt im Browser aufrufen, dann liefert sie korrekte Ergebnisse, auch wenn ich Umlaute im Browser eingebe, werden die "gleichen" (denn so gleich können sie ja nicht sein) Daten mittels der AJAX Routine gesendet, dann gibts wieder nur Murks.

NUR, was hat der Server für Daten bekommen? Wie gesagt, lasse ich den angeblichen Inhalt der gesendeten Daten zurückschicken, dann steht alles korrekt drin mit Umlaut, also was hat der Server für andere Buchstaben erhalten als ich hinterher auf dem Bildschirm?

Ich bin ein wenig ratlos und hoffe ihr könnt mir helfen, sofern ihr mich jetzt überhaupt verstanden habt...?!?! ich hoffe doch... ;-)

Gruß
Skyman

[globe]

n'abend,

http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
Der übergebene URI wurde zuvor nicht mit Javascript codiert, also kein encodeURI() für die Datenfolge ausgeführt.

wieso erzählst du dem Server du würdest ihm urlencoded-te Daten senden, wenn du das gar nicht machst?

weiterhin schönen abend...

[Skyman]

n'abend,

http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
Der übergebene URI wurde zuvor nicht mit Javascript codiert, also kein encodeURI() für die Datenfolge ausgeführt.

wieso erzählst du dem Server du würdest ihm urlencoded-te Daten senden, wenn du das gar nicht machst?

weiterhin schönen abend...

Ja sicher schon richtig, aber wie ich weiter geschrieben habe hab ich es ja auch mit encodeURI() probiert, der Effekt war ja kein besserer, das ist ja das Problem.

Also, jetzt wird der gesamte URL-Strin mittels encodeURI() codiert, dann dürfte auch der Content-Type des Requests richtig sein. Jetzt lasse ich zum Test einfach mal alle zugewiesenen $_POST Werte ausgeben und sogar den SQL-Query String. In BEIDEN Ausgaben liefert der Server das Wort z.B. "Bäume" korrekt wieder, also sollte man davon ausgehen, das er "ä" auch verstanden hat, hat er aber nicht!!!!!!
Die SQL Anfrage liefert KEINE Ergebnisse zurück.

Gehe ich jetzt von der Webseite aus, das <input..>-Feld ist ja ein Form-Feld und starte die Submit Funktion wird der gleiche String ja auch mittels "POST" zum Server geschickt und liefert auch korrekte Ergebnisse.
Deshalb bin ich ja so verwundert. Auch der oben erwähnte SQL-String hat das "ä" drin und mittels drag&drop vom Bildschirm ins phpMyAdmin geschoben liefert es korrekte Ergebnisse.
Ich verstehe die Welt nicht mehr, echt...

Gruß
Skyman

[globe]

n'abend,

Ich verstehe die Welt nicht mehr, echt...

na dann wirds wohl am Charset liegen. Dazu hat sich dedlfix bereits geäußert

weiterhin schönen abend...

[dedlfix]

echo $begrüßung;

nicht gleich meckern, ich weiß, es gibt schon etliche Threads zur Datencodierung etc.

Das Thema ist ein recht komplexes, weil du mehrere Komponenten hast, die alle zusammenspielen müssen, damit es keinen Datensalat gibt. Da gibt es den Browser, Javascript, AJAX, PHP und noch die Datenbank, und alle müssen genau instruiert werden, welche Kodierung sie zu erwarten haben, und dann auch noch in der Lage sein, damit umgehen zu können.

Aber keines davon bringt mich weiter und irgendwie weiß ich derzeit nicht, was ich wirklcih falsch mache oder was ich wie codieren und decodieren soll.

Da heißt es zuerst einmal zu ermitteln, welche Kodierungen vorliegen und welche erwartet werden. Außerdem wird sicher noch das Wissen benötigt, wie man von der einen Kodierung zur anderen kommt, wenn zwei Komponenten unterschiedlich arbeiten oder eingestellt sind.

Standardproblem: AJAX-Routine übergibt Datenstring an den Server zu einer PHP Datei und irgendwie passt es mit den deutschen Umlauten nicht, was sich jedoch komischerweise wie folgt äußert:

Du hast also ein Problem mit der Zeichenkodierung.

http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );

Diese Angabe hat nichts mit der Zeichenkodierung zu tun sondern mit der Art, wie die Formulardaten im Allgemeinen zusammengestellt werden.

Alles klappt prima, bis man auf die Idee mit Umlauten kommt. Aber was jetzt wie umcodieren?

Im Prinzip gar nichts. Und schon gar nicht, ohne zu analysieren, was genau schief läuft.

Denn das Problem ist, das ich nicht weiß, was die PHP Datei auf dem Server nicht versteht?

Doch zuvor solltest du dir die Grundlagen der Kodierung von Zeichen im Allgemeinen anschauen und insbesondere dich über die Zeichensätze/Kodierungen ISO 8859-1/Windows1252 (hierzulande recht gebräuchlich) und Unicode/UTF-8 informieren.

Denn es ist so, gebe ich einfach mal den String aus den $_POST Variablen aus bzw. sende diesen zurück, dann steht nach Eingabe von "Bäume" im Textfeld auch hinterher "Bäume" in $_POST['textfeld'], also wäre doch eigentlich alles ok, oder wie?

Wenn alles ordentlich aussieht, dann machen alle beteiligten Komponenten alles richtg, beziehungsweise reichen alles einfach nur durch, ohne sich um die Daten zu kümmern.

Die PHP Datei bringt mir den Inhalt immer richtig zurück, damit arbeiten kann sie aber wohl nicht, denn SQL-Aufrufe enden Erfolglos.

Wie ermittelst du, dass die SQL-Aufrufe erfolglos enden? Fragst du Fehlermeldungen ab oder ignorierst du sie und merkst nur am Ergebnis, dass das was nicht hinhaut?

Ich kann ja zum Test die PHP Datei direkt im Browser aufrufen, dann liefert sie korrekte Ergebnisse, auch wenn ich Umlaute im Browser eingebe, werden die "gleichen" (denn so gleich können sie ja nicht sein) Daten mittels der AJAX Routine gesendet, dann gibts wieder nur Murks.

In welcher Kodierung erhält der Browser die Daten? Welche Kodierung verwendet die AJAX-Routine standardmäßig? Lässt sich das umschalten? Oder lassen sich alle anderen Beteiligten zur Verwendung der gleichen Kodierung wie die AJAX-Routine überreden?

Vermutlich wird AJAX UTF-8 verwenden. Wie du aus dem oben empfohlenen Grundlagenstudium hoffentlich erkannt hast, ist UTF-8 eine gute Wahl, da sich damit so gut wie alle möglichen und unmöglichen Schriftzeichen dieses Planeten kodieren lassen. Dumm nur ist, dass meist noch von ISO 8859-1 ausgegangen wird, und dass einige Beteiligten (PHP vor Version 6, MySQL vor Version 4.1) ganz oder teilweise nicht mit UTF-8 umgehen können.

NUR, was hat der Server für Daten bekommen?

Er hat vermutlich Kodierung A erhalten und versucht sie mit Kodierung B zu entschlüsseln, was nicht bei allen Zeichen funktioniert.

Ich bin ein wenig ratlos und hoffe ihr könnt mir helfen, sofern ihr mich jetzt überhaupt verstanden habt...?!?! ich hoffe doch... ;-)

Ja, aber ich befürchte, dass nun nur noch mehr Sorgenfalten auf deiner Stirn aufgetaucht sind. Außerdem habe ich auch nicht alle Punkte angesprochen, auf die es zu achten gilt. Doch als Grundlage zur weiteren Forschung deinerseits sollte es erstmal reichen. Den Rest sehen wir später ...

echo "$verabschiedung $name";

[Skyman]

Ja, aber ich befürchte, dass nun nur noch mehr Sorgenfalten auf deiner Stirn aufgetaucht sind. Außerdem habe ich auch nicht alle Punkte angesprochen, auf die es zu achten gilt. Doch als Grundlage zur weiteren Forschung deinerseits sollte es erstmal reichen. Den Rest sehen wir später ...

echo "$verabschiedung $name";

EBEN, leider... :-)  :-(

Also, ich gebe echt zu das ich kein Codierungsexperte bin. Jetzt ist die Frage, was du z.B. wissen musst um mir zu helfen.
Ich werde mir gleich mal deine Codierseite ansehen, aber zuvor versuche ich noch zu beschreiben, was ich alles an Codierungen gefunden habe, ich weiß nicht was wo wie Einfluß nimmt:

Die Webseite selber:
<meta name="Content-Type" content="text/html; charset=iso-8859-1">

Jetzt mal was neues probiert, der Request Content der AJAX Routine:
http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded; charset:iso-8859-1' );

Die aufgrufene PHP Datei codiert mal nichts und bastelt nur ein wenig HTML mit Daten zusammen, die dann zurück kommen sollen.

ABER vielleicht hilft dir genau da etwas weiter:
Ich bin mal hingegangen und habe der eigentlich per POST übergebenen Suchvariablen in dem PHP Script einfach mal einen festen Wert zugewiesen um zu sehen was das Script macht.
Jetzt wirds lustig:
ich habe festgelegt: $s_name = "bäumer";
Dann habe ich mir mal den gebastelten SQL String per echo zurückgeben lassen und auf einmal macht er aus dem Variableninhalt folgendes: "b?er"
Was ist da jetzt passiert? Da spielt doch irgendeine Codierung mit, oder? Aber welche und wie?

Wie ich merke, das der SQL Aufruf keine Ergebnisse liefert? Nun, wenn der Aufruf mysql_query($sql_string) FALSE zurück liefert, war das wohl nix...

...wie gesagt, $sql_string mit echo auf Browser ausgeben lassen ist alles ok.

Bitte Hilfe...
...jetzt guck ich mir die Seite an, die du genannt hattest.

Gruß
Skyman

[dedlfix]

echo $begrüßung;

Die Webseite selber:
<meta name="Content-Type" content="text/html; charset=iso-8859-1">

Das sagt dem Browser, dass die Zeichen dieses Dokuments gemäß ISO 8859-1 kodiert sind. Ein A ist beispielsweise durch den Wert 65, ein Ä durch 196 und umgekehrt, sollte der Wert 196 durch ein Ä dargestellt werden. Mit UTF-8 werden Zeichen jenseits von ASCII (lateinische Buchstaben, Ziffern und ein paar Satzzeichen) mit 2 bis 4 Bytes kodiert. Interpretiert man nun diese Bytes gemäß ISO 8859-1, sieht man entsprechend 2 bis 4 Zeichen. Die Bytes eines UTF-8-Zeichens müssen bestimmten Regeln entsprechen. Nicht jede Bytekombination ist also zulässig. Ein in ISO 8859-1 kodierter Text enthält bei Verwendung von Umlauten solche unzulässigen Bytefolgen, was dann mit einem Fragezeichen und ggf. dem Verlust nachfolgender Zeichen quittiert wird, bis wieder eine erlaubte Bytereihenfolge auftaucht.

Die Angabe in diesem Meta-Element ist aber nur ein Ersatzwert. Wenn in den HTTP-Headern ebenfalls eine charset-Angabe im Content-Type steht, so hat diese Vorrang. HTTP-Header kann man sich beispielsweise mit der livehttpheaders-Extension des Firefox anzeigen lassen.

Jetzt mal was neues probiert, der Request Content der AJAX Routine:
http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded; charset:iso-8859-1' );

Ich bin mir nicht sicher, ob das so erlaubt ist. Wobei ich mir aber sicher bin: Es wird keine Wirkung auf die Kodierung der Zeichen haben. Es reicht nicht, auf einen Umschlag "100 Euro" zu schreiben, dadurch füllt er sich nicht automatisch. setRequestHeader() wird eine allgemeine Methode sein, um jede Art von HTTP-Header zu setzen. Sie wird den zu setzenden Inhalt nicht auswerten und danach handeln. Wenn du dem http_request sagen möchtest, in welcher Kodierung es die Daten versenden soll, wirst du eine eigens dafür vorgesehene Methode aufrufen müssen.

Ich bin mal hingegangen und habe der eigentlich per POST übergebenen Suchvariablen in dem PHP Script einfach mal einen festen Wert zugewiesen um zu sehen was das Script macht.
ich habe festgelegt: $s_name = "bäumer";

In welcher Kodierung liegt dein Script vor und damit besagter Wert?

Dann habe ich mir mal den gebastelten SQL String per echo zurückgeben lassen und auf einmal macht er aus dem Variableninhalt folgendes: "b?er"
Was ist da jetzt passiert? Da spielt doch irgendeine Codierung mit, oder? Aber welche und wie?

Welche Kodierung, nimmt der Browser, an hätten deine Daten?
(Firefox: Rechtsklick->Seiteninformationen anzeigen; oder im Menü Ansicht unter Zeichenkodierung nachsehen, welche markiert ist. Wähle einen anderen Wert aus. Wenn die Umlaute dann richtig dargestellt werden, liegen die Daten in dieser Kodierung vor (oder diese Kodierung passt zufälligerweise auch auf die Testdaten).

Wie ich merke, das der SQL Aufruf keine Ergebnisse liefert? Nun, wenn der Aufruf mysql_query($sql_string) FALSE zurück liefert, war das wohl nix...

Gut. Den Rückgabewert der mysql_*-Funktionen auszuwerten ist immer eine gute Idee. Aber was sagt mysql_error() dazu?

Und weiter geht's mit einer wichtigen Komponente. Unter welcher Version läuft dein MySQL-Server? 4.0 und kleiner oder 4.1 und größer? Bis Version 4.0 konnte MySQL noch nicht mit UTF-8 umgehen. In Version 4.1 wurde dem Thema Zeichenkodierung besondere Aufmerksamkeit geschenkt. Man kann nun an sehr vielen Stellen angeben, welche Kodierung für diese Stellen verwendet werden soll. Um nur zwei zu nennen: Für jedes Feld kann eine andere Kodierung verwendet werden, selbst jedes String-Literal kann in einer anderen Kodierung notiert werden. Und damit der Server die Bytes richtig dekodieren kann, und gegebenenfalls in andere Kodierungen wandeln kann, muss er genau wissen, welche Kodierung vorliegt. Für dich ist momentan wichtig, welche Kodierung zur Kommunikation mit dem Client (dein PHP-Script) verwendet werden soll. Diese stellt man am besten mit einem expliziten "SET NAMES ..."-Statement, welches man direkt nach dem Connect sendet, auf einen definierten Wert ein. Damit interpretiert der Server die ankommenden Daten gemäß dieser Kodierung und gibt die Ergebnisse ebenfalls in dieser Kodierung zurück. Wenn für die Felder in den Tabellen andere Kodierungswerte eingestellt sind, nimmt der Server automatisch Umwandlungen vor. Dabei kann es auch prinzipbedingt zu Verlusten kommen, wenn sich Zeichen nicht mit der Zielkodierung darstellen lassen. (Auch deswegen ist die durchgehende Verwendung von UTF-8 eine gute Idee.)

echo "$verabschiedung $name";

[Skyman]

echo $begrüßung;

Die Webseite selber:
<meta name="Content-Type" content="text/html; charset=iso-8859-1">

Danke erstmal für deine ausführlichen Antworten.
Allerdings wächst mir das ja schon fast wieder aus den Ohren raus, solche Probleme mit den Codierungen hatte ich ja noch nie.

Ich denke der META Tag in der Ausgangsseite ist also zu vernachlässigen, ok?

Jetzt mal was neues probiert, der Request Content der AJAX Routine:
http_request.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded; charset:iso-8859-1' );

Ich bin mir nicht sicher, ob das so erlaubt ist.

Ich bin mir auch nicht sicher, aber habe es schon in einigen Demo-Scripten gesehen, was ja nun auch nichts heißen muß, aber man klammert sich ja an jeden Strohhalm.
Aber deine Erklärung dazu ist natürlich einleuchtend, aber es hätte ja sein können...

Ich bin mal hingegangen und habe der eigentlich per POST übergebenen Suchvariablen in dem PHP Script einfach mal einen festen Wert zugewiesen um zu sehen was das Script macht.
ich habe festgelegt: $s_name = "bäumer";

In welcher Kodierung liegt dein Script vor und damit besagter Wert?

Nun, das Script, elches die Datenbankabfrage startet ruft erstmal gar keinen Code Befehl auf. Die mittles POST reinkommenden Variablen werden genutzt um die mysql_query Abfrage zu starten und die erhaltenen Daten mit ein bißchen HTML drumherum per echo zurückzusenden, damit sie dann mittels innerHTML in ein div Objekt eingefügt werden, mehr nicht.

Dann habe ich mir mal den gebastelten SQL String per echo zurückgeben lassen und auf einmal macht er aus dem Variableninhalt folgendes: "b?er"
Was ist da jetzt passiert? Da spielt doch irgendeine Codierung mit, oder? Aber welche und wie?

Welche Kodierung, nimmt der Browser, an hätten deine Daten?
(Firefox: Rechtsklick->Seiteninformationen anzeigen; oder im Menü Ansicht unter Zeichenkodierung nachsehen, welche markiert ist. Wähle einen anderen Wert aus. Wenn die Umlaute dann richtig dargestellt werden, liegen die Daten in dieser Kodierung vor (oder diese Kodierung passt zufälligerweise auch auf die Testdaten).

Also mein IE Browser hier steht auf UNI-Code UTF-8 und links-nach-rechts Ausgabe, also standard denke ich mir.

Wie ich merke, das der SQL Aufruf keine Ergebnisse liefert? Nun, wenn der Aufruf mysql_query($sql_string) FALSE zurück liefert, war das wohl nix...

Gut. Den Rückgabewert der mysql_*-Funktionen auszuwerten ist immer eine gute Idee. Aber was sagt mysql_error() dazu?

Und weiter geht's mit einer wichtigen Komponente. Unter welcher Version läuft dein MySQL-Server? 4.0 und kleiner oder 4.1 und größer? Bis Version 4.0 konnte MySQL noch nicht mit UTF-8 umgehen. In Version 4.1 wurde dem Thema Zeichenkodierung besondere Aufmerksamkeit geschenkt. Man kann nun an sehr vielen Stellen angeben, welche Kodierung für diese Stellen verwendet werden soll.

Au mein Gott, wem sagst du das, ich dachte, ich platze...
MySQL läuft auf unserem Server 4.1.13 und der codiert wirklich jeden Furtz...
Wir haben eigentlich alles auf standard gelassen bzw. Latin-1 glaub ich als Standard vorgegeben, dann hatte er beim Import aus dem alten Server damals auch alle Umlaute richtig mitgenommen.
Die Kollationen sind in allen Tabellen gleich und alle Abfragen funktionieren ja auch mit den Umlauten, nur AJAX stellt sich jetzt quer.

So allmählich bin ich geneigt unsaubere Maßnahmen zu ergreifen und alle Umlaute vor dem absenden einfach in "ae" und ähnlichem umzuwandeln und in der PHP Routine wieder zurück, bevor ich mir hier einen heißen suche.
Dazu müßte ich aber den passenden Jvascript regular-expression hinbekommen, wo das nächste Problem wäre...

...ich heule echt ab, PHP ist so schön, warum ist Javascript dann so kompliziert? Ok, nur für mich... :-(

Gruß
Skyman

[dedlfix]

echo $begrüßung;

Danke erstmal für deine ausführlichen Antworten.
Allerdings wächst mir das ja schon fast wieder aus den Ohren raus, solche Probleme mit den Codierungen hatte ich ja noch nie.

Wenn alle Systeme die gleiche Kodierung verwenden, gibt es da auch keine.

Ich denke der META Tag in der Ausgangsseite ist also zu vernachlässigen, ok?

Nur dann, wenn es in den HTTP-Headern eine charset-Angabe in der Content-Type-Zeile gibt. Bei lokal gespeicherten Webseiten gibt es keine HTTP-Übertragung und dann ist diese Meta-Angabe nicht ganz unwichtig, wenn man auf richtig angezeigte Zeichen Wert legt :-)

ich habe festgelegt: $s_name = "bäumer";
In welcher Kodierung liegt dein Script vor und damit besagter Wert?
Nun, das Script, elches die Datenbankabfrage startet ruft erstmal gar keinen Code Befehl auf.

Die Kodierung des Scripts legst du im Editor beim Abspeichern fest. Wenn der Editor da keine Möglichkeit anbietet, wird es die Defaulteinstellung des Systems sein: Windows1252 (weitgehend ISO 8859-1-kompatibel).

Dann habe ich mir mal den gebastelten SQL String per echo zurückgeben lassen und auf einmal macht er aus dem Variableninhalt folgendes: "b?er"
Also mein IE Browser hier steht auf UNI-Code UTF-8 und links-nach-rechts Ausgabe, also standard denke ich mir.

Das passt zu dem angezeigten Fragezeichen. Ein nach ISO 8859-1 kodiertes Umlautzeichen ist eine ungültige UTF-8-Sequenz.

Und weiter geht's mit einer wichtigen Komponente. Unter welcher Version läuft dein MySQL-Server? [...]
Au mein Gott, wem sagst du das, ich dachte, ich platze...

Ruhig Blut, es wird nichts so heiß gegessen wie es gekocht wird.
Es ist zwar wichtig zu wissen, wo MySQL überall mit Zeichenkodierungen hantiert, für die praktische Arbeit ist aber eigentlich nur das passende "SET NAMES ..." nach dem Connect wichtig.

MySQL läuft auf unserem Server 4.1.13 und der codiert wirklich jeden Furtz...
Wir haben eigentlich alles auf standard gelassen bzw. Latin-1 glaub ich als Standard vorgegeben, dann hatte er beim Import aus dem alten Server damals auch alle Umlaute richtig mitgenommen.

Wichtig ist, dass du zur Kommunikation mit dem Server selbigem mitteilst, welche Kodierung zu verwenden sei und alles wird gut. Wenn der phpMyAdmin alles richtig anzeigt, sind deine Daten in Ordnung.

Die Kollationen sind in allen Tabellen gleich und alle Abfragen funktionieren ja auch mit den Umlauten, nur AJAX stellt sich jetzt quer.

AJAX arbeitet mit XML, da ist UTF-8 die Standard-Kodierung. Es wäre ratsam, wenn du alle Beteiligten auf die Verwendung von UTF-8 umstellst.

So allmählich bin ich geneigt unsaubere Maßnahmen zu ergreifen und alle Umlaute vor dem absenden einfach in "ae" und ähnlichem umzuwandeln und in der PHP Routine wieder zurück, bevor ich mir hier einen heißen suche.

Wer wird denn gleich. Damit tauschst nur das eine Problem gegen ein anderes aus. Und was machst du, wenn Javascript ausgeschaltet ist?

Nehmen wir mal an, du möchtest durchgehend UTF-8 verwenden. Das setzt voraus, dass du mit PHP kaum Stringverarbeitung machen möchtest, da diese Funktionen noch nicht fähig sind, mit Mehrbyte-Zeichenkodierungen richtig umzugehen. ein strlen('Müller') liefert 7 zurück, weil das ü aus zwei Bytes besteht, und auch substr() schneidet an den falschen Stellen. Wenn du solcher Art Stringverarbeitung nicht machst, sondern die Werte einfach nur durchreichst, musst du dir um PHP keine großen Sorgen machen.

Die Daten in der Datenbank werden günstigerweise auch UTF-8-kodiert gespeichert. MySQL nimmt zwar Umwandlungen vor, wenn die Connection mit UTF-8 läuft und die Felder auf latin1 eingestellt sind, aber mit 256 möglichen Werten ist latin1 doch recht begrenzt. Nimm dir den phpMyAdmin und wähle die Datenbank aus. Stelle dort unter "Operationen" den Wert für "Kollation" auf utf8_general_ci oder utf8_unicode_ci um. Der Unterschied zwischen beiden Werten ist im Handbuch-Kapitel Unicode Character Sets beschrieben. Für die Tabellen kannst du analog verfahren. Bei den Feldern sind nur die String-Felder zu berücksichtigen, also die bei denen in der Übersicht in der Spalte Kollation ein Wert eingetragen ist. Wenn du diese Angabe änderst, wandelt MySQL die gespeicherten Werte in die neue Kodierung um.

Nach einem Datenbank-Connect sendest du ein "SET NAMES utf8" und bekommst die Werte UTF-8-kodiert ausgeliefert. Natürlich musst du nun auch UTF-8-kodierte Werte senden.

Deine Scripte und sonstwo herkommenden Texte müssen auch UTF-8-kodiert gespeichert werden. Zur Not musst du die Daten mit utf8_encode() umwandeln, wenn die Quellen unbedingt ISO 8859-1 bleiben müssen. Den Browsern sendest du die charset-Angabe im HTTP-Header und im Meta-Element. Ein accept-charset-Attribut in den Form-Elemente sollte dem Browser letzte Zweifel beim Kodieren der zurückgesendeten Daten nehmen. Für noch schwerwiegendere Fälle gibt es einen Lösungsvorschlag auf den MySQL-Seiten im Artikel Unicode and Other Funny Characters.

echo "$verabschiedung $name";

[Skyman]

Ich nochmal,

also nochmal zu dem MySQL Server Einstellungen:
Language generell: German (de-utf-8)
MySQL-Zeichensatz allgemein: UTF-8 Unicode
Kollation der SQL Verbindung: utf8_general_ci

Funktioniert mit der normalen Kommunikation zwischen Webseite und Datenbank optimal bis jetzt...

Der Hammer ist ja:
Rufe ich irgendeine Tabelle auf zeigt er für die Textfelder:
Kollation: latin1_swedish_ci  <- ja ne iss klar.

Weiß nicht was das soll, aber da alles funzt habe ich mir darüber auch keinen Kopf gemacht.

Ich glaube auch nicht das es die Datenbank selber ist, denn bei der Datenbankabfrage wird ja schon der String kein "ä" mehr enthalten sondern irgendein Sonderzeichen, das ABER bei der Rückgabe durch das echo wieder richtig codiert wird, sonst stünde es ja nicht wieder als "ä" auf der Webseite, oder?
Also nur die Kommunikation zwischen dem internen Stringinhalt in der PHP Seite und das was der SQL-Server bekommt ist irgendwie daneben.

Ach menno....

[dedlfix]

echo $begrüßung;

also nochmal zu dem MySQL Server Einstellungen:
Language generell: German (de-utf-8)
MySQL-Zeichensatz allgemein: UTF-8 Unicode
Kollation der SQL Verbindung: utf8_general_ci

Das sind die Einstellungen, die nur den phpMyAdmin betreffen. Dieser benutzt zur Kommunikation mit dem Server utf-8 (letzte Zeile). Da man diesen Wert pro Session einstellen kann, gelten für andere Clients möglicherweise andere Default-Werte.
Schau lieber nach, was unter "MySQL-System-Variablen anzeigen" für "globale Werte" bei den "character set *"-Einstellungen stehen. Wenn du nichts anderes festlegst gelten nämlich diese Werte.

Funktioniert mit der normalen Kommunikation zwischen Webseite und Datenbank optimal bis jetzt...

Glück gehabt. Manche bemerken, dass sie da Wissensdefizite haben, wenn die Daten bereits verloren sind, sprich: nur mit menschlicher Intelligenz und Handarbeit wieder rekonstruiert werden können.

Rufe ich irgendeine Tabelle auf zeigt er für die Textfelder:
Kollation: latin1_swedish_ci  <- ja ne iss klar.

Der Wert ist wie folgt aufgebaut: Zuerst kommt der verwendete Zeichensatz bzw. die Zeichenkodierung (wird im Handbuch immer als charset bezeichnet). Der zweite Wert gibt die Kollation an (collation). Schwedisch ist die Default-Einstellung. Warum auch nicht, MySQL AB ist ein schwedisches Unternehmen. Die Bedeutung von ci weiß ich nicht, die war bei mir bisher noch nicht wichtig.
Die Kollation sagt aus, wie Sortierungen und Vergleiche vorgenommen werden. Dass da schwedisch sortiert wird, fällt hierzulande bei der Sortierung von ü auf.
Für die Datenübertragung zwischen Client und Server spielt die Kollation keine große Rolle, da kommt es hauptsächlich auf den richtigen charset-Wert an.

Also nur die Kommunikation zwischen dem internen Stringinhalt in der PHP Seite und das was der SQL-Server bekommt ist irgendwie daneben.

Wir bekommen das schon hin ...

echo "$verabschiedung $name";

[Felix Riesterer]

Lieber Skyman,

ich erinnere mich, dass beim XMLHttpRequest die Serverantwort mit folgendem Header an den Browser gesendet werden muss, sonst macht z.B. der IE Zicken:
"Content-Type: text/xml; charset=utf-8"

Das könnte umgekehrt bedeuten, dass Du _grundsätzlich_ alle Datenübertragungen über dieses XMLHttpRequest-Gedönse über UTF-8 regeln solltest, um genau diesen ärgerlichen Unterschieden in den Zeichenkodierungen aus dem Weg zu gehen.

Wenn Deine Datenbank die jeweiligen Daten im ISO-8859-1 Format abgespeichert hat, dann kannst Du die Zeichenketten vor dem Abfragen oder Abspeichern in das ISO-8859-1 Format konvertieren. PHP hat dazu zwei sinnvolle Funktionen:
utf8_encode und utf8_decode

Hoffentlich löst das Dein Problem...

Liebe Grüße aus Ellwangen,

Felix Riesterer.