nicht angemeldet
Moin!
genau das war das Problem! Danke, dass hätte ich niemals alleine gefunden. In meinem Dokumenten Head stand das falsche Charset.
Jetzt funktionierts (mit charset=ISO-8859-1)
Damit funktioniert aber das Eurozeichen nicht wirklich - nur so zur Info. Du kriegst dann von den Browsern alles mögliche, aber eben kein Euro - genau deswegen ging das hier im Forum auch so lange nicht, weil diese Sache nicht so einfach zu lösen ist.
<- drei Eurozeichen als Test
Andererseits würde ich niemals Entities in eine Datenbank speichern, sondern die immer erst nach dem Auslesen aus der DB umwandeln. Du mußt eben nur aufpassen, dass du die Zeichencodierungen nicht durcheinanderbringst.
Warum? Was ist der Grund dafür? Eigentlich sollte doch viel häufiger gelesen (und damit umgewandelt) werden, wobei die Konvertierung doch Zeit kostet.
Im Grunde genommen brauchst du Entities wie ä etc. nicht verwenden, solange du eine korrekte Angabe für das Transfer-Encoding (leider im Meta-Tag als "charset" bezeichnet - ist aber technisch falsch) machst.
Der Zeichensatz von HTML und XML ist Unicode - also alle möglichen und unmöglichen Zeichen aller bekannten und darin definierten Schriften dieser Welt (und anderer Welten, denn die Schriften aus Tolkien "Herr der Ringe" sind auch definiert - und klingonisch auch).
Die Frage ist nun: Wie kann ich dem Empfänger sagen, welche Zeichen ich meine?
Und für sowas sind Dinge wie UTF-8, ISO-8859-1 oder Windows-1252 da. Diese definieren, welches Byte (oder welche Bytekombination) welches Zeichen meint.
Insofern ist es für moderne Browser gar kein Problem, ein un-entitiertes Ä mit dem Bytewert laut ISO-8859-1 zu erhalten. Erstens muß der Browser das Ä darstellen können, weil es in Unicode definiert wurde (ist nur die Frage, ob die Schriftart, die verwendet wird, eine Definition des Aussehens vorrätig hat), und zweitens ist die ISO-8859-1 ja nun kein exotischer Standard, den noch nie ein Mensch zuvor gesehen hat.
Ebenso gut könnte der Browser auch die UTF-8-Variante gesendet bekommen. Nur wird da vermutlich Netscape 4 noch so seine Probleme haben (was ich aber nur vermuten kann, ich habe es nicht selbst getestet).
Bleibt also nur die Frage: Wie speichert man seine Zeichen günstig ab?
Und diese Frage beantwortet sich: Es hängt davon ab. :)
Wenn auch nur die geringste Chance besteht, dass mehr als nur die amerikanischen ASCII-Zeichen gespeichert werden sollen, muß man sich entscheiden, welches Transfer-Encoding alle möglichen vorkommenden Zeichen komplett abdeckt.
ISO-8859-1 ist in diesem Zusammenhang eigentlich total OUT! Weil es kein Eurozeichen kennt. Ein Eurozeichen läßt sich in diesem Zeichensatz schlicht nicht darstellen. Für europäische Anwender ist dieser Zeichensatz zum Speichern von Eurozeichen (die ja nahezu überall vorkommen können) also total ungeeignet - und für amerikanische Anwender möglicherweise auch, wenn die sich mit Euro beschäftigen.
Wenn man für die gewählte Zeichencodierung unpassende Zeichen nun in Entities wandelt (die ja nur aus ASCII bestehen, also in jeder Codierung darstellbar sind), dann hat man den Nachteil, dass man beispielsweise nicht mehr direkt nach "ä" in der Datenbank suchen kann, sondern immer nach "ä" suchen muß.
Lediglich UTF-8 ist eigentlich sehr gut geeignet. Die Zeichencodierung der einzelnen Zeichen ist so gewählt, dass man auch ohne Verständnis der Mehr-Byte-Zeichen einen String nach Alphabet sortieren kann. Lediglich wenn es darum geht, tatsächlich auf einzelne Zeichen, und nicht auf die sie bildenden Bytes zuzugreifen, benötigt man spezielle Funktionen (PHP hat dazu die "mb..."-Funktionen im Angebot, mit denen man "multibyte"-Strings bearbeiten kann).
Warum ich keine Entities in die DB speichern würde? Weil es Dinge komplizierter macht. In die Datenbank gehören nach meiner Ansicht die Daten, von denen aus ich alle notwendigen Zeichencodierungen schnell erreichen kann. Die Entities sind explizit nur in HTML-Browserdarstellung verwendbar, deren Rückcodierung ist nicht mal so eben in einer Funktion getan. Wenn die Datenbank nun aber nicht nur HTML-Seiten befüllen soll, sondern auch noch text/plain-Ausgaben (wozu auch immer: CSV-Exporte, Textlisten, ...) füttert, gibt es dann logischerweise Konflikte.
- Sven Rautenberg