Pregunta ¿Qué caracteres están permitidos en el atributo Nombre HTML dentro de la etiqueta de entrada?


Tengo un script PHP que generará <input>s dinámicamente, por lo que me preguntaba si necesitaba filtrar los caracteres en el name atributo.

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


74
2017-08-06 14:43


origen


Respuestas:


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" get "restringe los valores del conjunto de datos de formulario a caracteres ASCII". referencia

Hay un buen hilo en esto aquí.


28
2017-08-06 14:56



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 del espacio en blanco se recortan y los caracteres del espacio en blanco interno, así como el personaje . son reemplazados por _. (Probado en Chrome 23, Firefox 13 e Internet Explorer 9, todos en Win7).


47
2017-12-13 11:15



Cualquier personaje que pueda incluir en un archivo HTML [X] está bien para ponerlo en un <input name>. Como dice el comentario de Allain, <input name> se define como conteniendo CDATA, por lo que lo único que no puede poner ahí 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ó a W3 de la especificación HTML4:

Nota. El método "get" restringe los valores del conjunto de datos de formulario a caracteres ASCII. Solo el método "publicar" (con enctype = "multipart / form-data") se especifica 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 los datos no tienen 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 es "no especificado" y debe usar POSTed multipart/form-data en lugar.

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

Y ningún navegador implementa lo asombrosamente 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 partes múltiples. En cualquier caso, la especificación HTML que define multipart/form-data no dice directamente que debería usarse RFC2231, y, de nuevo, rompería servidores si lo intentaras.

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

DLH:

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

En realidad, el único elemento cuya name 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, típicamente 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). Eso es 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 ser evitado (uso id en lugar).


37
2017-08-06 15:47



Mientras que el comentario de Allain respondió a la pregunta directa de OP y Bobince brindó información brillante y profunda, creo que mucha gente viene aquí buscando 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 surgió 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 no es cierto. No sé si el navegador realmente realizó este tipo de operación en 2013, aunque lo dudo. Los navegadores envían caracteres de punto como están (¡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 no entiendan:

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

Lo comprobé 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 es reemplazado por _!

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


4
2018-03-19 20:05



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

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

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


0
2017-08-06 14:49