¿Qué caracteres se permiten en el atributo de nombre HTML dentro de la etiqueta de entrada?


83

Tengo un script PHP que generará <input>s dinámicamente, así que me preguntaba si necesitaba filtrar algún carácter en el nameatributo.

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

Respuestas:


28

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

"El método" get "restringe los valores del conjunto de datos del formulario a caracteres ASCII". referencia

Hay un buen hilo aquí .


Entonces, ¿ nametiene un tipo de datos diferente <input>al que tiene para otros elementos? Interesante.
DLH

Es el mismo <a>y la mayoría de los elementos, pero diferente a<meta>
Alohci

4
Sí. Intenté <input>con todo tipo de tonterías en el nameatributo y se validó en HTML 4.01 Strict. ¡Aceptado!
DLH

twitter usa este tipo de nombre, cualquier razón especial para obtener alguna publicidad ...... usuario [user_password], usuario [email]
Vishal Sharma

"La única restricción real sobre los caracteres que pueden aparecer en los nombres de control de formulario es cuando se envía un formulario con GET" - No. Eso no restringe lo que puede aparecer en el nombre, solo significa que debe estar codificado en URL cuando se convierte a una URL.
Quentin

54

Tenga en cuenta que no todos los caracteres se envían para los nameatributos 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, así como el carácter, .se reemplazan por _. (Probado en Chrome 23, Firefox 13 e Internet Explorer 9, todos Win7).


11
Gracias por agregar este aviso, amigo. Estaba a punto de empezar a codificar usando. como separador.
Davis Peixoto

1
El espacio en blanco interno se reemplaza por el signo más (+) de acuerdo con esta página: w3schools.com/tags/tryit.asp?filename=tryhtml_form_submit
thdoan

1
Yo segundo @Dave. Para aquellos que estaban pensando lo mismo, probablemente estén buscando entradas de estilo matriz: en first[second]lugar de first.second.
JD

5
Me gustaría señalar que esto es algo específico del servidor, no 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.
Abluejelly

3
Vea el comentario de @Aleksander, a continuación. Algunos servidores pueden convertir '.' a '_', pero no sucede en el navegador.
Jeff Lowery

38

Cualquier carácter 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 que contieneCDATA , por lo que lo único que no puede poner allí 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 el método "post" (con enctype = "multipart / form-data") se especifica para cubrir todo el conjunto de caracteres ISO10646.

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

La teoría es que los application/x-www-form-urlencodeddatos 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 en cualquiera de los dos "no se especifica" como funciona y debe usar POSTedmultipart/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 hacerlo, en los encabezados de subparte de un multipart/form-data cuerpo solicitud POST. (Creo que Mozilla intentó implementarlo una vez, pero se echó atrás porque rompió los servidores).

Y ningún navegador implementa lo asombrosamente complejo y feo estándar RFC2231 que sería necesario para insertar nombres de campo codificados que no sean ASCII en los encabezados de las subpartes de varias partes. En cualquier caso, la especificación HTML que define multipart/form-datano 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 valores que contienen caracteres no ASCII es lo mismo para GET y ambos tipos de formulario POST: los codifica usando 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 de otros elementos?

En realidad, el único elemento cuyo nameatributo no CDATAes <meta>. Consulte la lista de atributos de la especificación HTML4 para conocer 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ía, nameexcepto 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. Se debe evitar el uso de la vieja escuela de namepara identificar elementos como <form>o <a>en la página (usar iden su lugar).


9

Si bien el comentario de Allain respondió la pregunta directa de OP y bobince brindó información brillante en profundidad, creo que muchas personas vienen aquí buscando 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 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 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 punto tal como están (hablando de datos POST)! Puede comprobarlo en las herramientas de desarrollo de cualquier navegador decente.

Por favor, observe ese pequeño comentario de abluejelly, que probablemente muchos se pierden:

Me gustaría señalar que esto es algo específico del servidor, no 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 HTTP Apache (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 provocar algunos comportamientos inesperados según el servidor HTTP utilizado .


¿lo que pasa? Si uso name = "foo bar".
squal

0

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

Si es así, me sentirí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 ataques XSS, etc.

Además, ¿por qué dejar que el usuario controle cualquier aspecto de la etiqueta de entrada? (Puede que, en última instancia, no sea 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).


Puede que no termine teniendo mis nombres generados de esta manera. Estoy en el proceso de tratar de pensar en formas de permitir que los miembros menos expertos en tecnología de mi oficina especifiquen campos de formulario.
DLH

@DLH Me sentiría tentado (para eliminar el riesgo de conflictos de nombres, etc.) a un enfoque intermedio como el anterior. :-)
John Parker
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.