Zeilenumbruch in Gästebuch

[Solero]

Hi Leute

bin gerade dabei, ein Gästebuch mit PHP zu schreiben und stehe an der Stelle, wo Gästebucheinträg beim Schreiben in die Datenbank als Strings bearbeitet werden.

Ich suche eine Funktion, die mir Einträge, die aus sinnlos langen Wörtern bestehen, abhackt, sprich nach x-Zeichen in einem Wort einen Leerschlag oder Zeilenumbruch einfügt.

wordwrap() will ich nicht verwenden, da wordwrap den Text immer na der gewissen Anzahl Zeichen bricht (oder beim nächsten Whitespace), ich will aber eine Funktion, die NUR ab z.B. 20 Zeichen ohne Leerschlag, Zeilenumbruch, etc einen Umbruch einfügt.

Wer hat da ne Idee, wie man das lösen könnte? Geht das ohne Reguläre Ausdrücke?

MfG
Solero

[Deus Figendi]

Wer hat da ne Idee, wie man das lösen könnte? Geht das ohne Reguläre Ausdrücke?

Ich weiß nicht warum dir das wichtig ist keine RegExp zu verwenden aber meine erste Eingebung war dann:

$arrayw = explode(" ",$input_stringw);  
foreach $arrayw as $keyw => $valuew {  
 if strlen ($valuew) > $max_lengthw {  
  $arrayw[$keyw] = substr($valuew,0,$max_lengthw)."\n".substr($valuew,$max_lengthw,end);  
 }  
}  
return implode(" ",$arrayw);

Ich hätte gerne split() statt explode() genommen um verschiedene Varianten der Whitespaces zu erwischen, aber du wolltest ja keine RegExp.

[dedlfix]

Hi!

bin gerade dabei, ein Gästebuch mit PHP zu schreiben und stehe an der Stelle, wo Gästebucheinträg beim Schreiben in die Datenbank als Strings bearbeitet werden. Ich suche eine Funktion, die mir Einträge, die aus sinnlos langen Wörtern bestehen, abhackt, sprich nach x-Zeichen in einem Wort einen Leerschlag oder Zeilenumbruch einfügt.

Das ist aber nicht für das DBMS notwendig.

Wer hat da ne Idee, wie man das lösen könnte? Geht das ohne Reguläre Ausdrücke?

Nimm besser CSS und gib dem Containerelement eine feste Breite und ein overflow: auto;

Lo!

[Gunnar Bittersmann]

@@Solero:

nuqneH

stehe an der Stelle, wo Gästebucheinträg beim Schreiben in die Datenbank als Strings bearbeitet werden.

Nein, falsche Stelle. Beim _Schreiben_ in die Datenbank solltest du die Nutzereingaben so lassen, wie sie sind. (Aber dabei natürlich keine Injections zulassen.)

Wenn du die Nutzereingaben in irgendeiner Form (außer technisch notwendigem Escapen) bearbeiten willst, dann nach dem _Lesen_ aus der Datenbank.

Qapla'

[dedlfix]

Hi!

Beim _Schreiben_ in die Datenbank solltest du die Nutzereingaben so lassen, wie sie sind. (Aber dabei natürlich keine Injections zulassen.)

Man lässt die Nutzereingaben nur dann wie sie sind, gerade wenn man keine Injections zulässt - sie also so bearbeitet, dass sie vom empfangenden System intentionsgemäß interpretiert werden können (meine Intention, nicht die des bösen Buben).

Lo!

[Tom]

Hello,

Beim _Schreiben_ in die Datenbank solltest du die Nutzereingaben so lassen, wie sie sind. (Aber dabei natürlich keine Injections zulassen.)

Man lässt die Nutzereingaben nur dann wie sie sind, gerade wenn man keine Injections zulässt - sie also so bearbeitet, dass sie vom empfangenden System intentionsgemäß interpretiert werden können (meine Intention, nicht die des bösen Buben).

Das ist jetzt aber ein Satz mit einem Verständlichkeitsgrad eines Sprechers, der mal einen Doktortitel hatte, den sie ihm aber wieder weggenommen haben... ;-P

