Textarea zeigt <br />

[Karsten]

Guten Tag,

ich habe ein Formular mit einem textarea. Zeilenumbrüche des Eingebers werden übernommen. Will man sich den Inhalt anschauen, erscheint er so, wie man ihn eingegeben hat.

Will man nun den Inhalt korrigieren, muss man wiedrum in das Formular. Jetzt werden aber die Zeilenumbrüche mit <br /> angezeigt. Dadurch hat sich die Optik des Inhaltes verändert.

Wie kann ich das unterbinden ?

[Beat]

ich habe ein Formular mit einem textarea. Zeilenumbrüche des Eingebers werden übernommen. Will man sich den Inhalt anschauen, erscheint er so, wie man ihn eingegeben hat.
Will man nun den Inhalt korrigieren, muss man wiedrum in das Formular. Jetzt werden aber die Zeilenumbrüche mit <br /> angezeigt. Dadurch hat sich die Optik des Inhaltes verändert.
Wie kann ich das unterbinden ?

Indem du <br> wiederum zu \n konvertierst.

mfg Beat

[MudGuard]

Hi,

ich habe ein Formular mit einem textarea. Zeilenumbrüche des Eingebers werden übernommen. Will man sich den Inhalt anschauen, erscheint er so, wie man ihn eingegeben hat.
Will man nun den Inhalt korrigieren, muss man wiedrum in das Formular. Jetzt werden aber die Zeilenumbrüche mit <br /> angezeigt. Dadurch hat sich die Optik des Inhaltes verändert.
Wie kann ich das unterbinden ?
Indem du <br> wiederum zu \n konvertierst.

Eher indem die \n gar nicht erst zu <br> konvertiert werden.

cu,
Andreas

[Beat]

Indem du <br> wiederum zu \n konvertierst.
Eher indem die \n gar nicht erst zu <br> konvertiert werden.

ja eher (nämlich je nach Bedürfnis der verwendeten Datenbank), also nicht generell.
Ist der Weg HTML -> Server -> HTML so ist bei Flatfiles gegen \n -> <br> -> \n nichts einzuwenden.

mfg Beat

[Karsten]

Die Rohdaten werden ja einfach in die Datenabnk gespeichert und ausgegeben. In der datenbank werden die <br /> automatisch ergänzt. Jeder Zeilenumbrauch wird allerdings doppelt ausgeführt. und "<br/>" bzw. <n> werden als texteingabe übernommen.

Jetzt habe ich
$arbeit = str_replace('<br />', '', $dsatz["Arbeit"]);

benutzt, um die br und n weg zu bekommen. Ich weiß noch nicht, ob das der Königsweg ist.

[suit]

Jetzt habe ich
$arbeit = str_replace('<br />', '', $dsatz["Arbeit"]);

aaah es ist also php

benutzt, um die br und n weg zu bekommen. Ich weiß noch nicht, ob das der Königsweg ist.

nein, weil '' kein umbruch ist sondern nichts - wie schon mehrfach hier erwähnt, speichere die rohdaten und nicht html und dein "n" wird überhaupt nicht entfernt mit deiner zeile

wenns trotzdem unbedingt sein muss, warum ersetzt du dann nicht '<br />' durch einen zeilenumbruch?

[dedlfix]

echo $begrüßung;

Die Rohdaten werden ja einfach in die Datenabnk gespeichert und ausgegeben. In der datenbank werden die <br /> automatisch ergänzt.

Mir ist kein DBMS bekannt, das automatisch HTML-spezifische Dinge macht. Das wird garantiert irgendwas eigenes sein, das den Unfug verursacht.

Jetzt habe ich
$arbeit = str_replace('<br />', '', $dsatz["Arbeit"]);
benutzt, um die br und n weg zu bekommen. Ich weiß noch nicht, ob das der Königsweg ist.

Finde die Ursache anstatt im Nachhinein deren Auswirkungen zu korrigieren.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

