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 name
CDATA
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
).
Entonces 'nombre' tiene un tipo de datos diferente para' 'que para otros elementos? Interesante. – DLH
Es lo mismo que '' y la mayoría de los elementos, pero es diferente de '' – Alohci
Sí. Acabo de probar un '' con todo tipo de basura en el atributo 'name', y se validó en HTML 4.01 Strict. ¡Aceptado! – DLH