großes Inputfeld, Zeilenumbruch innerhalb

[dorkas]

Hallo,

ich habe eine Frage. Normalerweise finde ich immer alle Antworten alleine schon durch die Suche, aber ich glaube, diesmal scheiterte es daran, dass ich nicht so recht weiss, wie ich meine Suche formulieren soll.
Ich hoffe, ich bin im richtigen Forum dafür.

Ich habe ein Inputfeld, in das ein User einen About-Text über sich eingeben kann. Die Länge des Textes darf 2000 Zeichen betragen. Nun  habe ich angefangen dafür ein Input-Feld zu erstellen.

  
<table border="1" cellpadding="0" cellspacing="1">  
   <colgroup>  
     <col width="125">  
     <col width="500">  
   </colgroup>  
  
   <tr>  
      <td>About You:</td>  
      <td id="print_about"><c:out value="${model.about}"/></td>  
      <td><input class="inputFieldBig" type="text" name="about" maxlength="2000" id="input_about" value="${model.about}" style="display:none"></td>  
   </tr>  
</table>

Gestaltet habe ich es mit CSS:

.inputFieldBig{  
    width: 500px;  
    height: 60px;  
  
    background-color: #FFFFFF;  
  
    font-family: sans-serif;  
    font-size: 13px;  
  
    color: black;  
    border-color: #244179;  
    border-right-style: solid;  
    border-left-style: solid;  
    border-bottom-style: solid;  
    border-top-style: solid;  
    border-right-width: 1px;  
    border-left-width: 1px;  
    border-bottom-width: 1px;  
    border-top-width: 1px;  
}

Dargestellt wird es korrekt. Wenn ich aber anfange Text einzugeben, dann beginnt der Text vertical mittig und läuft dann endlos weiter nach hinten, über den Feldrand hinaus, ohne Zeilenumbruch.

Ich möchte gerne wissen, wie ich dieses Verhalten ändern kann.
Die Texteingabe soll oben links starten und wenn sie das Feldende erreicht, soll ein Umbruch erfolgen und der Text links in der zweiten Reihe weitergehen, usw.

Für eine Antwort wäre ich sehr dankbar.

Gruß, dorkas.

[Gunnar Bittersmann]

@@dorkas:

nuqneH

Die Texteingabe soll oben links starten und wenn sie das Feldende erreicht, soll ein Umbruch erfolgen und der Text links in der zweiten Reihe weitergehen, usw.

Du möchtest ein geeignetes http://de.selfhtml.org/html/formulare/eingabe.htm@title=Eingabefeld verwenden: ein mehrzeiliges.

Qapla'

[dorkas]

ja, genau, danke!!

gibt es da eigentlich auch eine Möglichkeit, die Texteingabe auf 2000 Zeichen zu begrenzen? Ich meine jetzt nicht, dass man mehr eingeben kann und dann per JavaScript oder Java oder... prüft, ob es zu viel waren. Es sollte am besten nach 2000 Zeilen stoppen, sonst ärgert sich der User doch, wenn er umsonst zuviele Zeilen getippt hat...

Danke :-)

[ChrisB]

Hi,

gibt es da eigentlich auch eine Möglichkeit, die Texteingabe auf 2000 Zeichen zu begrenzen?

Jetzt darfst du wieder anfangen, erst mal zu suchen, bevor du fragst :-)

Ich meine jetzt nicht, dass man mehr eingeben kann und dann per JavaScript oder Java oder... prüft, ob es zu viel waren. Es sollte am besten nach 2000 Zeilen stoppen, sonst ärgert sich der User doch, wenn er umsonst zuviele Zeilen getippt hat...

Dann prüft man halt *während* der Eingabe.

MfG ChrisB

[dorkas]

also, ich habe versucht das jetzt folgendermaßen mit JavaScript zu lösen:

  
<script type="text/javascript" >  
    function checkLength(about){  
        if (about.value.length>2000) {  
            about.value = about.value.substring(0,2000)  
        }  
    }  
</script>  

  
<tr>  
                <td>About You:</td>  
                <td id="print_about"><c:out value="${model.about}"/></td>  
                <td><textarea name="about" cols="70" rows="15" id="input_about" onkeyup="return checkLength(this)" onkeypress="return checkLength(this)" style="display:none">${model.about}</textarea></td>  
            </tr>  