Wolltest Du sagen, dass Benutzereingaben grundsätzlich in den vorgesehenen Zieltyp umgewandelt werden sollten und man meckert, wenn dies nicht funktioniert? Erst bei der Übergabe an die nächste (Verarbeitungs-)Stufe (z.B. die Datenhaltung) müssen dann die berühmten Kontextwechsel beachtet werden...

Den Kontextwechsel von Datentransfer zu Script hat ja schon PHP für uns vorgenommen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Beim _Schreiben_ in die Datenbank solltest du die Nutzereingaben so lassen, wie sie sind. (Aber dabei natürlich keine Injections zulassen.)
Man lässt die Nutzereingaben nur dann wie sie sind, gerade wenn man keine Injections zulässt - sie also so bearbeitet, dass sie vom empfangenden System intentionsgemäß interpretiert werden können (meine Intention, nicht die des bösen Buben).
Wolltest Du sagen, dass Benutzereingaben grundsätzlich in den vorgesehenen Zieltyp umgewandelt werden sollten und man meckert, wenn dies nicht funktioniert?

Wer ist "man" in dem Fall? Der Zieltyp wäre sozusagen "Stringliteral für SQL-Statments". Ein

Hallo 'Welt'!

(bei in '' eingefassten Strings) ist nur dann gemäß meiner Intention und aus Sicht des DBMS unverfälscht, wenn ich die Anführungszeichen um Welt maskiere. Ansonsten liest das DBMS nur Hallo und ein Leerzeichen, was nicht mehr der Benutzereingabe entspricht, also (unbeabsichtigt sicherlich) verändert wurde.

Erst bei der Übergabe an die nächste (Verarbeitungs-)Stufe (z.B. die Datenhaltung) müssen dann die berühmten Kontextwechsel beachtet werden...

Eben. Wenn Gunnar die Injections anspricht, meint er auch diesen Vorgang, nicht nur die vorherige Verarbeitung im Script.

Lo!

[Tom]

Hello,

Wolltest Du sagen, dass Benutzereingaben grundsätzlich in den vorgesehenen Zieltyp umgewandelt werden sollten und man meckert, wenn dies nicht funktioniert?

Wer ist "man" in dem Fall? Der Zieltyp wäre sozusagen "Stringliteral für SQL-Statments". Ein

Hallo 'Welt'!

Da bringst Du jetzt selber mehrere Dinge durcheinander.
http://forum.de.selfhtml.org/archiv/2011/1/t202717/#m1369714

Also erstmal sollte im Script, typischerweise in einem Elemetn von $_GET oder $_POST kein Literal mehr stehen, sondern ein Wert. PHP überträgt hier grundsätzlich nur den Datentyp "String".

Die Wandlung (Kontextbehandlung) für die Verwendung im Script hat bereits stattgefunden. Dennoch kann die Zeichenkette nun noch Zeichen enthalten, die nicht hineingehören (Stichwort: Magic Quotes).

Außerdem muss nun geprüft werden, ob der vorgesehene Zieltyp aus dem String-Wert ohne Fehler erzeugt werden kann. Wie genau hier "Fehler" zu definieren ist, hängt sicherlich auch vom Geschick der Umwandlungsfunktion ab.

Beispiel:
Aus dem String "08.02.1969" den String "19580208" zu machen, dürfte noch recht einfach sein.
Aus dem String "08.2.1969" den String "19580208" zu machen, ist schon eine Stufe schwieriger.
Aus dem String "08.2.69" ebenfalls den String "19580208" zu machen, erfordert schon Zusatzinformationen.

Mit dem String "08,2,69" immer noch zum gewünschtren Erfolg zu kommen, ist schon ein wenig Überlegung wert.

Sinn dieser Umwandlungsstufe (von "Filter" bis "Sanitize") liegt sicherlich darin, dem Benutzer das Eingaben von Daten zu erleichtern und trotzdem plausible Daten zu erhalten. In dieser Stufe ist das Ziel ein vereinheitlichtes ROHDATEN-Format.

Ob diese Daten dann später in eine Datenbank geschrieben werden, spielt HIER noch keine Rolle.

