nicht angemeldet
Moin!
Ich habe ein Formular, das den WYSIWYG-Editor "TinyMCE" einsetzt.
Dieser Editor kann, da er auf Javascript basiert, prima mit Unicode umgehen. Muss gar nicht separat eingebaut werden.
In dieses Feld soll man beliebige Zeichen (auch Sonderzeichen wie das Pik/Karo/Herz-Zeichen und Umlaute) eintragen können.
"Dieses Feld" ist eine Textarea, die TinyMCE beim Start entsprechend seiner Bedürfnisse umbaut. In die Textarea gehört der HTML-Quellcode, der zu bearbeiten ist, und zwar in der Form, wie er in Textareas zu landen hat: Als Resultat von htmlspecialchars(). Und diese Funktion macht mit UTF-8 auch keinerlei Probleme, da sie nur die Zeichen codiert, die sich auch im ASCII-Bereich befinden.
Der Haken ist halt nun, dass bei der Ausgabe des Inhalts dieser maskiert werden muss. Hierfür habe ich zum einen die standardmäßige htmlentities(), die ja dank des letzten Parameters auch wunderbar mit UTF-8 umgehen kann. Für 90% meiner Inhalte reicht das auch.
htmlentities ist definitiv die falsche Funktion, wenn du UTF-8 einsetzt. Egal was der Encoding-Parameter dir verspricht.
Eine Ausnahme stellen TinyMCE-Inhalte dar, da diese ja HTML enthalten, was ja bei htmlentities() dann ebenfalls maskiert werden würde. Daher entschied ich mich, eine eigene Methode (quasi "htmlentitiesHTML()" ;-) ) zu bauen, die im wesentlichen wie htmlentities() funktioniert, ohne < > " ' zu maskieren. Dazu noch ein strip_tags() um böse Tags herauszuhauen und fertig.
Kann ich nicht nachvollziehen. Entweder der gespeicherte HTML-String geht unmaskiert raus, oder er wird durch htmlspecialchars() geschleust. Nur eine dieser beiden Möglichkeiten ist sinnvoll, wenn UTF-8 benutzt wird, und welche Möglichkeit das ist, hängt davon ab, in welchem Kontext der entstehenden HTML-Seite der String benutzt wird. Wird er direkt als HTML-Quellcode benutzt, ist htmlspecialchars() natürlich falsch. Wird er als Inhalt einer Textarea benutzt, ist htmlspecialchars() richtig.
Ich konvertiere also zuerst den String in einen Zeichensatz, den PHP bedienen kann,
Und dabei zerstörst du dir alle Zeichen, die in ISO-8859-1 nicht enthalten sind - das sind die meisten Unicode-Zeichen!
Warum das Gehampel mit dem Umcodieren? Kostet nur Zeit und macht Ärger!
Lustigerweise werden Umlaute korrekt maskiert. Lediglich Sonderzeichen wie Karo/Pik/Herz oder das Unendlich-Zeichen zwingen die Funktion zum Abbruch.
Weil das Zeichen sind, die in ISO-8859-1 nicht vorkommen. Also zerstört werden, und nicht wiederherstellbar sind.
Wenn ich statt "ISO-8859-1" "ASCII" nehme, bricht die Funktion auch bei Umlauten ab.
ASCII enthält nur Zeichen vom Code 0 bis 127. Umlaute sind darin nicht enthalten, die werden auch zerstört.
Ich hoffe ich hab euch jetzt mit dieser ausführlichen Beschreibung nicht erschlagen ;-)
Habt ihr ne Idee wie ich das Problem lösen könnte? Mir gehen langsam die Ideen aus....
Du maskierst zuviel, du codierst zuviel um. Nutze UTF-8 doch einfach. ;) Dann gibts keine Notwendigkeit zu ISO-8859-1 zurückzukehren.
- Sven Rautenberg