Leider habe ich dabei folgendes Problem:
Der Text wird in eine Datenbank gespeichert. Die erlaubt für die Spalte About nur 2000 Zeichen.
Die Begrenzung des Textareas liegt zwar bei 2000, aber: wenn man ganz viele Leerzeilen oder Leerzeichen angibt, dann werden die beim Textareafeld nicht mitgezählt. In die Datenbank werden sie aber trotzdem gespeichert. Das heißt, wenn eine Person einen Text mit 2000 Zeichen und dazwischen mit 5 Leerzeilen schreibt, dann kann dieser Text nicht in die Datenbank gespeichert werden.

Auch stört mich, dass, wenn ein Text mit Leerzeilen geschrieben wird, dieser bei der Ausgabe nicht dementsprechend wiedergegeben wird, sondern komplett als Block. Ausgabe erfolgt ganz simpel mit:

About: <c:out value="${model.about}"/><br/>

Wäre dankbar, wenn mir jemand für meine Probleme eine Hilfestellung geben könnte. Danke.

[Der Martin]

Hallo,

<script type="text/javascript" >

function checkLength(about){
        if (about.value.length>2000) {
            about.value = about.value.substring(0,2000)
        }
    }
</script>

  
diese Funktion gibt keinen Wert zurück; weiter unten, wo du die Funktion aufrufst, verwendest du aber den undefinierten Rückgabewert:  
  

> `<textarea name="about" cols="70" rows="15" id="input_about" onkeyup="return checkLength(this)" onkeypress="return checkLength(this)" style="display:none">${model.about}</textarea>`{:.language-html}  
  

> Leider habe ich dabei folgendes Problem:  
> Der Text wird in eine Datenbank gespeichert. Die erlaubt für die Spalte About nur 2000 Zeichen.  
> Die Begrenzung des Textareas liegt zwar bei 2000, aber: wenn man ganz viele Leerzeilen oder Leerzeichen angibt, dann werden die beim Textareafeld nicht mitgezählt.  
  
Dann ist irgendeine Magie im Spiel. Der Codeauszug, den du zeigst, gibt dieses Verhalten jedenfalls nicht her. Die length-Eigenschaft eines Strings zählt alle Zeichen mit, auch Leerzeichen, Tabs oder Zeilenumbrüche.  
  

> In die Datenbank werden sie aber trotzdem gespeichert. Das heißt, wenn eine Person einen Text mit 2000 Zeichen und dazwischen mit 5 Leerzeilen schreibt, dann kann dieser Text nicht in die Datenbank gespeichert werden.  
  
Das solltest du näher untersuchen, vielleicht findest du dann die Stelle, an der dein Irrtum liegt. Ich kann's mir im Moment nicht vorstellen.  
  

> Auch stört mich, dass, wenn ein Text mit Leerzeilen geschrieben wird, dieser bei der Ausgabe nicht dementsprechend wiedergegeben wird, sondern komplett als Block. Ausgabe erfolgt ganz simpel mit:  
> `About: <c:out value="${model.about}"/><br/>`{:.language-html}  
  
Was immer das sein mag - HTML ist es nicht, Javascript auch nicht. Vermutlich eine Metaanweisung deines CMS, das du verwendest. Anyway, dass im HTML-Kontext jeglicher Whitespace auf jeweils ein Leerzeichen komprimiert wird, sollte bekannt sein. Hier ist also wieder ein klassisches Beispiel eines nicht bachteten Kontextwechsels. Für die Ausgabe im Kontext HTML muss der String geeignet aufbereitet werden.  
  
So long,  
 Martin  

-- 
Die letzten Worte des Polizisten:  
Ich hab mitgezählt, Leute: Sechs Schuss, jetzt hat er keine Munition mehr!  
  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[dorkas]

Hallo,

erstmal danke für deine Antwort.
Das mit dem return habe ich irgendwie übersehen. Ich bin neu bei JavaScript. Ich habe nun einfach das return rausgenommen. Die Funktion funktioniert, ist da jetzt noch ein Syntax-Fehler?

