htmlspecialchars und doppelte Anführungszeichen

[blumi]

Es geht um ein Gästebuch.
Text wird nach der Eingabe über Formular direkt in die DB geschrieben.
Zum Anzeigen des Eintrages werden später dann die Funktionen htmlspecialchars und nl2br angewendet.

Möchte nun noch eine Vorschau für den Eintrag mit einbauen. Hier gibt es jedoch Probleme mit den doppelten Anführungszeichen.

Wie regelt man es, dass die Anführungszeichen in der Vorschau zu sehen sind, wenn ich dann aber zurück gehe um eventuell den Eintrag zu ändern wieder als doppelte Anführungszeichen zu sehen sind in der Textarea?

[Husti]

Text mit "Hallogalli" schreibst du wahrscheinlich mit addslashes() in die DB?
$comment=addslashes(trim($comment));

Beim Auslesen asu der DB arbeitest du evtl. auch mit stripslashes()
$comment=htmlentities(stripslashes($comment));
echo nl2br($comment);

Wo ist dein Problem?

[blumi]

Text schreibe ich direkt in die DB ohne addslashes, wie bereits erwähnt.

Funktioniert gut, nur mit der Vorschau habe ich Probleme.

Problem Nr. 1
In der Vorschau wird aus "test" "\test"\

Problem Nr. 2
Wenn ich dann in der Vorschau auf zurück gehe wird aus "\ \\ und alles weiter wird abgeschnitten.

[Husti]

Daher addslashes und stripslashes

[Wyveres]

Original geschrieben von Husti
Daher addslashes und stripslashes

Bingo ... dürfte eigentlich dein problem lösen.

[wahsaga]

Original geschrieben von blumi
Problem Nr. 1
In der Vorschau wird aus "test" "\test"\

Problem Nr. 2
Wenn ich dann in der Vorschau auf zurück gehe wird aus "\ \\ und alles weiter wird abgeschnitten.

magic_quotes_gpc, zum x-ten Mal ...

[blumi]

Alles klar,
das sind die Wörter die ich brauchte.

Schau mir alles an und teste dann mal fleißig.

Danke

[ArSeN]

OffTopic:

---

"\test"\

Wohl eher \" *klugscheiß*

---

Jedenfalls mal was allgemeines: Es hat sich als praktischer erwiesen, die Umlaute und Anführungszeichen etc. _vor_ dem Einfügen in die DB umzuwandeln, und bei der Ausgabe lediglich ein nl2br anzuwenden. Damit sparst du dir ne Menge Arbeit.

[ghostgambler]

Original geschrieben von ArSeN
Jedenfalls mal was allgemeines: Es hat sich als praktischer erwiesen, die Umlaute und Anführungszeichen etc. _vor_ dem Einfügen in die DB umzuwandeln, und bei der Ausgabe lediglich ein nl2br anzuwenden. Damit sparst du dir ne Menge Arbeit.

Entities gehören nicht in deine Datenbank. Nie niemals nie, sie haben da absolut nichts zu suchen.

Eine Datenbank ist ein abstraktes Speichermedium, welches von verschiedenen Applikationen genutzt werden können muss und nicht alle Applikationen brauchen die Daten mit HTML-Entities.
Temporäre Daten kann man mit Entities zwischenspeichern, aber niemals die originalen Daten!

[prego]

ghostgambler hats erfasst.
Was ist wenn die Daten morgen in ner XML Schnittstellen auftauchen sollen? Oder Übermorgen als CSV-Export in ner Excel-Tabelle landen?

Btw, warum htmlentities? htmlspecialchars reicht vollkommen. Schaut mal nach "Charset" im Bezug auf die DB. Ich benutze schon seit Jahren kein $uuml; mehr - auch nicht in HTML.

Noch ein Tipp, mysql_real_escape_string() statt addslashes, sofern es sich um eine MySQL Datenbank handelt. Imo gibts aber für andere DB-Schnittstellen eine ähnliche Funktion.


PS: Man möge mich korrigieren, wenn ich hier falsch liege...

[wahsaga]

Original geschrieben von ArSeN
Es hat sich als praktischer erwiesen, die Umlaute und Anführungszeichen etc. _vor_ dem Einfügen in die DB umzuwandeln,

Bullshit.

und bei der Ausgabe lediglich ein nl2br anzuwenden.

Komisch, wieso das nicht auch gleich schon vorher?

[ghostgambler]

Original geschrieben von prego
PS: Man möge mich korrigieren, wenn ich hier falsch liege...

Nö, alles richtig, wird nur nicht überall so praktiziert ... leider ... folgende Programmierer haben dann die Arsch-Karte, wenn es darum geht auf einem non-standard-System aufzubauen~

[Husti]

Jedenfalls mal was allgemeines: Es hat sich als praktischer erwiesen, die Umlaute und Anführungszeichen etc. _vor_ dem Einfügen in die DB umzuwandeln, und bei der Ausgabe lediglich ein nl2br anzuwenden. Damit sparst du dir ne Menge Arbeit.

Nachdem sich der Pulverqualm verzogen hat...
Mal abgesehen von allen non-standard-systems, XML-Schnittstellen, CSV-Export, Applikationen usw. würden aus einem Zeichen mal flugs 6 bzw. mehr werden.