(bei in '' eingefassten Strings) ist nur dann gemäß meiner Intention und aus Sicht des DBMS unverfälscht, wenn ich die Anführungszeichen um Welt maskiere. Ansonsten liest das DBMS nur Hallo und ein Leerzeichen, was nicht mehr der Benutzereingabe entspricht, also (unbeabsichtigt sicherlich) verändert wurde.

Eben diese Behandlung (Escaping) ist erst der nächste Schritt. Wenn ich die Datenbank über Blockpuffer mit Daten fülle, muss ich mit dem String gar nichts mehr nachen, wenn das DBMS den Datentyp String unterstützt (was normal wäre). Wenn ich eine Zahl übergeben will, muss ich den die Zahl repräsentierenden String vorher noch in ein gültiges Zahlenformat umwandeln.

Wenn ich für die Übergabe eine Textschnittstelle benutzte, muss ich den String escpapen, mit dem die Zahl repräsentierenden String gar nichts mehr machen.

Erst bei der Übergabe an die nächste (Verarbeitungs-)Stufe (z.B. die Datenhaltung) müssen dann die berühmten Kontextwechsel beachtet werden...

Eben. Wenn Gunnar die Injections anspricht, meint er auch diesen Vorgang, nicht nur die vorherige Verarbeitung im Script.

Aber wir sollten nicht zwei Verarbeitungsschritte in einem zu Brei verarbeiten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Da bringst Du jetzt selber mehrere Dinge durcheinander.

Nö, ich fasste nur den Fokus enger als du.

Also erstmal sollte im Script, typischerweise in einem Elemetn von $_GET oder $_POST kein Literal mehr stehen, sondern ein Wert. PHP überträgt hier grundsätzlich nur den Datentyp "String".
Die Wandlung (Kontextbehandlung) für die Verwendung im Script hat bereits stattgefunden. Dennoch kann die Zeichenkette nun noch Zeichen enthalten, die nicht hineingehören (Stichwort: Magic Quotes).

Ja, aber den Teil haben wir schon hinter uns gelassen. Es geht darum, sie zu speichern und vorher noch zu ändern oder nicht.

Außerdem muss nun geprüft werden, ob der vorgesehene Zieltyp aus dem String-Wert ohne Fehler erzeugt werden kann. Wie genau hier "Fehler" zu definieren ist, hängt sicherlich auch vom Geschick der Umwandlungsfunktion ab.

Beispiel:
Aus dem String "08.02.1969" den String "19580208" zu machen, dürfte noch recht einfach sein.
[...]

Sowas stand für den vorliegenden Fall nicht zur Debatte.

(bei in '' eingefassten Strings) ist nur dann gemäß meiner Intention und aus Sicht des DBMS unverfälscht, wenn ich die Anführungszeichen um Welt maskiere. Ansonsten liest das DBMS nur Hallo und ein Leerzeichen, was nicht mehr der Benutzereingabe entspricht, also (unbeabsichtigt sicherlich) verändert wurde.
Eben diese Behandlung (Escaping) ist erst der nächste Schritt. Wenn ich die Datenbank über Blockpuffer mit Daten fülle, muss ich mit dem String gar nichts mehr nachen, wenn das DBMS den Datentyp String unterstützt (was normal wäre).

Warum sagst du nicht einfach Prepared Statements mit Databinding dazu? Ob da ein Blockpuffer oder sonstwas dahinter steht, ist weder relevant noch werden viele zu entziffern wissen, was du damit sagen willst. Prepared Statements dürften einige schon gehört haben und die anderen finden unter dem Begriff mehr zum Thema passende Literatur als zu "Blockpuffer".

Aber auch darum ging es nicht, weil implizit die Rede von herkömmlich zusammengestellten Statements war.

Wenn ich eine Zahl übergeben will, muss ich den die Zahl repräsentierenden String vorher noch in ein gültiges Zahlenformat umwandeln.

War auch grad nicht gefragt.

Erst bei der Übergabe an die nächste (Verarbeitungs-)Stufe (z.B. die Datenhaltung) müssen dann die berühmten Kontextwechsel beachtet werden...
Eben. Wenn Gunnar die Injections anspricht, meint er auch diesen Vorgang, nicht nur die vorherige Verarbeitung im Script.
Aber wir sollten nicht zwei Verarbeitungsschritte in einem zu Brei verarbeiten.