Eher indem die \n gar nicht erst zu <br> konvertiert werden.
ja eher (nämlich je nach Bedürfnis der verwendeten Datenbank), also nicht generell.
Ist der Weg HTML -> Server -> HTML so ist bei Flatfiles gegen \n -> <br> -> \n nichts einzuwenden.

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen. Wenn du <br> als Zeichen für einen Zeilenumbruch speichern willst, musst du auch dafür sorgen, dass die Zeichenfolge <br>, die nicht für einen Zeilenumbruch stehen soll, entsprechend gekennzeichnet wird. Du handelst dir mit solch einer dem Kontext nicht gerecht werdenden Kodierung nur weitere Probleme ein.

echo "$verabschiedung $name";

[suit]

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen. Wenn du <br> als Zeichen für einen Zeilenumbruch speichern willst, musst du auch dafür sorgen, dass die Zeichenfolge <br>, die nicht für einen Zeilenumbruch stehen soll, entsprechend gekennzeichnet wird. Du handelst dir mit solch einer dem Kontext nicht gerecht werdenden Kodierung nur weitere Probleme ein.

zudem kommt dazu, man - sollte man jemals auf xhtml umstellen - wieder alle <br> in <br /> konvertieren muss

ebenso benötigt ein "echter" zeilenumbruch weniger speicherplatz als ein <br> oder gar <br />

beim auslesen aus der datenbank fürs frontend kann man dann nl2br() verwenden (sollte man denn mit php arbeiten)

[Beat]

echo $begrüßung;

Eher indem die \n gar nicht erst zu <br> konvertiert werden.
ja eher (nämlich je nach Bedürfnis der verwendeten Datenbank), also nicht generell.
Ist der Weg HTML -> Server -> HTML so ist bei Flatfiles gegen \n -> <br> -> \n nichts einzuwenden.

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen.

Es gibt flatfiles im xml Format.

Wenn du <br> als Zeichen für einen Zeilenumbruch speichern willst, musst du auch dafür sorgen, dass die Zeichenfolge <br>, die nicht für einen Zeilenumbruch stehen soll, entsprechend gekennzeichnet wird. Du handelst dir mit solch einer dem Kontext nicht gerecht werdenden Kodierung nur weitere Probleme ein.

Ich kenne kein Problem.
Mir macht nur diese "Rohdaten speichern" Propaganda Kopfschmerzen.
Ich pflege Daten zu validieren, bevor ich sie speichere. Ich determiniere Kontext und Sprachoptionen in Input.

mfg Beat;

[suit]

Mir macht nur diese "Rohdaten speichern" Propaganda Kopfschmerzen.
Ich pflege Daten zu validieren, bevor ich sie speichere. Ich determiniere Kontext und Sprachoptionen in Input.

rohdaten speichern ist auch nicht unbedingt nötig, man sollte nur ausgabemedienneutral speichern

alles in html zu speichern macht es später nötig bei bedarf in xhtml zu konvertieren

weitestgehend ausgabemedienneutral ist zb die wikisyntax von mediawiki, ob der parser html, xhtml oder latex ausgeben muss, ist ihm ansich egal

leider wird das in der wikipedia nicht konsequent praktiziert und viele infoboxen und vorlagen nutzen hardcodiertes html und arbeiten am parser vorbei - es gibt auch viele artikel in denen hardcodiert "<br />" drinnensteht

jemand der die inhalte weiternutzen möchte (um zb ein buch damit zu drucken, wurde ja bereits gemacht) muss dann erstmal allen html-kram konvertieren, weil eine ggf. vorhandene schnittstelle, die wikisyntax zb in postscript konvertiert, nicht ausreicht um alle für sein medium nicht relevatenten markup-elemente zu entfernen

[dedlfix]

echo $begrüßung;

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen.
Es gibt flatfiles im xml Format.

Flatfiles sind üblicherweise Plaintext-Files und eine XML-Datei wird auch so bezeichnet. Flach ist eine XML-Struktur im Allgemeinen nicht. Außerdem hat ein <br> alleinstehend auch nichts in einem XML-Datei zu suchen.

