Anführungszeichen in Strings?

[dflasjjs]

Moin,
ich habe mir eine kleine Webanwendung mit Servlets und JSP gebaut.
Dort gibts Probleme wenn ich innerhalb des Strings Anführungszeichen schreibe (null-pointer).

Wie gehe ich damit am besten um? Gar nicht erst "-Zeichen zulassen? Oder gibts andere Möglichkeiten? Und gibts es noch andere Zeichen die eher Problematisch sind? Denke jetzt an <,>, ' usw?

 

[Tomate_Salat]

String bsp = "Ein String mit \"Anführungszeichen\"";

Edit Du musst vor Anführungszeichen die du in einem String verwenden willst [c]\[/c] setzen. Das auch für das zeiche [c]\[/c] selber:

 String asdf = "Ein Slash im String \\ und das Anführungszeichen\"";

.

 

[dflasjjs]

Also muss ich mir jeden String angucken den jemand einträgt und auf diese Zeichen überprüfen und ggf. den String editieren?
Die Daten kommen ja aus einem HTML-Formular ins Servlet und von dort in die Java-Anwendung... also im Servlet mal reinluschern und gucken ob "-Zeichen drin sind und ggf. \ vorschreiben is ne gute Methode?

 

[Landei]

Ich glaube, du verstehst das Prinzip falsch. Im "Innern" besitzt jeder String ein char-Array, und da steht alles wie "gewohnt" drin, also z.B. wird aus dem String "ab\"cd" intern das Array char[]{'a','b','"','c','d'} - da gibt es keinen Backslash mehr. Diese Escape-Sequenzen sind nur dazu da, die Sache im Code "eindeutig" zu machen. Woher soll der Compiler auch wissen, ob du mit dem " nun ein Zeichen oder das String-Ende meinst? Der \ hat nun dadurch eine Spezialbedeutung (nicht nur dafür, sondern auch zur Darstellung nichtdruckbarer Zeichen wie "Carriage Return" \r, Zeilenumbruch \n oder Tabulator \t), muss also auch wieder speziell gekennzeichnet werden, hier mit \\. Wie gesagt, das ist nur ein Hilfsmittel um den Code in den Speicher zu bekommen, dort ist ein " auch ein ", ein \ ist ein \, ein Tab ist ein Tab u.s.w, und auch bei externen Quellen (Datei, HTTP...) wird das übertragen, was drinsteht.

 

[dflasjjs]

Ich muss mich korrigieren.
Der Konflikt tritt immer auf, wenn Checkboxen nutze und dort als Value irgendetwas mit Anführungszeichen habe, nun übergebe ich die Werte dem Servlet und der findet dann die Werte nicht mehr, weil ja alles bis zum ersten " abgeschnitten wird.

Also Beispiel:

Ich habe eine Auswahl von Gerichten, dieses kann vorher vom Benutzer eingegeben werden über ein Formular.
Er gibt folgende Gerichte ein:
Pizza
Lahm
Sahne "Spezial" Schnitzel

Dann kommt er zum Auswahlformular mit den Checkboxen. Beim letzten Gericht steht nun im Value-Ding: value="Sahne "Spezial" Schnitzel", im Browser sind alles richtig angezeigt, nur wenn ich das Formular abschicke und die Checkbox mit String[] radioVals = request.getParameterValues("radiogroup"); auslese, dann steht in radioVals[0] dann nicht mehr Sahne "Spezial" Schnitzel, sondern Sahne.

Da gibts nun natürlich mehrere Wege das zu beheben, " gar nicht zulassen, beim Value-Attribut die "s escapen.. was ist der eleganteste Weg für dieses Problem?

 

[faetzminator]

Auf Ebene (X)HTML soll ein " mit [c]&quot;[/c] ausgegeben werden. Genau so wie ein & als [c]&amp;[/c] etc. Natürlich muss man das im Backend wieder decodieren.

 

[Tomate_Salat]

[c]value='Sahne "Spezial" Schnitzel'[/c]

müsste auch funktionieren. Wie valide das ist, da bin ich mir aber nicht sicher^^

 

[faetzminator]

Es ist zumindest kein valides XML (also XHTML). Immer schön [c]<tag key="value" />[/c] verwenden

 

[Tomate_Salat]

Jup bezweifel dass das bei reinem xml funktionieren würde,bei html geht das aber glaub ich. Aber ist ja auch egal. Bezweifel dass das valide ist, denke eher dass hier html zu großzügig ist. Mit dem von dir (faetzminator) beschrieben Syntax ist man aber auf der sicheren Seite, also empfehlenswert eher den zu nehmen ;-)

 

[dflasjjs]

Hmm, dann müsste ich ja tausend Zeichen vor der AUsgabe umwandeln... <,>, ", ', & usw... sowas muss es doch schon irgendwie geben, oder nicht? bin kann ja nicht der einzige mit dem Problem sein...