Hat er aber. Beziehungsweise er hat empfohlen, den ersten zu streichen und auf den zweiten hingewiesen. Und da gibt es den scheinbaren Widerspruch, dass die Daten verändert werden müssen, um unverändert anzukommen.

Lo!

[dedlfix]

Hi!

Wenn ich die Datenbank über Blockpuffer mit Daten fülle, muss ich mit dem String gar nichts mehr nachen, wenn das DBMS den Datentyp String unterstützt (was normal wäre).
Warum sagst du nicht einfach Prepared Statements mit Databinding dazu? Ob da ein Blockpuffer oder sonstwas dahinter steht, ist weder relevant noch werden viele zu entziffern wissen, was du damit sagen willst. Prepared Statements dürften einige schon gehört haben und die anderen finden unter dem Begriff mehr zum Thema passende Literatur als zu "Blockpuffer".

Siehe auch DBMS-Abstraktionen wie PDO. Dort kann man Prepared Statements verwenden, auch für die Systeme, die das nicht unterstützen. PDO ist dann so nett und erzeugt ein SQL-Statement mit maskiert eingefügten Daten. Ein Blockpuffer kommt dabei nicht vor. Aus Anwendersicht sieht man ein Prepared Statement - das ist der entscheidende Punkt, aus dem man erkennt, dass die Daten sicher zum DBMS gelangen, ohne dass man sie behandeln muss. Ob Blockpuffer, Simulation oder sonstwas dahinter steckt ist interessant aber nicht wichtig. Wenn man von Blockpuffer spricht, ist davon nur die eine interne Umsetzung betroffen. Spricht man von Prepared Statements, so wie der Anwender sie sieht, erwischt man hingegen alle Fälle.

Lo!

[Detlef G.]

Hallo Tom

Aus dem String "08.02.1969" den String "19580208" zu machen, dürfte noch recht einfach sein.

^^                ^^
Warum sollte man genau das wollen? ;)

Auf Wiederlesen
Detlef

[Tom]

Hello Detlef,

ach Du nun wieder!

Aus dem String "08.02.1969" den String "19580208" zu machen, dürfte noch recht einfach sein.
                           ^^                ^^
Warum sollte man genau das wollen? ;)

Na klar will amn das nicht.

Aus dem String "08.02.1969" den String "19690208" zu machen, dürfte noch recht einfach sein.

sollte das heißen. Die 1969 waren nur als Gemeinheit gegen den Unix-Timestamp gerichtet, die 1958 stammen aus einer anderen Zeit. Da hat man noch Computer aus Relais gebaut. :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Ich suche eine Funktion, die mir Einträge, die aus sinnlos langen Wörtern bestehen, abhackt, sprich nach x-Zeichen in einem Wort einen Leerschlag oder Zeilenumbruch einfügt.

wordwrap() will ich nicht verwenden, da wordwrap den Text immer na der gewissen Anzahl Zeichen bricht (oder beim nächsten Whitespace), ich will aber eine Funktion, die NUR ab z.B. 20 Zeichen ohne Leerschlag, Zeilenumbruch, etc einen Umbruch einfügt.

Sortier erstmal, was Du wirklich willst. Deine Forderungen sind nicht wirklich schlüssig.

eine Funktion,
[ ] die das Überschreiten der Zeilenlänge x verhindert
[ ] die ein Wort nur dann umbricht, wenn es am Ende der Zeile steht,
    und länger als y Zeichen ist

Alleine schon diese beiden Forderungen werfen die Frage auf, was mit Worten geschehen soll, die am Ende der Zeile stehen und kürzer als y Zeichen sind.

Damit die Zeilenlänge x nicht überschritten werden kann, müsste so ein Wort entweder total entfernt werden, oder komplett auf die nächste Zeile verschoben werden. Das soll es aber nach Deiner obigen Aussage zu wordwrap() nicht.

Also: wie lauten Deine sortierten und abgeglichenen Forderungen nun?

Ich schlage vor, dass Du wordwrap() benutzt :-))

