Zeilenumbrüche in der tabelle

[Andy]

Hallo,

ich habe einige Tabellen in denen sich Text inklusive Zeilenumbrüche <br /> befindet.
Beispiel:
das ist ein Text<br />mit Zeilenumbruch.

Jetzt meine Frage sollte man das so lassen, ich meine ist das OK.
Sollte man (kann man die) <br /> ersetzen? Wenn ersetzen gegen was?

Wenn ich :
das ist ein Text
mit Zeilenumbruch.
so in der Tabelle habe, bekomme ich keine Pobleme beim Mailversand mit php Mail.
Muss denn Text aber in den php/html Dateien mit nl2br auslesen.

Was ist der bessere Weg.

Dankeschön

[Timbo]

Hi Andy,

also das hängt von deinem Programm ab. Du kannst <br /> gegen \n ersetzen, wenn das noch in vorhanden ist. Allerdings musst du es bei der Anzeige wieder zurückwandeln, was Performance einbüßt. I.d.R. ist das aber kein Problem. Oder hast du 1.000.000 Page-Impressions pro Tag?

Gruß
Timbo

[Andy]

Hallo Timbo,

wenn ich das <br> nicht ersetze, ist das dann ein Problem für die Datenhaltung?

Ich würde es am liebsten so lassen und ab sofort die Daten mit mysql_real_escape_string($variable) einfügen.
Dann habe die Daten so in der DB wie ich sie eingebe und keine Probleme beim Layout wenn ich die Daten in eine Mail einfüge.

danke Andy

[Timbo]

Umbrüche sind kein Problem. Du musst nur nach dem Auslesen stripslashes() verwenden, wenn du vorher mit mysql_real_escape_string() verwendet hast. Sonst wird dir \n angezeigt statt \n.

[ChrisB]

Hi,

Du musst nur nach dem Auslesen stripslashes() verwenden, wenn du vorher mit mysql_real_escape_string() verwendet hast. Sonst wird dir \n angezeigt statt \n.

Das ist Bloedsinn.

Bitte aeussere dich erst wieder zum Thema kontextgerechter Maskierung, wenn du es verstanden hast.

MfG ChrisB

[Timbo]

Hi,

Bitte aeussere dich erst wieder zum Thema kontextgerechter Maskierung, wenn du es verstanden hast.

Das ist Bloedsinn.

Bitte aeussere dich erst wieder zum Thema kontextgerechter Maskierung, wenn du die Antwort verstanden hast. Oder willst du hier noch einen Thread zum Thema SQL-Injection oder "Wieso sind überall Backslashes in den E-Mail?"?

MfG Timbo

[ChrisB]

Hi,

Bitte aeussere dich erst wieder zum Thema kontextgerechter Maskierung, wenn du es verstanden hast.

Das ist Bloedsinn.

Nein, ist es nicht - *deine* Antwort:

Du musst nur nach dem Auslesen stripslashes() verwenden, wenn du vorher mit mysql_real_escape_string() verwendet hast.

war Bloedsinn.

Bitte aeussere dich erst wieder zum Thema kontextgerechter Maskierung, wenn du die Antwort verstanden hast.

Ich habe sie "verstanden", und erkannt, dass sie bloedsinnig war. Deshalb habe ich darauf hingewiesen, damit dein bloedsinniger Vorschlag hier nicht unkommentiert stehen bleibt - sonst wendet jemand, der ebenfalls wenig davon versteht, diesen Bloedsinn eventuell noch an, und wundert sich dann ueber die komischen Ergebnisse.

Oder willst du hier noch einen Thread zum Thema SQL-Injection oder "Wieso sind überall Backslashes in den E-Mail?"?

Was ich will, schrieb ich doch schon - dass du dich bitte dazu erst aeussert, wenn du die Thematik verstanden hast.

Dass du annimmst, die , die zur kontextgerechten Behandlung von Daten in eine MySQL-Query von mysql_real_escape_string vor Sonderzeichen eingefuegt werden, wuerden damit auch in den gespeicherten Daten landen und seien deshalb nach dem Auslesen wieder zu entfernen, zeigt, dass du es bisher nicht verstanden hast.

MfG ChrisB

[Timbo]

Ob die "überflüssigen" Slashes letztendlich doch zu sehen sind, hängt allerdings von den Datenbankeinstellungen und magic_quotes_gpc ab.

Aber ist immer wieder nett darüber zu sprechen ;)

[ChrisB]

Hi,

Ob die "überflüssigen" Slashes letztendlich doch zu sehen sind, hängt allerdings von den Datenbankeinstellungen

Als da waeren?

und magic_quotes_gpc ab.

Die waeren ein Problem, welches *vor* dem Einfuegen der Daten zu beseitigen (besser: abzustellen) waere - und nicht erst beim Auslesen, da waere es zu spaet, weil dann bereits verfaelschte Daten in der Datenbank stehen wuerden.

magic_quotes_runtime haette ich jetzt als Argument noch gelten lassen - aber das ist per Default auf off, und in "freier Wildbahn" dementsprechend selten auf on vorzufinden (im Gegensatz zu magic_quotes_gpc). In PHP 6 entfallen gluecklicherweise beide.

MfG ChrisB