Wenn du <br> als Zeichen für einen Zeilenumbruch speichern willst, musst du auch dafür sorgen, dass die Zeichenfolge <br>, die nicht für einen Zeilenumbruch stehen soll, entsprechend gekennzeichnet wird. Du handelst dir mit solch einer dem Kontext nicht gerecht werdenden Kodierung nur weitere Probleme ein.

Ich kenne kein Problem.

Dann speichere doch mal einen Text nach deiner Zeilenumbruch-zu-<br>-Methode, der neben Zeilenumbrüchen die Zeichenfolge <br> in den Nutzdaten enthält, so dass beides verlustfrei wiederhergestellt werden kann.

Mir macht nur diese "Rohdaten speichern" Propaganda Kopfschmerzen.

Du hast immer das Problem, wenn du nicht möglichst nahe am Original speicherst, dass du Schwierigkeiten bekommst, wenn du mal ein anderes Format benötigst. Besonders dann, wenn nicht mehr zwischen gewolltem Text und einer Ersatzdarstellung zu unterscheiden ist.

Ich pflege Daten zu validieren, bevor ich sie speichere.

Validieren ist eine andere Baustelle. Für das Speichern ist keine Validierung erforderlich, sehr wohl aber eine Behandlung, die dem Speicherkontext gerecht wird.

Ich determiniere Kontext und Sprachoptionen in Input.

Wenn du diesem Satz eine wichtige Bedeutung beimisst, könntest du ihn so formulieren, das "in Input" verständlicher wird?

echo "$verabschiedung $name";

[suit]

Flatfiles sind üblicherweise Plaintext-Files und eine XML-Datei wird auch so bezeichnet. Flach ist eine XML-Struktur im Allgemeinen nicht. Außerdem hat ein <br> alleinstehend auch nichts in einem XML-Datei zu suchen.

alleinstehend, durch einen cdata-bereich umschlossen, schon ;)

Ich kenne kein Problem.

ich kenne das problem, das problem lässt sich in php durch htmlspecialchars() umgehen ;) das sorg dafür, dass ein als text gemeinters <br> (zb "ein <br> erzeugt einen umbruch"), auch so dargestellt wird

Dann speichere doch mal einen Text nach deiner Zeilenumbruch-zu-<br>-Methode, der neben Zeilenumbrüchen die Zeichenfolge <br> in den Nutzdaten enthält, so dass beides verlustfrei wiederhergestellt werden kann.

richtig, das ist das eigentliche problem ;) darum: rohdaten speichern und bei der ausgabe parsen -> htmlspecialchars() drüber, dann die umbrüche durch <br> ersetzen bzw von doppelten umbrüchen "umschlossene" zeilen mit <p></p> ergänzen

Wenn du diesem Satz eine wichtige Bedeutung beimisst, könntest du ihn so formulieren, das "in Input" verständlicher wird?

ich habs auch nicht verstanden, wollte aber nix sagen :D

[dedlfix]

echo $begrüßung;

ich kenne das problem, das problem lässt sich in php durch htmlspecialchars() umgehen ;) das sorg dafür, dass ein als text gemeinters <br> (zb "ein <br> erzeugt einen umbruch"), auch so dargestellt wird

Und dann? Beim Einlesen des Textes htmlspecialchars_decode() drüberlaufen lassen? Dann kann man es doch gleich lassen. Als Speichermedium wurde eine Datenbank genannt. Da benötigt man gemeinhin eine spezielle Behandlung nur wenn die Daten in einem SQL-Statement eingebettet zu ihr hintransportiert werden. Es ist unnötig, sich in der Situation mit HTML zu beschäftigen.

echo "$verabschiedung $name";

[suit]

Und dann? Beim Einlesen des Textes htmlspecialchars_decode() drüberlaufen lassen? Dann kann man es doch gleich lassen. Als Speichermedium wurde eine Datenbank genannt. Da benötigt man gemeinhin eine spezielle Behandlung nur wenn die Daten in einem SQL-Statement eingebettet zu ihr hintransportiert werden. Es ist unnötig, sich in der Situation mit HTML zu beschäftigen.

