J'ai un script PHP qui va générer <input> de manière dynamique, et je me demandais donc si je devais filtrer tous les caractères dans le fichier name attribut.
Je sais que le nom doit commencer par une lettre, mais Je ne connais pas d'autres règles. Je pense que les crochets doivent être autorisés, puisque PHP les utilise pour créer des tableaux à partir de données de formulaire. Et les parenthèses ? Les espaces ?
Notez que tous les personnages ne sont pas soumis pour name des champs de formulaire (même en utilisant POST) !
Les caractères d'espace blanc sont rognés et les caractères d'espace blanc internes ainsi que le caractère . sont remplacés par _ . (Testé dans Chrome 23, Firefox 13 et Internet Explorer 9, tous sous Win7).
Tout caractère que vous pouvez inclure dans un fichier [X]HTML peut être placé dans un fichier [X]HTML. <input name> . Comme le dit le commentaire d'Allain, <input name> est défini comme contenant CDATA Les seules choses que vous ne pouvez pas y mettre sont donc les codes de contrôle et les points de code invalides que la norme sous-jacente (SGML ou XML) interdit.
Allain a cité W3 à partir de la spécification HTML4 :
Remarque. La méthode "get" limite les valeurs de l'ensemble de données du formulaire aux caractères 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 ne dispose pas d'un mécanisme permettant de spécifier un encodage pour les noms ou les valeurs du formulaire, de sorte que l'utilisation de caractères non ASCII dans l'un ou l'autre cas n'est "pas spécifiée" comme fonctionnant et vous devez utiliser POSTed multipart/form-data à la place.
Malheureusement, dans le monde réel, aucun navigateur ne spécifie un encodage pour les champs, même s'il pourrait théoriquement le faire, dans les en-têtes de sous-parties d'un fichier de type multipart/form-data Corps de la requête POST. (Je crois que Mozilla a essayé de l'implémenter une fois, mais a fait marche arrière car cela cassait les serveurs).
Et aucun navigateur ne met en œuvre l'étonnamment complexe et laid RFC2231 qui serait nécessaire pour insérer des noms de champs codés non-ASCII dans les en-têtes de sous-parties de la multipartie. Dans tous les cas, la spécification HTML qui définit la norme multipart/form-data ne dit pas directement que la RFC2231 doit être utilisée, et, encore une fois, cela casserait les serveurs si vous essayiez.
La réalité de la situation est donc qu'il n'y a aucun moyen de savoir quel est l'encodage utilisé pour les noms et les valeurs d'un formulaire soumis, quel que soit le type de formulaire. Ce que les navigateurs font avec les noms et les valeurs des champs qui contiennent des caractères non ASCII est le même pour les formulaires GET et les deux types de POST : ils les encodent en utilisant l'encodage utilisé par la page contenant le formulaire. Les noms de formulaires GET non ASCII ne sont pas plus cassés que les autres.
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 name n'est pas CDATA est <meta> . Voir l'article de la spécification HTML4 liste des attributs pour toutes les différentes utilisations de name Il s'agit d'un nom d'attribut surchargé, qui a plusieurs significations différentes selon les éléments. Ceci est généralement considéré comme une mauvaise chose.
Cependant, de nos jours, on évite généralement name sauf sur les champs de formulaire (où il s'agit du nom d'un contrôle) et sur les champs d'entrée. param (où il s'agit d'un identifiant de paramètre spécifique au plugin). Il n'y a donc que deux significations à prendre en compte. L'utilisation à l'ancienne de name pour identifier des éléments comme <form> ou <a> sur la page doit être évitée (utilisez id à la place).
La seule véritable restriction sur les caractères qui peuvent apparaître dans les noms des contrôles de formulaires est lorsqu'un formulaire est soumis avec GET
"La méthode "get" limite les valeurs de l'ensemble des données du formulaire aux caractères ASCII." référence
Il y a un bon fil de discussion à ce sujet ici .
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 de convertir) les caractères de nom "d'entrée" autorisés en seulement a-z (A-Z), 0-9 et une gamme limitée de ponctuation (".", ",", etc.), ne serait-ce que pour limiter le potentiel d'exploitation XSS, etc.
De plus, pourquoi laisser l'utilisateur contrôler un quelconque aspect de la balise d'entrée (ne serait-il pas plus simple, du point de vue de la validation, de conserver les noms de balise d'entrée "custom_1", "custom_2", etc. et de les mettre en correspondance en fonction des besoins).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
