Umlaute in MySQL Tabelle werden als benannte Zeichen ausgege

Hallo,

ich habe eine PHP-Datei mit der ich Text in eine Tabelle eingebe, so wie er geschrieben wird. Inklusive Umlaute sowie eine weiter PHP-Datei wo ich diesen Text editieren kann.
(insert into…mysql_real_escape_string($_POST[‘text’])
in der Tabelle steht der Text dann auch genau so.
Wenn ich die PHP-Datei aufrufe in der der Text aus der MySQL Tabelle ausgelesen wird war alles richtig.

Jetzt kommt das Problem, ich habe einen neuen Rechner bekommen, habe XAMPP für Windows installiert, die gleiche Version, MYSQL auch, habe die alte Datenbank exportiert und auf den anderen Rechner eingelesen sowie alle PHP Dateien.

Rufe ich jetzt Datei auf, welche den Text ausgibt habe ich anstatt Ö Ö oder anstatt Ä Ä usw.
Das Kuriose dabei ist, in der Tabelle steht es richtig. also Ä anstatt Ä
In der Datei zum editieren steht es auch richtig.
Führe ich ein Update durch (ohne das ich am Text was ändere) ist es auch in der Ausgabe Datei richtig.

Wie gesagt, ich habe nix verändert, bin nur von einem zum anderen Rechner umgezogen.

Seltsam, woran kann das liegen?
Besten Dank
GD

hi,

also bei der ausgabe werden die umlaute abgeändert, nachdem du sie durch die escape-funktion geschickt hast? im prinzip macht die funktion alles genau richtig, denn umlaute sollte man nie unmaskiert ausgeben. ansonsten, wenn du sie wirklich wieder in ä, ö, ü haben möchtest, müsstest du sie einzeln wieder zurückändern. ich kenne keine funktion, die das automatisch macht.

lg

Unsinn.

Man sollte viel eher eine Kodierung verwenden, die die benoetigten Zeichen darstellen kann.

hast du vllt einen aufruf von htmlentities() dazwischen? nimm stattdessen htmlspecialchars().
Sonst:

de2.php.net/manual/de/function.h … decode.php

Hallo,

das ich nicht so viel Ahnung habe, dass habe ich ja schon erwähnt.

Kurz zum insert.
Hochkomma doppelte und einfache können nicht übergeben werden, dass habe ich ausgeschlossen.
Die Daten werden, wie erwähnt mit mysql_real_escape_string($_POST[‘textfeld’] in die DB eingetragen.

Ich wolle die Werte so in der DB haben wie eingetragen werden. Ist doch leichter beim durchsuchen.

Ich habe auch kein htmlentities benutzt.

Wie gesagt, auf dem alten Rechner ist alles richtig, nur auf dem Neuen Rechner nicht.
Kann das am Zeichensatz von PHP Xammp liegen?

Danke Guckst Du

Die Zeichenkodierung, in der die Seite und damit das Formular ausgeliefert werden, koennte auch relevant sein. Wenn eine verwendet wird, in der Sonderzeichen nicht darstellbar sind, dann senden manche Browser diese in Formulareingaben schon als Entities oder nummerische Zeichenreferenzen an den Server.

Aber irgendwie ist das hier alles Herumstochern in einem Heuhaufen im Nebel …
Da braeuchte es schon konkretere Details, um die Ursache finden zu koennen.

Unsinn.

Man sollte viel eher eine Kodierung verwenden, die die benoetigten Zeichen darstellen kann.[/quote] völliger unsinn ist das bei html-seiten nicht, denn ausländische browser können die sonderzeichen u.u. nicht darstellen - da brauchts die maskierung, sonst gäbe es sie ja nicht.

das klingt auch ein bisschen unsinnig. Wenn ein Sonderzeichen nicht dargestellt werden kann, dann liegt es wohl eher daran, dass im System nur Schriftarten installiert sind, die die benötigten Sonderzeichen nicht enthält. Und wenn sie nicht vorhanden sind, können sie nicht angezeigt werden, ganz egal auf welche Art und Weise man Sonderzeichen maskiert oder kodiert.
Ich kodiere meine Seiten lieber vernünftig mit UTF-8, oder wenn nicht benötigt mit einem Latin Zeichensatz, wie es in Deutschland ja üblich ist.

mfg Balmung

Das hat dann wenn aber andere Gruende; siehe auch Balmungs Antwort.

Nein, die gibt es, weil es Kodierungen gibt, die diese gaengigen Sonderzeichen nicht enthalten - US-ASCII z.B., was ja eine der ersten verbreiteten Kodierungen in diesem Bereich war. Und da u.a. Deutsch ja auch von einer nicht unerheblichen Anzahl von potentiellen Nutzern gesprochen wird, hat man da dann schon mal an Moeglichkeiten fuer HTML gedacht, diese auch dann im Quellcode unterbringen zu koennen, wenn die verwendete Kodierung sie ggf. nicht enthaelt.

Aber einen hinreichend modernen Web-Browser, der wenigstens ISO-8859-1 oder UTF-8 versteht, duerfte wohl jeder Nutzer, der auch nur im entferntesten an deutschen Umlauten interessiert sein koennte, inzwischen haben.

so habe ich darüber bisher noch gar nicht nachgedacht - das ist einleuchtend. allerdings @balmung: wenn man die maskierung nutzt, hat der browser die möglichkeit, die sonderzeichen irgendwie anders darzustellen, z.b. als ae, oe und ue - das meinte ich. ich werde wohl weiterhin an der maskierung festhalten, da ich es so gelernt habe, aber andere können es natürlich anders machen.

hm naja, ä ist ja im Prinzip nichts weiter als ein Entity, welches auf ein bestimmtes Unicode Zeichen verweist/referenziert. in dem Fall auf 0x00E4 (228 Dezimal)
Genau so könnte man die Entities ä oder ä nutzen, welche alle auf das selbe Unicodesymbol weisen.
Hier kann man nachschauen und findet heraus, dass bei ISO-8859-1 der Bytewert 0xE4 ebenfalls auf das Unicodesymbol 0x00E4 verweist.
Und UTF-8 ist im Endeffekt nichts anderes als eine andere Verschachtelung von Unicode. D.h. die Bytefolge 0xC3A4 entspricht ebenfalls dem Unicodesymbol 0x00E4

Jetzt denkt man sich natürlich, wenn all diese verschiedenen Schreibweisen auf ein und das selbe Symbol verweisen, wäre es dann nicht unsinnig, wenn nur ä im Fall der Fälle als ae dargestellt wird? Wäre es nicht viel sinnvoller zu sagen, dass alle Symbole die auf 0x00E4 verweisen als ae im Fall der Fälle dargestellt werden sollen?
Ich nehme mal nicht an, dass die Browser so dämlich Programmiert sind, falls es diese Umschreibung wirklich gibt (wovon ich nicht überzeugt bin). Wie es in der Praxis ausschaut weiß ich allerdings nicht, da ich bisher nie in solch einer Situation geraten bin, und bisher auch kein System erlebt habe, bei dem keine Umlaute in den Schriftarten vorhanden waren… (außer vielleicht bei den Japanern oder so, aber wann besuchen die schon meine Seiten? Und wenn, wären die Seiten ohnehin Englisch => kein Gebrauch von Umauten) - Ich Schweif ab.

Außerdem:
Wer intensiver XML nutzt (wie ich, gerne im Zusammenhang mit XSL) kommt um eine richtige Kodierung nicht drum rum. in XML müsste man sämtliche Entities erst im Doctype deklarieren, was IMHO unnützer zusätzlicher Aufwand ist.

[size=90]Wie war noch gleich das Original-Topic in diesem Thread?[/size]

mfg Balmung