2010-08-06 34 views
73

Tengo un script PHP que generará <input> s dinámicamente, por lo que me preguntaba si necesitaba filtrar cualquier carácter en el atributo name.¿Qué caracteres están permitidos en el atributo Nombre de HTML dentro de la etiqueta de entrada?

Sé que el nombre tiene que comenzar con una letra, pero No conozco ninguna otra regla. 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?

Respuesta

27

La única restricción real sobre los caracteres que pueden aparecer en 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." reference

Hay un buen hilo en él here.

+0

Entonces 'nombre' tiene un tipo de datos diferente para' 'que para otros elementos? Interesante. – DLH

+4

Sí. Acabo de probar un '' con todo tipo de basura en el atributo 'name', y se validó en HTML 4.01 Strict. ¡Aceptado! – DLH

0

¿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.), aunque solo sea para limitar el potencial de exploits XSS, etc.

Además, ¿por qué permitir que el usuario controle cualquier aspecto de la etiqueta de entrada? (Podría no ser más fácil desde el punto de vista 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

Puede que no termine generando mis nombres 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

+0

@DLH Me sentiría tentado (para eliminar el riesgo de conflictos de nombres, etc.) a solo un enfoque intermedio como el anterior. :-) –

36

Cualquier caracter que pueda incluir en un archivo HTML [X] está bien para ponerlo en <input name>. Como dice el comentario de Allain, <input name> se define como que contiene CDATA, 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 citado W3 de la especificación HTML 4:

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 muy cierto en la práctica.

La teoría es que application/x-www-form-urlencoded de datos no tiene un mecanismo para especificar una codificación de nombres o valores del formulario, por lo que el uso de caracteres no ASCII en cualquiera está “no especificado” como trabajar y se debe utilizar publicado multipart/form-data 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 las subpartes de un cuerpo de solicitud POST multipart/form-data. (Creo que Mozilla intentó implementarlo una vez, pero se retiró porque se rompió el servidor.)

Y ningún navegador implementa el estándar RFC2231 asombrosamente complejo y feo que sería necesario para insertar nombres codificados de campos no ASCII en la subparte de las partes múltiples encabezados 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 los servidores si lo intentara.

Así que la realidad de la situación es que no hay manera de saber qué codificación se está utilizando para los nombres y valores en un envío de formulario, sin importar de qué tipo 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:

Así nombre tiene un tipo de datos diferente para lo que lo hace para otros elementos?

En realidad el único elemento cuyo atributo no es nameCDATA es <meta>. Consulte las especificaciones de HTML4 en attribute list 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 estos días evitaría 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. Se debe evitar el uso de name de la vieja escuela para identificar elementos como <form> o <a> en la página (en su lugar, use id).

45

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

+8

Gracias por agregar este aviso, amigo. Estaba a punto de comenzar a codificar usando. como un separador – Dave

+0

probé en mozilla pero no pude obtener los valores del campo de entrada con espacio en blanco en él ... significa que no está recortado ... –

+1

El espacio en blanco interno se reemplaza por el signo más (+) según esta página: http : //www.w3schools.com/tags/tryit.asp? filename = tryhtml_form_submit – 10basetom

2

Mientras que el comentario de Allain respondió a la pregunta directa de OP y Bobince proporcionó información brillante y exhaustiva, creo que muchas personas vienen aquí buscando respuestas a más pregunta 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:

carácter. son reemplazados por _

Esto no es verdad. 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, observe ese pequeño comentario de abluejelly, que probablemente se perdió por muchos:

me gustaría tener en cuenta que esto es una cosa específica del servidor, no es una cosa 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 en función del servidor HTTP utilizado.

Cuestiones relacionadas