Ich habe das mit der Datenbank jetzt nochmal ausprobiert und vorher die Zeichen im Textareafeld durchgezählt. Diesmal hat es geklappt. Ich weiß nicht, was da vorhin schiefgelaufen ist, aber ich hoffe einfach mal, dass es meine Schuld war.

Nach wie vor wird der Text mit Zeilenumbrüchen und Leerzeichen in der Datenbank gespeichert. Das ist ja auch gut so.
Wie du erwähntest, muss ich ihn dann nur noch in das HTML Format bringen. Vielen Dank für deinen Hinweis dazu.

Ich habe mal kurz gesucht, aber noch nichts geeignetes gefunden. Da du darin Erfahrung zu haben scheinst, kannst du mir sagen, was du zur Aufbereitung eines Strings für HTML verwenden würdest?

Vielen Dank.

[Der Martin]

Hi,

Das mit dem return habe ich irgendwie übersehen. Ich bin neu bei JavaScript. Ich habe nun einfach das return rausgenommen. Die Funktion funktioniert, ist da jetzt noch ein Syntax-Fehler?

nicht dass ich wüsste.

Nach wie vor wird der Text mit Zeilenumbrüchen und Leerzeichen in der Datenbank gespeichert. Das ist ja auch gut so.
Wie du erwähntest, muss ich ihn dann nur noch in das HTML Format bringen. Vielen Dank für deinen Hinweis dazu.
Ich habe mal kurz gesucht, aber noch nichts geeignetes gefunden. Da du darin Erfahrung zu haben scheinst, kannst du mir sagen, was du zur Aufbereitung eines Strings für HTML verwenden würdest?

Das kommt drauf an, womit du ihn ursprünglich verarbeitest. Da du von Datenbank sprichst, gehe ich von serverseitiger Verarbeitung aus, und die typische Sprache wäre dann PHP. PHP bietet zwei Funktionen, die in diesem Fall wichtig sein könnten: htmlspecialchars() wandelt die Zeichen '<', '>' und '&', die in HTML ja eine Sonderbedeutung haben, in die entsprechenden Entity-Referenzen &lt;, &gt; und &amp; um, und nl2br() fügt den Zeilenumbrüchen, die ja in HTML keine Bedeutung und keine Wirkung haben, ein <br /> hinzu.

So long,
 Martin

[dorkas]

Hallo,

herzlichen Dank für deine Antwort.

also, ich verwende JSP Seiten (mit CSS und ein bisschen JavaScript) und ansonsten das Spring Framework und Hibernate, arbeite also mit Java. Außerdem verwende ich den MySQL Server 5.1. mit InnoDBs.

Den String, den ich mir über die JSP Seite aus dem Formular hole, speicher ich dann mittels Hibernate, so wie er ist, in die Datenbank. Dort steht er dann, wie erwähnt, korrekt drin.

PHP kann ich zwar ein wenig, aber möchte ich nicht auch noch verwenden. Dein Hinweis hilft mir aber dennoch. Ich werde mal nach equivalenten von den genannten Methoden suchen.

Was denkst du, sinnvoll wäre es doch auch außer den genannten Zeichen die Sonderzeichen (ä, ü, ö) entsprechend umzuwandeln, richtig?

Vielen Dank für deine Hilfe, ich mache mich jetzt mal auf die Suche!

Gruß, dorkas.

[dorkas]

kleine Korrekt, "korrekt" steht dir String natürlich nicht ganz drin. Sonderzeichen werden momentan noch 'seltsam' interpretiert ;-)

[Der Martin]

Hi,

Was denkst du, sinnvoll wäre es doch auch außer den genannten Zeichen die Sonderzeichen (ä, ü, ö) entsprechend umzuwandeln, richtig?

nein, das würde ich unbedingt vermeiden. Verwende stattdessen -falls du das nicht bereits tust- eine Codierung, in der du diese Zeichen im Klartext notieren kannst. UTF-8 bietet sich an.

Ciao,
 Martin

[dorkas]

ok, danke, werde mich gleich mal informieren

noch eine (dämliche) Frage: den String, den ich mir von der JSP Seite hole, speichere ich ja in die Datenbank. Wenn ich ihn in Java auslese, sieht er noch so aus, wie er sollte.
Wann also würdest du ihn HTML konform umwandeln? Vor der Speicherung in die Datenbank oder danach?