Ansonsten... mach ich eben sone Methode wo ich jeden String vorher und nachher durchjagen muss und dieses ersetzt dann die Zeichen mit replace, oder kann ich da auch was mit Filtern machen?

 

[Tomate_Salat]

nun ja, ich würde mir überlegen, ob diese Zeichen zwingend notwendig sind, oder ob es nicht geschickter wäre, ID's zu vergeben.

 

[dflasjjs]

Unbedingt notwendig sind die Zeichen nicht. Du machst also die Zeichen gar nicht erst zulassen bei der Eingabe?

IDs ins Value-Feld schreiben? Würde im Prinzip gehen, aber das löst mein Gesamtproblem nicht. Wenn ich beispielsweise einen Datensatz editieren will, dann muss ich ja per Value den zu edtitierenden String reinschreiben. Da bringt mir die ID dann auch nichts.

Am liebsten würde ich wirklich die Zeichen rausfiltern, zumindest das ", alle anderen beeinträchtigen zumindest nicht die Funktion der Anwendung...

 

[Tomate_Salat]

Unbedingt notwendig sind die Zeichen nicht. Du machst also die Zeichen gar nicht erst zulassen bei der Eingabe?

Bei der Eingabe?! Da sollten die doch eigentl. bei der Übermittlung kein Problem sein. Ich glaube ich versteh deinen Antwendung nicht wirklich

IDs ins Value-Feld schreiben? Würde im Prinzip gehen, aber das löst mein Gesamtproblem nicht. Wenn ich beispielsweise einen Datensatz editieren will, dann muss ich ja per Value den zu edtitierenden String reinschreiben. Da bringt mir die ID dann auch nichts.

Nun ja, stünden die ID's als index für eine HashMap z.B sollte das eigentl. kein Problem darstellen, aber dafür müssten wir mehr Einblick in die Problemstelle haben.

Am liebsten würde ich wirklich die Zeichen rausfiltern, zumindest das ", alle anderen beeinträchtigen zumindest nicht die Funktion der Anwendung...

Nun ja, soetwas ist dann halt immer anfällig. Wenn du die Zeichen nur zur Anzeige benötigst, sollte das i.d.R. auch kein Problem sein (JLabels können ja HTML anzeigen, z.B.). Aber will man mit den Datensätzen wirklich arbeiten...nun ja, da würde ich eher versuchen eine Ausweichmethode zu finden, da man hier leicht einen sonderfall vergessen kann..

 

[dflasjjs]

Okay, dann beschreibe ich das Problem noch mal ein wenig genauer.

Es handelt sich um eine Webanwendung, mit JSP, Servlets und einen Java-Kern.
Typischer Fall ist nun das Hinzufügen von irgendwelchen Daten.
Dafür gibts es ein HTML-Formular in den JSPs. Beispielswiese Benutzer will man hinzufügen:

<form action="/addPerson" method="post">
				<fieldset>
					<label>Benutzername:</label><br />
					<input type="text" name="accountName" value="" /> [...]

So, nun trägt der Benutzer dort folgendes ein:
Simon "die katze" Schmidt

Schickt das Formular ab, das Servlet trägt es in den Datenbestand ein. Alles top.
Wenn ich nun den Namen editieren will, dann sieht das Formular so aus:

<form action="/editPerson" method="post">
				<fieldset>
					<label>Benutzername:</label><br />
					<input type="text" name="accountName" value="Simon "die katze" Schmidt" /> [...]

Der Name wird zwar richtig im Editierfeld angezeigt, aber nach dem abschicken (würde man nichts ändern am Namen), käme beim Servlet nur noch 'Simon ' an.

Mein Gedanke wäre nun, eine Methode die ein String zu einem XHTML fähigen String macht.

<input type="text" name="accountName" value="<%=meineStringUmwandelMethode( p.getAccountName() %>" />

Dieser macht dann eben aus einem " ein &quot;

Allerdings müsste ich in den Servlet dann ja noch die Gegenmethode haben, die alles wieder umwandelt.
Das könnte ich so machen und es wäre nicht mal so großer Aufwand bei mir. Die Frage ist, ist das sauber, macht man das so?

 

[Tomate_Salat]

der Benutzer muss dann doch in einer Datenbank o.ä. gespeichert werden (nehme ich mal an). Wieso dem ganzen nicht ein ID-Feld (bei mir ist das ganz einfach immer der primary key in der mysql) geben, über den der Benutzer eindeutig idendifiziert werden kann?

 

[dflasjjs]

Wenn ich das mache, dann muss im Value-Feld doch trotzdem der Wert stehen und nicht die ID, ich will in dem Editierfeld ja nicht "12" stehen haben, sondern den Namen, den er vorher auch eingetragen hat.

 

[Tomate_Salat]

verstehe das Problem nicht: wenn da 12 drin steht, dann hast du eine einfache Idendifizierung unabhängig von seinen Daten, dem Benutzer kanns egal sein, was im Valuefeld steht.
Ich für das mal ein bisschen ins extreme: Du hinterlegst doch auch nicht das Passwort auf der Seite, um es danach editieren zu können.

 

