Frage zu htmlentities()

[lachesis]

Hallo,

wenn ich htmlentities() auf meine Daten (hier äöü) anwende kommt folgendes in der Datenbank an.

Woran kann das liegen?

& Atilde;& curren;& Atilde;& frac14;& Atilde;& para;

Danke

lachesis

[wahsaga]

hi,

wenn ich htmlentities() auf meine Daten (hier äöü) anwende kommt folgendes in der Datenbank an.
& Atilde;& curren;& Atilde;& frac14;& Atilde;& para;

Woran kann das liegen?

• an deinen eingangsdaten
• an den weiteren funtkionen/methoden, die du auf deine daten anwendest
• ...

gruss,
wahsaga

[lachesis]

Hallo,

alles was ich mache, ist die Daten per post an mein Script zu schicken,

dann:

$_POST['titel']=trim(htmlentities($_POST['titel']));

und schließlich:

INSERT INTO buch SET a_id=$_POST['author'],titel=$_POST['titel']

Eigentlich ist da nichts dabei, was mir den String dermassen verändern könnte oder?

Grüßle

[wahsaga]

hi,

$_POST['titel']=trim(htmlentities($_POST['titel']));

inhalte des $_POST-arrays zu überschreiben, ist unfein. weisen den bearbeiteten wert lieber einer eigenen variable zu, $titel o.ä.

kontrollausgabe diese wertes ergibt? (bitte in den quelltext schauen, nicht auf die browser-anzeige)

INSERT INTO buch SET a_id=$_POST['author'],titel=$_POST['titel']

kontrollausgabe dieses zusammengefügten query-strings ergibt?

gruss,
wahsaga

[lachesis]

Hi,

danke für den Tipp. Was dabei herauskommt: (aus dem Quelltext)

post: ä ü ö  ->Inhalt der $_POST['titel']

titel: ä ü ö

-> nach trim() und htmlentities()

INSERT INTO buch SET a_id=1,titel=ä ü ö...

-> der sql String

htmlentities verändert den String also in dieser Weise. Bloß warum tut es das? In anderen Anwendungen funktioniert das gut.

Trotzdem schonmal danke für Deine Hilfe

[Sven Rautenberg]

Moin!

post: ä ü ö  ->Inhalt der $_POST['titel']

titel: ä ü ö

Das häufige auftreten von à deutet sehr stark darauf hin, dass deine POST-Eingangsdaten UTF-8-codiert sind.

Dahingehend solltest du mal testen. Denn logischerweise kannst du UTF-8 nicht so einfach in Entities wandeln.

Schritt 1 wäre also, dass du dir mal jedes einzelne Byte des Strings ausgeben läßt. Wenn du nur "ä ö ü" dort drin hast, dann muß die Stringlänge (strlen()) 5 betragen. Wenn UTF-8 im Spiel ist, ist jeder Umlaut zwei Byte groß, und die Länge beträgt 8.

htmlentities verändert den String also in dieser Weise. Bloß warum tut es das? In anderen Anwendungen funktioniert das gut.

htmlentities() macht nur das, was definitionsgemäß draufsteht: Buchstaben der Codierung ISO-8859-1 in ihre Entities wandeln. Selbst das Eurozeichen aus ISO-8859-15 wird leider nicht in €, sondern in ¤ gewandelt und ergibt so im Browser einen kleinen Kreis mit 4 Strahlen drumrum.

Eventuell kommst du um eine selbstdefinierte Funktion nicht herum.

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.

- Sven Rautenberg

[lachesis]

Hi,

Das häufige auftreten von à deutet sehr stark darauf hin, dass deine POST-Eingangsdaten UTF-8-codiert sind.

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)

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.

Oder gibt es andere Gründe dafür, die die (wahrscheinlich winzige) Verzögerung wett machen?

Nochmals vielen Dank!

[Sven Rautenberg]

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

[Tom]

Hello,

inhalte des $_POST-arrays zu überschreiben, ist unfein. weisen den bearbeiteten wert lieber einer eigenen variable zu, $titel o.ä.

Wieso? Es handelt sich um ein globales Array und wenn der Programmierer weiß, was er tut, warum sollte er die Inhalte nicht überschreiben dürfen?
Speicherplatz ist oft kostbar.

Liebe Grüße aus http://www.braunschweig.de

Tom