Ich würde eigentlich denken davor, damit man nicht bei jedem rausholen neu umwandeln muss, oder?

[Der Martin]

Hi,

noch eine (dämliche) Frage: den String, den ich mir von der JSP Seite hole, speichere ich ja in die Datenbank. Wenn ich ihn in Java auslese, sieht er noch so aus, wie er sollte.

so soll es sein.

Wann also würdest du ihn HTML konform umwandeln? Vor der Speicherung in die Datenbank oder danach?

Erst dann, wenn ich ihn als HTML an den Browser ausgebe.
Daten sollten dann *und genau dann* für einen bestimmten Kontext aufbereitet werden, wenn sie in diesen Kontext gebracht werden, nicht "auf Verdacht" an einer ganz anderen Stelle in der Verarbeitung. Vor dem Eintragen in die Datenbank musst du deinen String also für SQL aufbereiten, vor dem Ausgeben an den Browser für HTML.

Ich würde eigentlich denken davor, damit man nicht bei jedem rausholen neu umwandeln muss, oder?

Damit wirfst du dir selbst Knüppel zwischen die Beine, obwohl du es vielleicht nicht sofort merkst. Aber was ist, wenn in zwei Monaten dein Kunde kommt und sagt, "Toll, jetzt hab ich das Zeug ja alles in der DB, jetzt möchte ich daraus noch eine Excel-Tabelle erzeugen"? Dann fängst du wieder an, das HTML-Gedöns aufzulösen und stattdessen z.B. in CSV zu formatieren.

Deswegen: Verarbeite und speichere Daten, wo immer möglich, in einem neutralen Format, hier also Plain Text. Konvertiere und codiere dort, wo ein Kontextwechsel stattfindet (und nur dort) für den Zielkontext.

So long,
 Martin

[dorkas]

Herzlichen Dank für deine ausführliche Antwort.
Ich werde also deinen Rat befolgen und direkt _vor_ der Ausgabe den Text so umwandeln, dass er auf der HTML Seite richtig erscheint.

Leider komme ich nicht wirklich weiter. Das Problem stellt sich aktuell so dar:

Speicher ich einen String in der DB, der...

1. .. ein ü enthält
2. .. einen Zeilenumbruch enthält

so sieht dieser in der DB folgendermaßen aus:

1. .. für ü steht zb ³ da
2. .. für den Zeilenumbruch steht alles leer dar (also mit Zeilenumbruch, kann man nicht so gut erkennen.)

Hole ich es aus der Datenbank und gebe es in meinem Javarogramm aus, steht da:

1. .. ü
2. .. der Zeilenumbruch

Das bringt mich zu der Frage, ob ich trotz des ³ den Text weiterhin so wie er ist in der DB speichern kann. Es ändert sich ja scheinbar nichts.

Weiter: Wenn ich das ganze dann auf der JSP mit c:out ausgebe, sieht es folgendermaßen aus:

1. .. ü
2. .. kein Zeilenumbruch

Das heißt, ich brauche das ü nicht umwandeln. Mache ich das, muss ich für das c:out escapeXML=false angeben, damit es als ü dargestellt wird. Aber wozu, wenn es auch so schon richtig angezeigt wird. Die erste von dir genannte Methode htmlspecialchars brauche ich also nicht zu verwenden.

Nun kommt mein Problem. Ich kriege es einfach nicht hin, dass der Zeilenumbruch dargestellt wird. Das Problem ist, dass alle Methoden, die ich bisher gefunden habe (und alle Möglichkeiten), \t, \n oder anderes eben entsprechend ersetzen. Damit kann ich aber nichts anfangen, da diese ja dort gar nicht stehen.

Ich habe zum Beispiel auch solche Methoden ausprobiert: http://www.rgagnon.com/javadetails/java-0306.html aber nichts funktioniert.

Hat jemand noch eine Idee, was ich machen könnte?

Vielen Dank!

[Der Martin]

Mahlzeit,

Speicher ich einen String in der DB, der...

1. .. ein ü enthält
2. .. einen Zeilenumbruch enthält

so sieht dieser in der DB folgendermaßen aus:

