HTML: Zeichen für Namensattribut des Eingabeelements erlaubt?

Ich habe ein PHP-Skript, das generiert wird <input>s dynamisch, also habe ich mich gefragt, ob ich irgendwelche Zeichen in filtern muss name Attribut.

Ich weiß, dass der Name mit einem Buchstaben beginnen muss, aber Andere Regeln kenne ich nicht. Ich denke, eckige Klammern müssen erlaubt sein, da PHP diese verwendet, um Arrays aus Formulardaten zu erstellen. Wie wäre es mit Klammern? Leerzeichen?

Beachten Sie, dass nicht alle Zeichen eingereicht werden name Attribute von Formularfeldern (auch bei Verwendung von POST)!

Leerzeichen werden getrimmt und innere Leerzeichen sowie das Zeichen . werden ersetzt durch _. (Getestet in Chrome 23, Firefox 13 und Internet Explorer 9, alle Win7.)

Jedes Zeichen, das Sie in eine einfügen können [X]Eine HTML-Datei kann problemlos eingefügt werden <input name>. Wie Allains Kommentar sagt, <input name> wird als enthaltend definiert CDATAalso sind die einzigen Dinge, die Sie dort nicht einfügen können, die Steuercodes und ungültigen Codepunkte, die der zugrunde liegende Standard (SGML oder XML) nicht zulässt.

Allain zitiert W3 aus der HTML4-Spezifikation:

Notiz. Die “get”-Methode beschränkt Formulardatensatzwerte auf ASCII-Zeichen. Nur die “post”-Methode (mit enctype=”multipart/form-data”) ist spezifiziert, um den gesamten ISO10646-Zeichensatz abzudecken.

Allerdings stimmt das in der Praxis nicht wirklich.

Die Theorie ist das application/x-www-form-urlencoded data hat keinen Mechanismus, um eine Codierung für die Namen oder Werte des Formulars anzugeben, daher ist die Verwendung von Nicht-ASCII-Zeichen in beiden „nicht angegeben“ als funktionierend und Sie sollten POSTed verwenden multipart/form-data stattdessen.

Leider gibt in der realen Welt kein Browser eine Codierung für Felder an, selbst wenn dies theoretisch möglich wäre, in den Unterabschnitts-Headern von a multipart/form-data POST-Anforderungstext. (Ich glaube, Mozilla hat einmal versucht, es zu implementieren, hat sich aber zurückgezogen, als es Server kaputt machte.)

Und kein Browser implementiert das erstaunlich Komplexe und Hässliche RFC2231 Standard, der erforderlich wäre, um codierte Nicht-ASCII-Feldnamen in die Subpart-Header des Multiparts einzufügen. In jedem Fall definiert die HTML-Spezifikation multipart/form-data sagt nicht direkt, dass RFC2231 verwendet werden sollte, und wiederum würde es Server beschädigen, wenn Sie es versuchen würden.

Die Realität ist also, dass es keine Möglichkeit gibt, zu wissen, welche Codierung für die Namen und Werte in einer Formularübermittlung verwendet wird, unabhängig davon, um welche Art von Formular es sich handelt. Was Browser mit Feldnamen und Werten tun, die Nicht-ASCII-Zeichen enthalten, ist für GET und beide Arten von POST-Formularen gleich: Sie werden mit der Codierung der Seite codiert, die das verwendete Formular enthält. Nicht-ASCII-GET-Formularnamen sind nicht mehr beschädigt als alles andere.

DLH:

Name hat also einen anderen Datentyp als für andere Elemente?

Eigentlich das einzige Element, dessen name Attribut ist es nicht CDATA Ist <meta>. Siehe die HTML4-Spezifikationen Attributliste für all die verschiedenen Verwendungen von name; Es ist ein überladener Attributname, der viele verschiedene Bedeutungen für die verschiedenen Elemente hat. Dies wird im Allgemeinen als eine schlechte Sache angesehen.

Heutzutage würden Sie dies jedoch normalerweise vermeiden name außer bei Formularfeldern (wo es sich um einen Steuerelementnamen handelt) und param (wobei es sich um eine Plugin-spezifische Parameterkennung handelt). Das sind nur zwei Bedeutungen, mit denen man sich auseinandersetzen muss. Der Old-School-Gebrauch von name zum Identifizieren von Elementen wie <form> oder <a> auf der Seite sollte vermieden werden (use id stattdessen).

Die einzige wirkliche Einschränkung, welche Zeichen in Namen von Formularsteuerelementen erscheinen dürfen, ist, wenn ein Formular mit GET gesendet wird

“Die “get”-Methode beschränkt Formulardatensatzwerte auf ASCII-Zeichen.” Referenz

Es gibt einen guten Thread dazu Hier.

Während Allains Kommentar die direkte Frage von OP beantwortete und Bobince einige brillante, detaillierte Informationen lieferte, glaube ich, dass viele Leute hierher kommen, um eine Antwort auf eine spezifischere Frage zu erhalten: „Kann ich einen Punkt im Namensattribut des Formulars verwenden?“

Da dieser Thread als erstes Ergebnis auftauchte, als ich nach diesem Wissen suchte, dachte ich, ich könnte genauso gut teilen, was ich gefunden habe.

Erstens behauptete Matthias, dass:

Charakter . werden ersetzt durch _

Das ist falsch. Ich weiß nicht, ob Browser diese Art von Operation im Jahr 2013 tatsächlich durchgeführt haben – aber ich bezweifle das. Browser senden Punktzeichen so wie sie sind (bei POST-Daten)! Sie können es in den Entwicklertools jedes anständigen Browsers überprüfen.

Bitte beachten Sie diesen winzigen Kommentar von abluejelly, der wahrscheinlich von vielen übersehen wird:

Ich möchte darauf hinweisen, dass dies eine serverspezifische Sache ist, keine Browsersache. Getestet auf Win7 FF3/3.5/31, IE5/7/8/9/10/Edge, Chrome39 und Safari Windows 5, und alle haben „test this.stuff“ (vier führende Leerzeichen) als Namen im POST an gesendet der mit VS2012 gebündelte ASP.NET-Entwicklungsserver.

Ich habe es mit dem Apache HTTP-Server (v2.4.25) überprüft und tatsächlich wurde der Eingabename wie “foo.bar” in “foo_bar” geändert. Aber bei einem Namen wie „foo[foo.bar]” dieser Punkt wird nicht durch _ ersetzt!

Meine Schlussfolgerung: Sie können Punkte verwenden, aber ich würde es nicht verwenden, da dies je nach verwendetem HTTP-Server zu unerwartetem Verhalten führen kann.

Meinen Sie die ID- und Namensattribute des HTML-Eingabetags?

Wenn ja, wäre ich sehr versucht, die zulässigen “Eingabe” -Namenszeichen auf nur az (AZ), 0-9 und eine begrenzte Anzahl von Satzzeichen (“.”, “,” usw.) zu beschränken (oder umzuwandeln). sei es nur, um das Potenzial für XSS-Exploits usw.

Warum sollten Sie außerdem den Benutzer einen Aspekt des Eingabe-Tags steuern lassen? (Könnte es aus Sicht der Validierung nicht letztendlich einfacher sein, die Eingabe-Tag-Namen „custom_1“, „custom_2“ usw. beizubehalten und diese dann nach Bedarf zuzuordnen.)