nicht angemeldet
htmlentities() zerfetz die Umlaute
AugeTagchen,
kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)
Lässt sich da was gegen machen oder muss ich auf htmlentites() verzichten und die EInträge anders entschärfen? (Wäre str_replace() für < > " ausreichender Schutz?)
thx in advance
MFG
bleicher
--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio
-
Hallo
kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)
Tja, das liegt - meiner Vermutung nach - daran, dass du offensichtlich schon beim Abspeichern der Einträge die Umlaute durch ihre HTML-Entities ersetzt. Vermute ich richtig?
Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh. Erst bei der Ausgabe lässt du htmlentities über den Text laufen. Ansonsten werden die Umlaute doppelt maskiert.
Schema: Code -> Umwandlung(Ansicht des Quelltextes) -> Umwandlung(Ansicht im Browser)
beim Speichern: ä -> ä -> ä
beim Ausgeben: ä -> &auml; -> äTschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
<dingdong /><dingdong /><toc /><toc /><toc /><shout>Florence!</shout>
Veranstaltungsdatenbank Vdb 0.2-
Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh.
damit die Gäste schöne, bunte, SQLinsertions rienpressen? Evtl den Password für die CMS öffentlich machen? :(
MFG
bleicher--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio-
Moin!
Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh.
damit die Gäste schöne, bunte, SQLinsertions rienpressen? Evtl den Password für die CMS öffentlich machen? :(
Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.
Escape immer kontextabhängig: in SQL anders als in HTML.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.
die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken? oder sollte man sicherheitshalber noch beide einsetzen? JS-einschübe brauche ich ja auch nicht unbedingt :=)
MFG
bleicher--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio-
Moin!
Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.
die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken? oder sollte man sicherheitshalber noch beide einsetzen? JS-einschübe brauche ich ja auch nicht unbedingt :=)
Die Reihenfolge ist eigentlich ganz einfach:
Rohtext kommt aus der Textarea.
-> mysql_real_escape_string()
-> schreiben in die Datenbank.Rohtext kommt aus der Datenbank.
-> htmlspecialchars()
-> schreiben auf die HTML-Seite, z.B. auch in eine Textarea.Auf diese Weise kommt immer genau das dort an, wo man es brauchen kann.
- Sven Rautenberg
--
"Love your nation - respect the others." -
Hallo
Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.
die löst bei mir seltsame Ergäbniße aus..
... die sich wie zeigen?
darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken?
Nein, Sven schrieb nicht umsonst ausdrücklich "kontextabhängig".
mysql_real_escape_string, wenn es um MySQL geht,htmlentities, wenn es um HTML geht.oder sollte man sicherheitshalber noch beide einsetzen?
Beim speichern geht es um MySQL, also benutzte
mysql_real_escape_stringum die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt. Dafür wird, wegen der Ausgabe in einer HTML-Seite, die Maskierung der in diesem Zusammenhang gefährlichen Zeichen wichtig. Und die entfernt/maskiert man mit
htmlentities.Alle Klarheiten beseitigt? :-)
Tschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
<dingdong /><dingdong /><toc /><toc /><toc /><shout>Florence!</shout>
Veranstaltungsdatenbank Vdb 0.2-
echo $begrüßung;
Beim speichern geht es um MySQL, also benutzte mysql_real_escape_string um die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.
Diese Funktion entfernt keine 'schädlichen' Zeichen. Es gibt im Kontext eines SQL-Statements bestimmte Zeichen mit einer Sonderbedeutung. Damit man solche Zeichen auch als Datenbestandteil verwenden kann, müssen sie entsprechend präpariert werden. Einigen wird ein Backslash vorangestellt (", ' und ), andere werden in einer Ersatzdarstellung notiert (z.B. \r und \n).
Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt.
Sie werden schon beim Parsen des SQL-Statements von MySQL dekodiert, denn sie sind nur dazu da, den Transport innerhalb des Textes des SQL-Statments zu überstehen. In der Datenbank landen sie in - sagen wir mal - reiner Form. (Wie genau das abgelegt wird ist MySQLs Angelegenheit.)
Das Abfrageergebnis eines Statements kommt auf anderem Weg aus der Datenbank. Für diesen Weg (Kontext) sind keine Maskierungen erforderlich. Hier werden die Zeichen in ihrer ursprünglich gemeinten Form übertragen.
Dafür wird, wegen der Ausgabe in einer HTML-Seite, die Maskierung der in diesem Zusammenhang gefährlichen Zeichen wichtig.
Von "gefährlichen" oder "schädlichen" Zeichen zu sprechen ist nicht richtig, denn diese Eigenschaften haben diese Zeichen nicht. Sie haben einfach nur eine Sonderbedeutung in einem bestimmten Kontext. Wenn sie diese Sonderbedeutung nicht mehr haben sollen, müssen sie entsprechen den Vorschriften des Kontextes behandelt werden.
Und die entfernt/maskiert man mit
htmlentities.htmlentities() behandelt viel mehr Zeichen als für HTML notwendig ist. htmlspecialchars() ist im Prinzip ausreichend.
echo "$verabschiedung $name";
-
Hallo
Beim speichern geht es um MySQL, also benutzte mysql_real_escape_string um die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.
Diese Funktion entfernt keine 'schädlichen' Zeichen.
Nein, sie maskiert sie und sie sind nicht schädlich, sondern aufgrund ihrer Sonderbedeutung zu maskieren (wie du schon schriebst), damit mit ihnen kein Code in das Statement eingeschleust werden kann. Entschuldigung für die unkonkrete Ausdrucksweise.
Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt.
Sie werden schon beim Parsen des SQL-Statements von MySQL dekodiert, denn sie sind nur dazu da, den Transport innerhalb des Textes des SQL-Statments zu überstehen. In der Datenbank landen sie in - sagen wir mal - reiner Form.
Aha.
Von "gefährlichen" oder "schädlichen" Zeichen [im HTML-Kontext] zu sprechen ist nicht richtig, denn diese Eigenschaften haben diese Zeichen nicht. Sie haben einfach nur eine Sonderbedeutung in einem bestimmten Kontext.
Als Zeichen ansich sind sie natürlich nicht schädlich, sie hätten aber eventuell eine schädliche Wirkung, wenn sie dem Zweck dienten, z.B. JavaScript-Code in einen Gästebucheintrag einzubetten. Und um dies zu verhindern, werden sie halt maskiert. Da man in diesem Zusammenhang oft von "unschädlich machen" spricht, lag der Begriff vom "schädlichen" Zeichen - zumindest für mich - nicht fern.
Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
<dingdong /><dingdong /><toc /><toc /><toc /><shout>Florence!</shout>
Veranstaltungsdatenbank Vdb 0.2
-
-
-
Hallo bleicher,
Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.
die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken?
Dürfen schon, zu empfehlen ist das aber keinesfalls, da htmlentities ja nicht unbedingt dafür sorgt, dass nicht irgendwelche unbeabsichtigen MySQL-Befehle ausgeführt werden.
Schöne Grüße,
Johannes
-
-
-
-
-
Moin!
kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)
Welche Codierung benutzt du? UTF-8?
Lässt sich da was gegen machen oder muss ich auf htmlentites() verzichten und die EInträge anders entschärfen? (Wäre str_replace() für < > " ausreichender Schutz?)
htmlspecialchars() ist vollkommen ausreichend in 99,999% der Fälle.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Moin!
hi
Welche Codierung benutzt du? UTF-8?
ja - sonst werden kyrillische zeichen zu "???" konvertiert ;(
htmlspecialchars() ist vollkommen ausreichend in 99,999% der Fälle.
thx
was ist mit 0,00001%^^? oder ist es der prozent der gleich mit dem hostserver gehackt wird?MFG
bleicher--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio
-
-
Hallo,
... mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)
welchen Zeichensatz (charset, der dritte Parameter) verwendet htmlentities() und welchen der Browser zur Anzeige?
Suchst du nicht eigentlich htmlspecialchars()?Grüße,
Jochen
-
welchen Zeichensatz (charset, der dritte Parameter) verwendet htmlentities() und welchen der Browser zur Anzeige?
Browser bekommt UTF-8 header.. 3er parameter? k ich lese mal im handbuch nach.
MFG
bleicher--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio-
Danke, das war die Lösung^^
'UTF-8'als charset ;)
MFG
bleicher--
__________________________-
Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
Lieber bereuen gesündigt zu haben, als nicht sündigen und es später trotzdem bereuen.
Boccaccio
-
-