1. .. für ü steht zb ³ da
2. .. für den Zeilenumbruch steht alles leer dar (also mit Zeilenumbruch, kann man nicht so gut erkennen.)

zu Fall 1: Womit stellst du fest, was "wirklich" in der DB steht? - Das sieht nämlich sehr danach aus, dass du noch ein Problem mit der Zeichencodierung hast.
Ein kleines ü hat den Zeichencode U+00FC und wird in UTF-8 durch die zwei Bytes C3, BC dargestellt.
Dasselbe ü wird in einer ISO-8859-x-Codierung aber durch das einzelne Byte FC repräsentiert.
Genau dieser Bytewert FC entspricht aber in CP437 (das ist der "eingebaute" Zeichenvorrat von Grafikkarten) dem Symbol ³, das du erwähnst.
Offensichtlich werden deine Daten also in ISO-8859-x an die DB übergeben und eingetragen, ebenso in ISO-8859-x wieder ausgelesen und weiterverarbeitet. Das Tool, mit dem du nachschaust, was "wirklich" in der DB steht, scheint die Daten aber als CP437 (auch "OEM-Zeichensatz" genannt) zu interpretieren.

Zu Fall 2: Da ist mir nicht klar, was du damit sagen willst.

Hole ich es aus der Datenbank und gebe es in meinem Javarogramm aus, steht da:

1. .. ü
2. .. der Zeilenumbruch

Perfekt.

Weiter: Wenn ich das ganze dann auf der JSP mit c:out ausgebe, sieht es folgendermaßen aus:

1. .. ü
2. .. kein Zeilenumbruch

Wo ist "kein Zeilenumbruch"? In der Anzeige im Browser? Ich sagte doch schon, dass jeglicher Whitespace (und dazu gehören auch Zeilenumbrüche) in HTML als ein Leerzeichen dargestellt werden. Schau in den Quelltext, den der Browser bekommt, da ist der Zeilenumbruch sicher drin.
Deswegen habe ich dich auch auf die PHP-Funktion nl2br() hingewiesen und erwähnt, dass sie die im Text vorhandenen Zeilenumbrüche durch <br> ergänzt, damit auch HTML hier einen Zeilenumbruch macht.

Die erste von dir genannte Methode htmlspecialchars brauche ich also nicht zu verwenden.

Doch, denn das hat nichts, aber auch gar nichts mit dem ü-Problem zu tun!
Warum du htmlspecialchars() oder etwas Vergleichbares brauchst, siehst du deutlich, wenn du im Eingabefeld mal folgendes eingibst:

Es gilt x<4 oder x>8

Dann wirst du ohne korrekte Behandlung bei der HTML-Ausgabe sehen:

Es gilt x8

Den Text dazwischen wird der Browser als unbekanntes HTML-Tag auffassen und ignorieren.

Nun kommt mein Problem. Ich kriege es einfach nicht hin, dass der Zeilenumbruch dargestellt wird. Das Problem ist, dass alle Methoden, die ich bisher gefunden habe (und alle Möglichkeiten), \t, \n oder anderes eben entsprechend ersetzen. Damit kann ich aber nichts anfangen, da diese ja dort gar nicht stehen.

Doch, natürlich. Du hast mindestens \n als Zeilenumbruch, möglicherweise sogar \r\n.

Ich habe zum Beispiel auch solche Methoden ausprobiert: http://www.rgagnon.com/javadetails/java-0306.html

Die ersten drei Ersetzungen, die dieser Code vornimmt, bilden htmlspecialchars() nach und sind unbedingt notwendig. Der Rest ist Bullshit.

Das zeite Beispiel in dem von dir verlinkten Artikel kümmert sich wenigstens auch um die Umwandlung von Zeilenumbrüchen.

Schönes Wochenende,
 Martin

[dorkas]

Hallo,

und nochmals danke für die lange Antwort....!!

also zunächst einmal zu htmlspecialchars. Ich habe dein Beispiel ausprobiert (Es gilt x<4 oder x>8) und dies ist kein Problem. Es wird korrekt dargestellt. Ich würde also weiterhin sagen, dass ich htmlspecialchars nicht brauche, sondern lediglich das mit den Zeilenumbrüchen hinbekommen muss.