ich hab mich denke ich unklar ausgedrückt - htmlspecialchars() würde ich NUR für die frontendausgabe verwenden, in der datenbank landet das unbehandelt

eingaben in backend werden 1:1 in der datenbank gespeichert

änderungen die im backend durchgeführt werden, kommen exakt wie eingegeben wieder aus der datenbank, werden bearbeitet und wieder so gespeichert

ausgaben die ans fontend geschickt werden laufen durch einen parser - dieser führt zunächst mal ein htmlspecialchars() aus und formatiert das dann medientypgerecht (er ersetzt umbrüche durch br bzw p-elemente), ersetzt die entsprechende markierung für eine überschrift durch entsprechende hX-elemente usw

[dedlfix]

echo $begrüßung;

ich hab mich denke ich unklar ausgedrückt - htmlspecialchars() würde ich NUR für die frontendausgabe verwenden, in der datenbank landet das unbehandelt
eingaben in backend werden 1:1 in der datenbank gespeichert

OK, so kann ich das akzeptieren. Die Datenbank ist ja schließlich auch auf Rohdaten angewiesen, wenn ein Teil der Verarbeitung in ihr stattfinden soll, beispielsweise eine Sortierung oder das Anwenden von Stringfunktionen.

echo "$verabschiedung $name";

[Beat]

echo $begrüßung;

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen.
Es gibt flatfiles im xml Format.

Flatfiles sind üblicherweise Plaintext-Files und eine XML-Datei wird auch so bezeichnet. Flach ist eine XML-Struktur im Allgemeinen nicht. Außerdem hat ein <br> alleinstehend auch nichts in einem XML-Datei zu suchen.

Das ist aber das Resultat deiner Forderung.
Was machst du jetzt, wenn es nichts darin zu suchen hat?

Wenn du <br> als Zeichen für einen Zeilenumbruch speichern willst, musst du auch dafür sorgen, dass die Zeichenfolge <br>, die nicht für einen Zeilenumbruch stehen soll, entsprechend gekennzeichnet wird. Du handelst dir mit solch einer dem Kontext nicht gerecht werdenden Kodierung nur weitere Probleme ein.

Ich kenne kein Problem.

Dann speichere doch mal einen Text nach deiner Zeilenumbruch-zu-<br>-Methode, der neben Zeilenumbrüchen die Zeichenfolge <br> in den Nutzdaten enthält, so dass beides verlustfrei wiederhergestellt werden kann.