http://de2.php.net/manual/en/function.wordwrap.php
Voraussetzungen: es handelt sich beim behandelten Text um Singlebyte-Codierung also z.B. ISO-8859-1.

Da es eine Funktion mb_wordwrap() noch nicht gibt in PHP, müsstest Du dir diese für Multibyte-Codierungen selber schreiben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunnar Bittersmann]

@@Tom:

nuqneH

Voraussetzungen: es handelt sich beim behandelten Text um Singlebyte-Codierung also z.B. ISO-8859-1.

Schlechte Voraussetzung.

Qapla'

[Tom]

Hello Gunnar,

Voraussetzungen: es handelt sich beim behandelten Text um Singlebyte-Codierung also z.B. ISO-8859-1.

Schlechte Voraussetzung.

Deshalb war es wohl auch eher rhetorisch gemeint...
Hat ja mal wieder keiner sonst daran gedacht in diesem Thread ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Solero]

Es geht mir nicht um die Zeilenlänge, sondern um die Läne eines Wortes, sprich Anzahl Zeichen ohne Whitespaces.

D.h. ich bin auf der Suche nach eine Funktion die nach z.B. 20 Zeichen ohne Whitespaces ein Whitespace einfügt. Sobald ein Whitespace vorhanden ist, kann HTML die Zeile ja selber umbrechen. Deshalb geht es ja mit wordrwap nicht, weil es immer nach einer gewissen Zahl Zeichen ein Whitespace einfügt (oder Umbruch unter berüksichtigung der bestehenden Whitespaces im String), die Funktion die ich suche soll aber NUR bei 20 Zeichen OHNE Whitespaces umbrechen.

Sorry, falls ich das zuerst nicht klar genug erklärt habe, ich hoffe man versteht mein Anliegen jetzt. Der Wunsch mit den RegExp ist lediglich ein Wunsch. Wenn irgendwie möglich würde ich es gern ohne lösen, geht es nicht dann bin ich natürlich auch mit RegExp einverstanden.

Danke nochmals an alle!

MfG
Solero

[suit]

Sorry, falls ich das zuerst nicht klar genug erklärt habe, ich hoffe man versteht mein Anliegen jetzt.

Was stört dich an den gegebenen Vorschlägen?

Der Wunsch mit den RegExp ist lediglich ein Wunsch. Wenn irgendwie möglich würde ich es gern ohne lösen, geht es nicht dann bin ich natürlich auch mit RegExp einverstanden.

Du widersprichst dir: erst wünscht du dir Reguläre Ausdrücke - im darauffolgenden Satz sagst du, es wäre die "Notlösung".

[Jean-Max]

Bounjoun Solero,

Es geht mir nicht um die Zeilenlänge, sondern um die Läne eines Wortes, sprich Anzahl Zeichen ohne Whitespaces.

D.h. ich bin auf der Suche nach eine Funktion die nach z.B. 20 Zeichen ohne Whitespaces ein Whitespace einfügt.

Warum nicht den User gleich darauf aufmerksam machen, dass ein Wort in seiner Eingabe eine bestimmte Wortlänge überschreitet?

Dann muss er seine Eingabe korrigieren, nicht Du dann in der Datenbank. Er ist dann auch nicht enttäuscht, wenn nicht das rauskommt, was er geschrieben hat, eben weil er vorher informiert wurde, dass dies und das eben nicht erlaubt ist.

Adiou.

[Gunnar Bittersmann]

@@Jean-Max:

nuqneH

Warum nicht den User gleich darauf aufmerksam machen, dass ein Wort in seiner Eingabe eine bestimmte Wortlänge überschreitet?
Dann muss er seine Eingabe korrigieren

Och nö. Damit sollte der Nutzer nicht belastet werden. Was geht den auch an, ob das Layout der Seite gestört wird?

nicht Du dann in der Datenbank.

In der Datenbank ist auch die falsche Stelle.

Wenn, dann nach dem Auslesen aus der DB bei der Anzeige. Und sinnvollerweise nicht nach # Zeichen trennen, sondern nach Silben. Und keine Leerzeichen einfügen, sondern '­'. "Hyphenator" wäre der Suchbegriff.

Qapla'