zu Fall 1: Womit stellst du fest, was "wirklich" in der DB steht? - Das sieht nämlich sehr danach aus, dass du noch ein Problem mit der Zeichencodierung hast.
Ein kleines ü hat den Zeichencode U+00FC und wird in UTF-8 durch die zwei Bytes C3, BC dargestellt.
Dasselbe ü wird in einer ISO-8859-x-Codierung aber durch das einzelne Byte FC repräsentiert.
Genau dieser Bytewert FC entspricht aber in CP437 (das ist der "eingebaute" Zeichenvorrat von Grafikkarten) dem Symbol ³, das du erwähnst.
Offensichtlich werden deine Daten also in ISO-8859-x an die DB übergeben und eingetragen, ebenso in ISO-8859-x wieder ausgelesen und weiterverarbeitet. Das Tool, mit dem du nachschaust, was "wirklich" in der DB steht, scheint die Daten aber als CP437 (auch "OEM-Zeichensatz" genannt) zu interpretieren.

Ohje, ich hab nicht so viel Ahnung von Zeichencodes und Zeichensätzen. Ist es so schlimm, dass in der DB ³ steht, wenn doch im Javaprogramm das ³ als "ü" ausgegeben wird? Ich meine, hauptsache, ich habe das "ü" dann, wenn ich es brauche. Du sagtest doch selber, ich soll nicht konvertieren, bis ich es wirklich benötige. In dem Fall müsste ich ja gar nichts machen.
Oder habe ich jetzt irgendwas falsch verstanden?

Wo ist "kein Zeilenumbruch"? In der Anzeige im Browser?

Ja, im Broser, sorry. Im Quelltext ist er sichtbar, korrekt.

Nun kommt mein Problem. Ich kriege es einfach nicht hin, dass der Zeilenumbruch dargestellt wird. Das Problem ist, dass alle Methoden, die ich bisher gefunden habe (und alle Möglichkeiten), \t, \n oder anderes eben entsprechend ersetzen. Damit kann ich aber nichts anfangen, da diese ja dort gar nicht stehen.

Doch, natürlich. Du hast mindestens \n als Zeilenumbruch, möglicherweise sogar \r\n.

Ich habe zum Beispiel auch solche Methoden ausprobiert: http://www.rgagnon.com/javadetails/java-0306.html

Das zeite Beispiel in dem von dir verlinkten Artikel kümmert sich wenigstens auch um die Umwandlung von Zeilenumbrüchen.

So, also, ich habe das zweite Beispiel nun nochmal ausprobiert. Folgendes passiert:

Beispieltext:
"
Es gilt x<4 oder x>8

Zeilenumbrüche
"

Ausgabe im Browser:
aus

  
<c:out value="${model.about}"/>  

wird

  
Es gilt x<4 oder x>8 <br/> <br/>Zeilenumbrüche  
  

aus

  
<c:out value="${model.about}" escapeXml="false" />  

wird

  
Es gilt x<4 oder x>8 <br/> <br/>Zeilenumbrüche  

Hilfe....
das zweite sieht ja ganz gut aus, aber das hilft mir auch nichts, wenn <br/> <br/> im Browser dargestellt wird...

das ist irgendwie nicht ganz die richtige Lösung :-(

Danke für deine Hilfe!!!

[dorkas]

kleiner Nachtrag: Das Beispiel sieht als System.out in Java so aus:

Es gilt x<4 oder x>8  
<br/>  
<br/>Zeilenumbrüche

[Der Martin]

Hi,

kleiner Nachtrag: Das Beispiel sieht als System.out in Java so aus:
Es gilt x&lt;4 oder x&gt;8

hier ist die Maskierung richtig.

&lt;br/&gt;

Aber hier darf sie nicht sein. Kann es sein, dass du *erst* die <br>-Tags hinzufügst, und *dann* den gesamten String escapest? Dann werden natürlich die Tag-Klammern des <br> auch mit umgewandelt, was nicht sein darf. Diese Reihenfolge wäre dann verkehrt.

&lt;br/&gt;Zeilenumbr&#252;che

Wozu das 'ü' hier zu &#252; verstümmelt wird, will mir auch nicht einleuchten.

Ciao,
 Martin

[dorkas]

Hallo,

ich habe nun rausgefunden, dass ich auf der JSP-Seite bei c:out unbedingt escapeXml=false angeben muss und im auszugebenden Text dann "<br/>" (oder "<br>") als solche, nicht umgewandelt, stehen haben muss - dann klappt es. Eine andere Möglichkeit habe ich nicht gefunden. Ich werde also eine entsprechende Methode dafür schreiben.

Vielen Dank für deine ausführliche Hilfe! :-)