[dflasjjs]

Ich glaube wir reden irgendwie aneinander vorbei.
Die Identifizierung brauch ich gar nicht, das war oben ein Sonderfall, dadurch bin ich überhaupt auf das grundsätzliche Problem aufmerksam geworden und das besteht ja fernab von der Identifizierung, in allen Textfeldern.

Zum Editiervorgang: Im Prinzip mache ich es genau so. Beim Passwort jetzt nicht, weil das ja eh nicht im Klartext vorliegt, aber bei allen anderen Feldern, dort lade ich die Daten aus dem Java-Kern und schreibe sie als Value-Attribut ins Textfeld, so dass der Benutzer seine vorher eingegebenen Daten verändern kann.

 

[Tomate_Salat]

mal ein Paar hintergrundfragen:
a) Gibt es eine Benutzerdatenbank?
b) gibt es mehrere Benutzer?
c) if(a == true) welche art von Benutzerdatenbank gibt es?

 

[dflasjjs]

a) nein
b) ja

Alle Benutzer werden in einem Vector gespeichert und für die persistente Datenspeicherung als XML serialisiert.

 

[Tomate_Salat]

Ah mist, jetzt hab ich dein Problem kapiert :autsch:

Allerdings müsste ich in den Servlet dann ja noch die Gegenmethode haben, die alles wieder umwandelt.
Das könnte ich so machen und es wäre nicht mal so großer Aufwand bei mir. Die Frage ist, ist das sauber, macht man das so?

Ich wüsste nichts was dagegen sprechen sollte. Aber generell würde ich mir überlegen, ob ich solche Sonderzeichen überhaupt zulassen würde als Eingabe. Ich kenne jetzt z.b. niemanden der [c]"[/c] in seinem namen hat.

 

[dflasjjs]

Ah mist, jetzt hab ich dein Problem kapiert :autsch:

Ich wüsste nichts was dagegen sprechen sollte.

Supi

Aber generell würde ich mir überlegen, ob ich solche Sonderzeichen überhaupt zulassen würde als Eingabe. Ich kenne jetzt z.b. niemanden der [c]"[/c] in seinem namen hat.

Im Namen jetzt nicht, aber Benutzernamen war ja nur ein Beispiel von vielen. Ich habe auch viele Kommentarfelder usw. in der Anwendung, da macht sowas durchaus sinn.

 

[Antoras]

Es gibt nur eine Möglichkeit, wie du 100%ig sicher gehen kannst, dass keine Fehleingaben gespeichert werden: Du musst jedes Zeichen der Eingaben, wie aber bereits gesagt, auf Gültigkeit überprüfen.

D.h. wenn du nicht willst, dass später in deinem XML- oder HTML-Dokument irgendwelche Sonderzeichen ausgegeben werden, musst du diese maskieren. Eine Möglichkeit wäre bspw. für das Zeichen

"

das HTML-Metazeichen

"

zu verwenden. Schon hättest du ein Problem weniger. Oder aber du sorgst dafür, dass bei den Zeichen die Escape-Sequenz

\

davor gestellt wird.

Später, wenn du vorhast auf eine Datenbank umzusteigen, benötigst du sowieso Funktionen, die Zeichen mit einer besonderen Bedeutung ersetzen, da man die DB von außen zu einfach manipulieren kann. Google mal nach dem Stichwort Code-Injection. Da die Injections aber auch ohne DB auftreten können, führt kein Weg an der Zeichenüberprüfung vorbei, auch wenn es lästig erscheint. Aber sind die Funktionen dafür erst einmal gecodet, brauchst dir darum keine Gedanken mehr machen.

 

[rambozola]

[c]value='Sahne "Spezial" Schnitzel'[/c]
müsste auch funktionieren. Wie valide das ist, da bin ich mir aber nicht sicher^^

Es ist zumindest kein valides XML (also XHTML). Immer schön [c]<tag key="value" />[/c] verwenden

Jup bezweifel dass das bei reinem xml funktionieren würde,bei html geht das aber glaub ich. Aber ist ja auch egal. Bezweifel dass das valide ist, denke eher dass hier html zu großzügig ist. Mit dem von dir (faetzminator) beschrieben Syntax ist man aber auf der sicheren Seite, also empfehlenswert eher den zu nehmen ;-)

Natürlich ist das well-formed XML, mit Validität hat das allerdings nichts zu tun...

 

[dflasjjs]

Es gibt nur eine Möglichkeit, wie du 100%ig sicher gehen kannst, dass keine Fehleingaben gespeichert werden: Du musst jedes Zeichen der Eingaben, wie aber bereits gesagt, auf Gültigkeit überprüfen.

Jau, ich habe nun auch gemacht, alle numerischen Werte hatte ich eh durch so eine Methode gehauen. Für alle anderen Werte hab ich ebenfalls eine erstellt, damit bin ich relativ flexibel.