HTML: ¿caracteres permitidos para el atributo de nombre del elemento de entrada?

Tengo un script PHP que generará <input>s de forma dinámica, por lo que me preguntaba si necesitaba filtrar algún carácter en el name atributo.

Sé que el nombre tiene que empezar con una letra, pero No conozco otras reglas. Me imagino que se deben permitir los corchetes, ya que PHP los usa para crear matrices a partir de datos de formulario. ¿Qué hay de los paréntesis? ¿Espacios?

Tenga en cuenta que no todos los caracteres se envían para name atributos de los campos de formulario (incluso cuando se usa POST)!

Los caracteres de espacio en blanco se recortan y los caracteres de espacio en blanco internos también el carácter . son reemplazados por _. (Probado en Chrome 23, Firefox 13 e Internet Explorer 9, todos Win7).

Cualquier carácter que pueda incluir en un [X]El archivo HTML está bien para poner en un <input name>. Como dice el comentario de Allain, <input name> se define como que contiene CDATApor lo que lo único que no puede incluir son los códigos de control y los puntos de código no válidos que el estándar subyacente (SGML o XML) no permite.

Allain citó W3 de la especificación HTML4:

Nota. El método “get” restringe los valores del conjunto de datos del formulario a caracteres ASCII. Solo se especifica el método “post” (con enctype=”multipart/form-data”) para cubrir todo el juego de caracteres ISO10646.

Sin embargo, esto no es realmente cierto en la práctica.

La teoría es que application/x-www-form-urlencoded data no tiene un mecanismo para especificar una codificación para los nombres o valores del formulario, por lo que el uso de caracteres que no sean ASCII en ninguno de los dos “no se especifica” como funcional y debe usar POSTed multipart/form-data en cambio.

Desafortunadamente, en el mundo real, ningún navegador especifica una codificación para los campos, incluso cuando teóricamente podría hacerlo, en los encabezados de las subpartes de un multipart/form-data Cuerpo de solicitud POST. (Creo que Mozilla intentó implementarlo una vez, pero se retiró porque rompió los servidores).

Y ningún navegador implementa el sorprendentemente complejo y feo RFC2231 estándar que sería necesario para insertar nombres de campo codificados que no sean ASCII en los encabezados de las subpartes de las multipartes. En cualquier caso, la especificación HTML que define multipart/form-data no dice directamente que se deba usar RFC2231 y, nuevamente, rompería los servidores si lo intentara.

Entonces, la realidad de la situación es que no hay forma de saber qué codificación se está utilizando para los nombres y valores en el envío de un formulario, sin importar qué tipo de formulario sea. Lo que harán los navegadores con los nombres de campo y los valores que contienen caracteres que no son ASCII es lo mismo para GET y ambos tipos de formulario POST: los codifica utilizando la codificación de la página que contiene el formulario utilizado. Los nombres de formularios GET que no son ASCII no están más rotos que todo lo demás.

DLH:

Entonces, ¿el nombre tiene un tipo de datos diferente al que tiene para otros elementos?

En realidad, el único elemento cuyo name el atributo no es CDATA es <meta>. Ver las especificaciones de HTML4 lista de atributos para todos los diferentes usos de name; es un nombre de atributo sobrecargado, que tiene muchos significados diferentes en los diferentes elementos. Esto generalmente se considera algo malo.

Sin embargo, normalmente en estos días evitarías name excepto en los campos de formulario (donde es un nombre de control) y param (donde es un identificador de parámetro específico del complemento). Esos son solo dos significados con los que lidiar. El uso de la vieja escuela de name para identificar elementos como <form> o <a> en la página debe evitarse (utilice id en cambio).

La única restricción real sobre qué caracteres pueden aparecer en los nombres de control de formulario es cuando se envía un formulario con GET

“El método “obtener” restringe los valores del conjunto de datos del formulario a caracteres ASCII”. referencia

Hay un buen hilo sobre eso. aquí.

Si bien el comentario de Allain respondió la pregunta directa de OP y Bobince proporcionó información detallada y brillante, creo que muchas personas vienen aquí en busca de una respuesta a una pregunta más específica: “¿Puedo usar un carácter de punto en el atributo de nombre de entrada del formulario?”

Como este hilo apareció como primer resultado cuando busqué este conocimiento, supuse que también podría compartir lo que encontré.

En primer lugar, Matthias afirmó que:

personaje . son reemplazados por _

Esto es falso. No sé si el navegador realmente hizo este tipo de operación en 2013, aunque lo dudo. ¡Los navegadores envían caracteres de puntos tal como son (hablando de datos POST)! Puede verificarlo en las herramientas de desarrollo de cualquier navegador decente.

Por favor, fíjate en ese pequeño comentario de abluejelly, que probablemente muchos pasen por alto:

Me gustaría señalar que esto es una cosa específica del servidor, no una cosa del navegador. Probado en Win7 FF3/3.5/31, IE5/7/8/9/10/Edge, Chrome39 y Safari Windows 5, y todos enviaron “test this.stuff” (cuatro espacios iniciales) como nombre en POST a el servidor de desarrollo ASP.NET incluido con VS2012.

Lo verifiqué con el servidor Apache HTTP (v2.4.25) y, de hecho, el nombre de entrada como “foo.bar” se cambió a “foo_bar”. Pero en un nombre como “foo[foo.bar]”Ese punto no se reemplaza por _!

Mi conclusión: Puede usar puntos, pero yo no los usaría, ya que esto puede generar comportamientos inesperados según el servidor HTTP utilizado..

¿Te refieres a los atributos de identificación y nombre de la etiqueta de entrada HTML?

Si es así, estaría muy tentado a restringir (o convertir) los caracteres de nombre de “entrada” permitidos en solo az (AZ), 0-9 y un rango limitado de puntuación (“.”, “,”, etc.), aunque solo sea para limitar el potencial de exploits XSS, etc.

Además, ¿por qué dejar que el usuario controle cualquier aspecto de la etiqueta de entrada? (En última instancia, ¿no sería más fácil desde una perspectiva de validación mantener los nombres de las etiquetas de entrada como ‘custom_1’, ‘custom_2’, etc. y luego mapearlos según sea necesario?)