Gruß, dorkas

[Gunnar Bittersmann]

@@dorkas:

nuqneH

Ich habe dein Beispiel ausprobiert (Es gilt x<4 oder x>8) und dies ist kein Problem.

Doch, das ist es.

Es wird korrekt dargestellt.

Glück gehabt.

Ich würde also weiterhin sagen, dass ich htmlspecialchars nicht brauche

Oh, das würde ich nicht sagen. Nutzereingaben sind per se böse. '"><script>[code lang=javascript]alert("böser Code")</script>[/code]' solltest du nicht unbarbeitet wieder ausgeben. Lies: Nutzereingaben solltest du NIEMALS unbarbeitet wieder ausgeben.

Ohje, ich hab nicht so viel Ahnung von Zeichencodes und Zeichensätzen.

Abhilfe dagenen schafft Zeichencodierung für Anfänger und dortige Links.

Qapla'

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Es gilt x<4 oder x>8
Dann wirst du ohne korrekte Behandlung bei der HTML-Ausgabe sehen:
Es gilt x8

Nö. Und zwar deshalb nicht, weil ein Elementbezeichner nicht mit einer Ziffer beginnen darf. '<4' wird also vom Tagsoup-Parser nicht als Beginn eines Tags interpretiert.

'Es gilt x<4 oder x>8' im HTML ergibt tatsälich die Ausgabe "x<4 oder x>8" im Browser. (Was nicht heißen soll, dass man '<' unescapet im Quelltext verwenden sollte.)

Anders sieht es aus bei 'Es gilt x<a oder x>8'. Das ergibt tatsächlich "Es gilt x8".

Qapla'

[Gunnar Bittersmann]

@@dorkas:

nuqneH

Wann also würdest du ihn HTML konform umwandeln? Vor der Speicherung in die Datenbank oder danach?

Wenn sich die Frage auf deine vorherige

Was denkst du, sinnvoll wäre es doch auch außer den genannten Zeichen die Sonderzeichen (ä, ü, ö) entsprechend umzuwandeln, richtig?

bezieht, ist die Antwort: Weder davor noch danch, sondern gar nicht.

Qapla'

[ChrisB]

Hi,

Ausgabe erfolgt ganz simpel mit:
About: <c:out value="${model.about}"/><br/>

Was immer das sein mag - HTML ist es nicht, Javascript auch nicht.

Das dürfte ein JSTL-Tag in einem JSP-Dokument sein.

MfG ChrisB

[Kai345]

[latex]Mae  govannen![/latex]

Leider habe ich dabei folgendes Problem:
Der Text wird in eine Datenbank gespeichert. Die erlaubt für die Spalte About nur 2000 Zeichen.
Die Begrenzung des Textareas liegt zwar bei 2000, aber: wenn man ganz viele Leerzeilen oder Leerzeichen angibt, dann werden die beim Textareafeld nicht mitgezählt. In die Datenbank werden sie aber trotzdem gespeichert. Das heißt, wenn eine Person einen Text mit 2000 Zeichen und dazwischen mit 5 Leerzeilen schreibt, dann kann dieser Text nicht in die Datenbank gespeichert werden.

Das kann nicht sein. Ich hab gerade mal mit

<textarea name="foobar" onkeyup="alert(this.value.length)">vorbelegter Text</textarea>

getestet, es wird die Länge inklusive aller Leerzeichen und sonstigem Whitespace  ausgegeben.

Frage: Werden die multiplen Leerzeichen überhaupt benötigt (Zwecks Formatierung o.ä.)?
Wenn nicht, kannst du sie z.B. mit String.replace() auf ein vernünftiges Maß zusammenstauchen.

Cü,

Kai