smilla

Hallo,

meine Seite läuft komplett unter UTF-8. Also header sendet UTF-8, im Meta ist es auch drinnen und mit Mysql läut es auch, alles soweit bestens, da ist auch nicht das Problem. Einzige sache ist, das meine Dateien nicht UTF-8 kodiert sind, aber dies macht keine Probleme, da ich sämtliche Sonderzeichen als html entitiy schreibe.

In der Datenbank stehen UTF-8 kodierte Strings, die ich normal anzeigen lasse, dies klappt ganz gut.

Nun möchte ich an einige Stellen Fehlermeldungen anzeigen lassen. Ich übergebe einen String an eine Funktion, der diese dann mit htmlentities anzeigt. Mit den Fehlermeldungen aus der Datenbank klappt dies wunderbar. Wenn ich von Hand aber selbst Fehlermeldungen im html Quelltext habe, beinhaltet diese html entities (für Sonderzeichen) und genau diese stellte htmlentities nicht richtig dar.

Während die erste Zeile die Daten nicht korrekt anzeigt, zeigt die zweite Zeile die Daten korrekt an.

Kann es Probleme geben, wenn ich immer ein html_entity_decode da mit einbaue.

Wie kann man das besser lösen? Oder muss ich meine Dateien auch utf-8 kodiert abspeichern?

smila

Mister Ad

Sascha Ahlers

Wenn die Daten, die zur Datenbank gehen UTF-8 sind, musst Du sie natürlich auch in UTF-8 abspeichern.

smilla

Mit den Daten aus der Datenbank komme geht es wunderbar, diese Datensätze enthalten auch keine html Entities. Es geht nur nicht mit den Daten, die ich manuell in den Quellcode schreibe, welche Entities behalten. Vermutlich besteht das gleiche Problem, auch wenn kein UTF 8 im Spiel ist.

Asipak

Wieso willst du überhaupt htmlentities auf von dir in den Quelltext geschriebenen Text anwenden?

Manko10

Wozu nutzt du bei UTF-8 htmlentities(). Warum nicht einfach htmlspecialchars()? Umlaute in UTF-8 zu maskieren ist Schwachfug.

Beitrag editiert:
[…] Zu langsam

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

smilla

Ja eigentlich völlig recht, wenn ich htmlspecialchars nehme, erzielt es eigentlich den Zweck den ich bei der Anzeige möchte. Das sollte mein Problem lösen.

Wenn ich dann meine Dokumente UTF-8 abgespeichert kriege, sollte alles bestens sein, aber dies soll nicht bestand dieser Disskussion sein.

Besten Dank an alle.

Abweichler

Hallo zusammen!
Ich beschäftige mich gerade mit derselben Problematik. Deshalb würde mich natürlich brennend interessieren warum es keinen Sinn macht Umlaute in UTF-8 zu maskieren.

Für eure Hilfe und Erläuterungen recht herzlichen Dank!
=)

ChrisB

Warum sollte es denn welchen „machen“?

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

nikosch

Wieso nicht, wenn es das Problem löst und auch noch den state of the art darstellt?
Maskierung dient dazu Zeichen eines fremden Zeichensatzes darstellen zu können. Ein erweiterter Zeichensatz fasst 255 Zeichen, was in Deutschland bspw. nötige Umlaute wie üöä beinhaltet, in Schweden oder Griechenland eben Zeichen Ihres Sprachraums. Unicode (UTF-8 etc.) erweitert die verfügbare Zeichenmenge eines Zeichensatzes radikal, so dass man vereinfach sagen kann: Unicode enthält alle Zeichen der Welt.

Unicode

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Abweichler

Nun, bisher dachte ich, um Inhalt genauso auszugeben wie er ursprünglich erstellt wurde. Ich denke da gerade an die Probleme mit den Umlauten die man als Anfänger gerne hat.
Vielen Dank für die Ausführung inkl. Link. Wenn ich das also richtig verstanden habe, brauche ich vor einer Speicherung in die DB Umlaute im Text nicht durch ASCII-Code zu ersetzen, solange DB, Datenübermittlung (Script<->DB) und Ausgabe mit UTF-8 formatiert sind?

Oder wie ist das gemeint mit dem state of the art?