Input
Dies ist
Ein zeilenumbruch erzeugt durch <br>. Und damit sie nun wissen, wie ich ihnen den <br> Text darstellen kann: Ich maskiere das & zu &amp;. HTML ist nicht erlaubt. Nutzen sie die Funktionen nach der API [function:data]. Hier siehen sie die Anwendung von ![]([url:bsp.gif][info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]
[image:[url:bsp.gif)[info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]

Konversion Input -> Data
Dies ist <br>Ein Zeilenumbruch erzeugt durch &lt;br&gt;. Und damit sie nun wissen, wie ich ihnen den &lt;br&gt; Text darstellen kann: Ich maskiere das &amp; zu &amp;amp;. HTML ist nicht erlaubt. Nutzen sie die Funktionen nach der API [function:data]. Hier siehen sie die Anwendung von ![]([url:bsp.gif][info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]
[image:[url:bsp.gif)[info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]

Konversion Data --> HTML OUT
Dies ist <br>Ein Zeilenumbruch erzeugt durch &lt;br&gt;. Und damit sie nun wissen, wie ich ihnen den &lt;br&gt; Text darstellen kann: Ich maskiere das &amp; zu &amp;amp;. HTML ist nicht erlaubt. Nutzen sie die Funktionen nach der API [function:data]. Hier siehen sie die Anwendung von [info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]
(Darstellung eines Links mit Hover Info, der Link öffnet in einem neuen tab)

Konversion Data --> Textarea (oder "Rohdata" Export für Autor)
Dies ist
Ein Zeilenumbruch erzeugt durch <br>. Und damit sie nun wissen, wie ich ihnen den <br> Text darstellen kann: Ich maskiere das & zu &amp;. HTML ist nicht erlaubt. Nutzen sie die Funktionen nach der API [function:data]. Hier siehen sie die Anwendung von ![]([url:bsp.gif][info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]
[image:[url:bsp.gif)[info:Autor:bs
Grösse:120x160px
Filegrösse:14kB]]

Ich habe dir jetzt auch meine API vorgestellt. Die API kann beinhalten, dass sie \n zu [br:] wandelt, damit dies konsequent durchgeführt wird.
Meine API sieht generell kein (interpretierbares) HTML vor. HTML artiges kann deshalb grundsätzlich maskiert werden.
Es gilt lediglich zu beachten, das Konversionen immer zweistufig sind. Insofern die Maskierung von meinen API-Zeichen betroffen ist, auch dreistufig. Aber die Last der Konversion entfällt im Hauptbereich: Data nach HTML OUT, und dies folgt einem Performance Prinzip.

Das ist es, was mein Programm derzeit kann.
Ich ziehe es vor, dass ich \n in meinem Flatfile ausschliesslich als Record-Separator akzeptiere, ansonsten maskiere. Der Hintergedanke ist: Performance in Abfragen durch vereinfachte Iterationen.

Ich determiniere Kontext und Sprachoptionen in Input.

Wenn du diesem Satz eine wichtige Bedeutung beimisst, könntest du ihn so formulieren, das "in Input" verständlicher wird?

Ich hoffe, obiges gab eine Anschauung.
Der Hauptzweck der Anwendung ist HTML Output. Wäre der Zweck ein generell anderer, so würde ich wahrscheinlich meine Methode überdenken müssen.

mfg Beat;

[dedlfix]

echo $begrüßung;

Weder eine Datenbank noch Flatfiles haben das Bedürfnis nach HTML-spezifischen Dingen.
Es gibt flatfiles im xml Format.
Flatfiles sind üblicherweise Plaintext-Files und eine XML-Datei wird auch so bezeichnet. Flach ist eine XML-Struktur im Allgemeinen nicht. Außerdem hat ein <br> alleinstehend auch nichts in einem XML-Datei zu suchen.
Das ist aber das Resultat deiner Forderung.

Was habe ich denn anderes gefordert, als eine HTML-Behandlung für einen Nicht-HTML-Kontext wegzulassen?

Was machst du jetzt, wenn es nichts darin zu suchen hat?

Ich kodiere es kontextgerecht.

Konversion Input -> Data

Für welchen konkreten Kontext machst du dir eigentlich diese Mühe?

Konversion Data --> HTML OUT

Für einen irgendwann vielleicht mal später verwendeten? Warum willst du nicht alles zu seiner Zeit machen? Nur dann weißt du, was du konkret brauchst.

Das ist es, was mein Programm derzeit kann.
Ich ziehe es vor, dass ich \n in meinem Flatfile ausschliesslich als Record-Separator akzeptiere, ansonsten maskiere.

Aha, dein Kontext ist also keine Datenbank wie beim OP sondern eine Textdatei, die Zeilenumbrüche als Satztrenner verwendet. Du könntest es dir einfacher machen, wenn du Zeilenumbrüche als \n und \ als \ notierst, zur Not noch das \r berücksichtigst. Das wäre meiner Meinung nach dem Kontext angemessen. Das bleibt dann auch halbwegs lesbarer als HTML-Entitys.

Der Hintergedanke ist: Performance in Abfragen durch vereinfachte Iterationen.

Den Satz kann ich wahrscheinlich erst bewerten, wenn ich dein Programm dazu sähe. (Musst du jetzt nicht unbedingt veröffentlichen.)

Der Hauptzweck der Anwendung ist HTML Output. Wäre der Zweck ein generell anderer, so würde ich wahrscheinlich meine Methode überdenken müssen.

Und wenn der Zweck sowohl als auch ist, bzw. sich nachher herausstellt, dass noch ein Anwendungsfall für deine Daten dazukommt?

Letzten Endes musst du es sowieso machen, wie du es für richtig hältst. Man lernt ja am besten aus den Fehlern, die man selbst begangen hat. :-)

echo "$verabschiedung $name";

[Karsten]

Also, was ist denn besser ?
Wo kann ich einen passenden Link finden ?

[ChrisB]

Hi,

Also, was ist denn besser ?

Rohdaten speichern.

Wo kann ich einen passenden Link finden ?

Zu was - wie du Daten unveraendert laesst? Nichts tun - das solltest du eigentlich auch ohne Link hinbekommen.

MfG ChrisB

[Steel]

Hiho!

Also, was ist denn besser ?

Rohdaten speichern.

Wo kann ich einen passenden Link finden ?

Zu was - wie du Daten unveraendert laesst? Nichts tun - das solltest du eigentlich auch ohne Link hinbekommen.

Argh! Du Wahnsinniger! Du sagst ihm gerade er soll alle Usereingaben (Rohdaten) unveraendert uebernehmen! Nichtstun betrifft aber ja nur die Darstellung.

[suit]

Argh! Du Wahnsinniger! Du sagst ihm gerade er soll alle Usereingaben (Rohdaten) unveraendert uebernehmen! Nichtstun betrifft aber ja nur die Darstellung.

was spricht dagegen? mit unverändert war sicher gemeint, dass das ganze kontextspezifisch zu escapen ist

wenn ich rohdaten "unverändert" in eine mysql-datenbank schreibe, escape ich sie, wenn ich sie wieder rauslesen, entferne ich die escapezeichen wieder (mit der entsprechenden umkehrfunktion) - das verändert die rohdaten ansich nicht

[ChrisB]

Hi,

wenn ich rohdaten "unverändert" in eine mysql-datenbank schreibe, escape ich sie, wenn ich sie wieder rauslesen, entferne ich die escapezeichen wieder

Da gibt es nichts zu entfernen.

Die Maskierung von Sonderzeichen wird ausschliesslich fuer die Datenbankschnittstelle vorgenommen, damit die Daten und Sprachbestandteile nicht verwechseln kann.
An den Daten, die letztendlich in der DB landen, aendert sich dadurch aber rein gar nichts - es gibt also nichts wieder zu entfernen.

MfG ChrisB

[suit]

An den Daten, die letztendlich in der DB landen, aendert sich dadurch aber rein gar nichts - es gibt also nichts wieder zu entfernen.

auch wieder wahr ;)

[Steel]

Hi!

wenn ich rohdaten "unverändert" in eine mysql-datenbank schreibe, escape ich sie, wenn ich sie wieder rauslesen, entferne ich die escapezeichen wieder (mit der entsprechenden umkehrfunktion) - das verändert die rohdaten ansich nicht

Wo zum Geier is meine 'escapen != nichtstun ;)' Antwort geblieben?! Ich hasse unsere Netzanbindung!

[ChrisB]

Hi,

ich habe ein Formular mit einem textarea. Zeilenumbrüche des Eingebers werden übernommen. Will man sich den Inhalt anschauen, erscheint er so, wie man ihn eingegeben hat.

Will man nun den Inhalt korrigieren, muss man wiedrum in das Formular. Jetzt werden aber die Zeilenumbrüche mit <br /> angezeigt.

Also *nicht* mehr so, wie man ihn eingegeben hat.

Wie kann ich das unterbinden ?

Speichere Rohdaten - also "den Text so, wie man ihn eingegeben hat".

MfG ChrisB

[Peter Pan]

Hi!

Wie kann ich das unterbinden ?

Welche serverseitige Sprache benutzt Du?

off:PP