Versenden von <option value='<' />
Peter
- formulare
0 Gunnar Bittersmann0 quincunx0 hingucker1 dedlfix
Ich verwende folgenden Code:
<input name='address' maxlength='255' size='45' type='text' list='listofname' />";
<datalist id='listofname'>
<option value='irgendwer <irgendwer@gmx.de>' />";
</datalist>
Nach dem Versenden steht im $_REQUEST[address] nur der value bis ausschließlich '<'. Auch die Maskierung mit < oder die Nichtmaskierung bringen keine Änderung. Wie kann ich '<' im Formular versenden?
Für Hilfe danke ich Voraus Peter
@@Peter
Wie kann ich '<' im Formular versenden?
Prozent-escapet %3c
?
LLAP 🖖
Prozent-escapet
%3c
?
Danke für die Antwort - funktioniert aber nicht, da im Input-Feld sollte schon das richtige Zeichen, also (<) dargestellt werden sollte.
Peter
Hallo Peter,
Danke für die Antwort - funktioniert aber nicht, da im Input-Feld sollte schon das richtige Zeichen, also (<) dargestellt werden sollte.
Ich vermute, dass das nur bei der Übertragung per get
passiert. Umstellung auf post
könnte eine Alternative sein. Falls nicht, müsstest du vor dem Absenden mit JavaScript den Inhalt des input-Elements mit encodeURIComponent()
behandeln. Allerdings taucht in der MDN-Beschreibungsseite das Zeichen <
nicht als ersetzungswürdig auf. Zudem hättest du ggf. ein Problem, denn JavaScript lässt sich manipulieren. Deshalb hier die Frage: Ist das HTML valide?
Bis demnächst
Matthias
Ich vermute, dass das nur bei der Übertragung per
get
passiert. Umstellung aufpost
könnte eine Alternative sein.
Hallo Matthias, method ist POST.
Deshalb hier die Frage: Ist das HTML valide?
Leider nein - da gab's einiges zu meckern (doctype, sowie meta-Daten):
<!doctype html public '-//W3C//DTD XHTML 1.1//EN'>
<html>
<head>
<title>Peter Schmuck</title>
<link rel='stylesheet' type='text/css' href='text.css'></link>
<meta http-equiv='Content-Script-Type' content='text/javascript' />
<meta http-equiv="cache-control" content="no-cache" />
<meta name='author' content='Peter Schmuck' />
<meta name='copyright' content='© 2015 by Peter Schmuck' />
<meta name="robots" content="index, follow" />
<meta name="keywords" content="Peter, Schmuck" />
<meta name="description" content="Peter Schmuck" />
<script type='text/javascript' src='function.js'>
</script>
</head>
@@Peter
Deshalb hier die Frage: Ist das HTML valide?
Leider nein - da gab's einiges zu meckern (doctype, …):
<!doctype html public '-//W3C//DTD XHTML 1.1//EN'>
DOCTYPE
und PUBLIC
müssen groß geschrieben werden; außerdem fehlt am Ende "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
.
<html>
Die Namensraum-Angabe fehlt.
sowie meta-Daten
Die meta
-Angaben sind nicht falsch. Einige aber nicht sinnvoll oder mit wenig sinnvollen Werten.
Es ist aber überhaupt nicht sinnvoll, XHTML 1.1 zu verwenden. Verwende HTML5!
LLAP 🖖
@@Peter
<input name='address' maxlength='255' size='45' type='text' list='listofname' />"; <datalist id='listofname'> <option value='irgendwer <irgendwer@gmx.de>' />"; </datalist>
und wie ist es damit
<input name="address" maxlength="255" size="45" type="text" list="listofname" placeholder="Bitte auswählen">
<datalist id="listofname">
<option value="irgendwer <irgendwer@gmx.de>">
<option value="anderer <anderer@gmx.de>">
</datalist>
gr qx
<input name="address" maxlength="255" size="45" type="text" list="listofname" placeholder="Bitte auswählen"> <datalist id="listofname"> <option value="irgendwer <irgendwer@gmx.de>"> <option value="anderer <anderer@gmx.de>"> </datalist>
Der String wird wie gehabt nach dem Versenden abgeschnitten.
@@quincunx
und wie ist es damit
<option value="irgendwer <irgendwer@gmx.de>">
Das schrieb Peter doch schon:
Auch die Maskierung mit < … bring[t] keine Änderung.
Ein Browser, für den <
, <
und <
nicht dasselbe wären, wäre sehr kaputt.
LLAP 🖖
<option value='irgendwer <irgendwer@gmx.de>' />";
Nach dem Versenden steht im $_REQUEST[address] nur der value bis ausschließlich '<'.
Das guck Dir mal ein bischen genauer an. Relevant ist Form-Attribute enctype= was steht denn da bei Dir?
Method ist egal, ob POST, odr GET, in jedem Fall macht der Browser ein Percent-Encoding. Im Fall JS musst Du dich selbst um das encoding kümmern oder es übernimmt JQuery.serialize().
Was serverseitig passiert, stellen wir mal zurück, mach nun mal folgendes:
Dann schauen wir mal weiter. MfG
Das guck Dir mal ein bischen genauer an. Relevant ist Form-Attribute enctype= was steht denn da bei Dir?
enctype='multipart/form-data' - da ich auch files versenden will.
Method ist egal, ob POST, odr GET, in jedem Fall macht der Browser ein Percent-Encoding.
mach nun mal folgendes:
- entferne Alle Attribute Deines Form-Element
- klicke Submit-Button
- teile uns hier mit, was danach in der Adresszeile des Browsers steht
Was soll denn das? - wenn ich POST verwende, wird da die Adresse stehen, bei GET noch der Name und der Wert des Submit-Buttons hinter dem '?'.
hi,
- entferne Alle Attribute Deines Form-Element
- klicke Submit-Button
- teile uns hier mit, was danach in der Adresszeile des Browsers steht
Was soll denn das?
Da wäre der Test gewesen, ob Du verstanden hast, was der Browser bei einem Submit macht und ob Du verstanden hast, was ohne Attribute als Default gesetzt wird. Kleiner Hinweis; steht alles im wiki.
Tach!
Ich verwende folgenden Code:
<input name='address' maxlength='255' size='45' type='text' list='listofname' />"; <datalist id='listofname'> <option value='irgendwer <irgendwer@gmx.de>' />"; </datalist>
Nach dem Versenden steht im $_REQUEST[address] nur der value bis ausschließlich '<'.
Bei mir steht der Text vollständig drin. Einfach so. Und da muss auch nicht mit irgendwelchen Methoden am Client gezaubert werden.
Wie kann ich '<' im Formular versenden?
Deine Frage ist vermutlich eher, wie man solche Zeichen im HTML-Umfeld anzeigen lassen kann: Indem man sie kontextgerecht maskiert.
echo htmlspecialchars($_REQUEST['address']);
dedlfix.
Bei mir steht der Text vollständig drin. Einfach so. Und da muss auch nicht mit irgendwelchen Methoden am Client gezaubert werden.
Vielleicht liegt es tatsächlich an meinen Meta-Data im Header. Ich werde mal verschiedene charsets ausprobieren.
Deine Frage ist vermutlich eher, wie man solche Zeichen im HTML-Umfeld anzeigen lassen kann: Indem man sie kontextgerecht maskiert.
echo htmlspecialchars($_REQUEST['address']);
Nein, das war nicht meine Frage. Habe schon htmlspecialchars() probiert. Maskiert ja nicht anders, als wenn ich per Hand < schreibe.
Tach!
Bei mir steht der Text vollständig drin. Einfach so. Und da muss auch nicht mit irgendwelchen Methoden am Client gezaubert werden.
Vielleicht liegt es tatsächlich an meinen Meta-Data im Header. Ich werde mal verschiedene charsets ausprobieren.
Zeichenkodierungen sind, soweit ich das bisher sehe, kein Teil des Problems.
Deine Frage ist vermutlich eher, wie man solche Zeichen im HTML-Umfeld anzeigen lassen kann: Indem man sie kontextgerecht maskiert.
echo htmlspecialchars($_REQUEST['address']);
Nein, das war nicht meine Frage. Habe schon htmlspecialchars() probiert. Maskiert ja nicht anders, als wenn ich per Hand < schreibe.
Du kannst vielleicht in Literale im Code per Hand Maskierungen schreiben, aber du kannst nicht in einem laufenden Programm Daten während der Verarbeitung per Hand ändern. (Das heißt, das kannst du schon, wenn du einen Debugger hast und das Programm an einem Breakpoint anhältst. Das ist aber im PHP-Umfeld nicht üblich.)
Es geht darum, das was du in $_REQUEST stehen hast, auf den Bildschirm zu bekommen, und zwar so, dass dabei keine Zeichen vom Browser fehlinterpretiert werden und dir so der Eindruck entsteht, dass da Teile von den Daten abgeschnitten werden. In deinem Fall verschwindet nämlich nichts, jedenfalls nicht, wenn ich die Puzzleteile deiner Problembeschreibung soweit ergänze, dass eine nachvollziehbare Testumgebung entstehen kann.
Du kannst das htmlspecialchars() auch weglassen und stattdessen in die Quelltextansicht des Browsers schauen, wenn du meinst, dass htmlspecialchars() nicht die Lösung deines Problems ist. Andererseits kannst du auch ein vollständig nachvollziehbares Beispiel des Problems liefern, dann kann man vielleicht erkennen, wo der Fehler wirklich sitzt.
dedlfix.
[Vollzitat]
Hallo dedlix,
jetzt habe ich es verstanden und voila - das war tatsächlich die Lösung.
Vielen Dank
Peter