Quels caractères sont autorisés dans l'attribut Nom HTML à l'intérieur de la balise d'entrée?
J'ai un script PHP qui générera <input>s dynamiquement, donc je me demandais si j'avais besoin de filtrer les caractères de l'attribut name.
Je sais que le nom doit commencer par une lettre, mais Je ne connais pas d'autre règle. Je suppose que les crochets doivent être autorisés, car PHP les utilise pour créer des tableaux à partir des données du formulaire. Que diriez-vous des parenthèses? Des espaces?
Notez que tous les caractères ne sont pas soumis pour les attributs name des champs de formulaire (même lorsque vous utilisez POST)!
Les caractères blancs sont rognés et les caractères blancs intérieurs ainsi que le caractère . sont remplacés par _. (Testé dans Chrome 23, Firefox 13 et Internet Explorer 9, tous Win7.)
N'importe quel caractère que vous pouvez inclure dans un fichier HTML [X] peut être placé dans un <input name>. Comme le dit le commentaire d'Allain, <input name> est défini comme contenant CDATA, donc les seules choses que vous ne pouvez pas y mettre sont les codes de contrôle et les points de code invalides que la norme sous-jacente (SGML ou XML) interdit.
Allain a cité W3 de la spécification HTML4:
Remarque. La méthode "get" limite les valeurs du jeu de données de formulaire à ASCII. Seule la méthode "post" (avec enctype = "multipart/form-data") est spécifiée pour couvrir l'ensemble du jeu de caractères ISO10646 .
Cependant, ce n'est pas vraiment vrai dans la pratique.
La théorie est que application/x-www-form-urlencoded les données n'ont pas de mécanisme pour spécifier un encodage pour les noms ou les valeurs du formulaire, donc utiliser des caractères non-ASCII dans les deux n'est pas spécifié comme fonctionnant et vous devez utiliser POSTed multipart/form-data au lieu.
Malheureusement, dans le monde réel, aucun navigateur ne spécifie un codage pour les champs, même s'il le pourrait théoriquement, dans les en-têtes de sous-parties d'un multipart/form-data POST corps de la requête. (Je crois que Mozilla a essayé de l'implémenter une fois, mais a fait marche arrière car il a cassé les serveurs.)
Et aucun navigateur n'implémente la norme étonnamment complexe et laide RFC2231 qui serait nécessaire pour insérer des noms de champ non ASCII codés dans les en-têtes de sous-parties du multipart. Dans tous les cas, la spécification HTML qui définit multipart/form-data ne dit pas directement que le RFC2231 doit être utilisé et, encore une fois, cela briserait les serveurs si vous essayiez.
Donc, la réalité de la situation est qu'il n'y a aucun moyen de savoir quel codage est utilisé pour les noms et les valeurs dans une soumission de formulaire, quel que soit le type de formulaire. Ce que les navigateurs feront avec les noms de champ et les valeurs qui contiennent des caractères non ASCII est le même pour GET et les deux types de formulaire POST: il les encode en utilisant l'encodage de la page contenant le formulaire utilisé. Non -Les noms des formulaires GET ASCII ne sont pas plus cassés que tout le reste.
DLH:
Le nom a donc un type de données différent de celui des autres éléments?
En fait, le seul élément dont l'attribut name n'est pas CDATA est <meta>. Voir la spécification HTML4 liste d'attributs pour toutes les différentes utilisations de name; c'est un nom d'attribut surchargé, ayant de nombreuses significations différentes sur les différents éléments. Ceci est généralement considéré comme une mauvaise chose.
Cependant, ces jours-ci, vous éviterez généralement name sauf dans les champs de formulaire (où il s'agit d'un nom de contrôle) et param (où il s'agit d'un identificateur de paramètre spécifique au plugin). Ce n'est que deux significations à saisir. L'utilisation à l'ancienne de name pour identifier des éléments comme <form> ou <a> sur la page doit être évité (utilisez plutôt id).
Bien que le commentaire d'Allain ait répondu à la question directe d'OP et que Bobince ait fourni de brillantes informations approfondies, je pense que de nombreuses personnes viennent ici chercher une réponse à une question plus spécifique: "Puis-je utiliser un caractère point dans l'attribut de nom d'entrée du formulaire?"
Comme ce fil est apparu comme premier résultat lorsque j'ai recherché cette connaissance, je suppose que je pourrais aussi bien partager ce que j'ai trouvé.
Premièrement, Matthias 'a affirmé que:
personnage . sont remplacés par _
C'est faux. Je ne sais pas si le navigateur a réellement fait ce genre d'opération en 2013 - cependant, j'en doute. Les navigateurs envoient des caractères point tels quels (en parlant de POST données)! Vous pouvez le vérifier dans les outils de développement de tout navigateur décent.
S'il vous plaît, notez ce petit petit commentaire de abluejelly, qui manque probablement à beaucoup:
Je voudrais noter que c'est une chose spécifique au serveur, pas un navigateur. Testé sur Win7 FF3/3.5/31, IE5/7/8/9/10/Edge, Chrome39 et Safari Windows 5, et tous ont envoyé "test this.stuff" (quatre espaces de tête) comme nom dans POST au serveur de développement ASP.NET fourni avec VS2012.
Je l'ai vérifié avec le serveur HTTP Apache (v2.4.25) et en effet le nom d'entrée comme "foo.bar" est changé en "foo_bar". Mais dans un nom comme "foo [foo.bar]", ce point n'est pas remplacé par _!
Ma conclusion: Vous pouvez utiliser des points mais je ne l'utiliserais pas car cela peut conduire à des comportements inattendus selon le serveur HTTP utilisé.
Voulez-vous dire les attributs id et name de la balise d'entrée HTML?
Si c'est le cas, je serais très tenté de restreindre (ou convertir) les caractères de nom "d'entrée" autorisés en az (AZ), 0-9 et une plage de ponctuation limitée (".", ",", Etc.), ne serait-ce que pour limiter le potentiel d'exploits XSS, etc.
De plus, pourquoi laisser l'utilisateur contrôler n'importe quel aspect de la balise d'entrée? (Cela ne serait-il pas finalement plus facile du point de vue de la validation de conserver les noms des balises d'entrée "custom_1", "custom_2", etc., puis de les mapper selon les besoins.)