Tach!
Mit "Accept Charset" habe ich dafür gesorgt, das er das Formular in utf-8 sendet und nicht in ISO-8859-1, da er bei falschem Headder ja auch das falsche formular charset sendet.
"Er" ist in diesem Fall nur der Browser, den du grade verwendest. Andere ignorieren das accept_charset möglicherweise.
Wenn ich nicht weiß wo der Fehler sitzt probiere ich einfach viel aus um die stelle zu finden wo es hakt.
Das Probieren allein ist ungünstig. Damit findet man nur zufällig eine gängige Konstellation, weiß aber nicht genau, ob man das Problem nun ganz gelöst hat oder nur teilweise. Genau nachschauen ist immer besser. Was für Bytes schickt denn der Browser da? Ist es die Kodierung, die ich von ihm erwarte? Solche Fragen musst du bei einer Fehlersituation zu klären versuchen.
Nur html entieties verwende ich noch (es sollte doch eigentlich egal sein, ob ich die funktion vor dem speichern oder beim auslesen verwende?
htmlentities() ist unsinnig. Du verwendest doch UTF-8, kannst damit alle Zeichen direkt ausgeben und musst keine Ersatzschreibweise verwenden. Lediglich die HTML-eigenen Zeichen müssen berücksichtigt werden und das macht htmlspecialchars().
Wo man das anwendet, ist alles andere als egal. Siehe Kontextwechsel - HTML in der Datenbank.
Aber so kann ich sie in der Speicherfunktion verwenden und muss sie nicht auf verschiedenen Seiten jeweils extra beim auslesen angeben und brauche mir keine sorgen zu machen sie mal zu vergessen und dann von einem Witzbold ein </div> oder so in mein HTML zu bekommen.)
Die Ersparnis trügt. Du must jetzt nur noch mehr auspassen, welche Daten schon behandelt sind und welche nicht. Stringverarbeitung ist mit behandelten Daten auch nicht ohne weiteres möglich (siehe Link).
Und mysql_real_escape_string() verwende ich jetzt vor dem speichern nun auch noch, vielen dank, dass ihr mich auf die Funktion aufmerksam gemacht habt. Ich arbeite eben noch nicht sehr lange mit php.
Den Kontextwechsel muss man in jedem System beachten, nicht nur in PHP.
dedlfix.