Какие символы разрешены в атрибуте HTML Name внутри входного тега? - PullRequest
75 голосов
/ 06 августа 2010

У меня есть PHP-скрипт, который динамически генерирует <input> s, поэтому мне было интересно, нужно ли мне фильтровать какие-либо символы в атрибуте name.

Я знаю, что имя имеетначать с буквы, но я не знаю других правил.Я считаю, что квадратные скобки должны быть разрешены, так как PHP использует их для создания массивов из данных формы.Как насчет скобок?Пространства?

Ответы [ 5 ]

49 голосов
/ 13 декабря 2012

Обратите внимание, что не все символы представлены для name атрибутов полей формы (даже при использовании POST)!

Пробельные символы обрезаются и внутренние пробельные символы, а также символ . заменены на _.(Проверено в Chrome 23, Firefox 13 и Internet Explorer 9, все в Win7.)

38 голосов
/ 06 августа 2010

Любой символ, который вы можете включить в HTML-файл [X], можно поместить в <input name>. Как говорится в комментарии Аллена, <input name> определяется как содержащий CDATA, поэтому единственное, что вы не можете вставить в него, это контрольные коды и недопустимые кодовые точки, которые запрещает базовый стандарт (SGML или XML).

Аллен цитирует W3 из спецификации HTML4:

Примечание. Метод «get» ограничивает значения набора данных формы до символов ASCII. Только метод "post" (с enctype = "multipart / form-data") указан для охвата всего набора символов ISO10646.

Однако на практике это не совсем так.

Теория состоит в том, что application/x-www-form-urlencoded данные не имеют механизма для указания кодировки для имен или значений формы, поэтому использование не-ASCII символов в любом из них «не указано» как работающее, и вы должны использовать POSTed multipart/form-data вместо.

К сожалению, в реальном мире ни один браузер не определяет кодировку для полей, даже если это теоретически возможно, в заголовках подчастей тела запроса multipart/form-data POST. (Я полагаю, что Mozilla однажды пыталась реализовать это, но отступила, поскольку это сломало серверы.)

И ни один браузер не реализует удивительно сложный и уродливый RFC2231 стандарт, который был бы необходим для вставки кодированных имен полей не ASCII в заголовки составных частей. В любом случае спецификация HTML, определяющая multipart/form-data, прямо не говорит о том, что следует использовать RFC2231, и, опять же, она сломает серверы, если вы попытаетесь.

Таким образом, реальность ситуации такова, что нет способа узнать, какая кодировка используется для имен и значений в представлении формы, независимо от того, какая это форма. То, что браузеры будут делать с именами полей и значениями, содержащими не-ASCII-символы, одинаково для GET и обоих типов форм POST: он кодирует их, используя кодировку страницы, содержащей используемую форму. Имена форм без ASCII GET не более повреждены, чем все остальное.

DLH:

Значит, имя имеет другой тип данных, чем для других элементов?

На самом деле единственный элемент, у которого атрибут name не CDATA, это <meta>. См. Список атрибутов спецификации HTML4 для всех различных применений name; это перегруженное имя атрибута, имеющее много разных значений для разных элементов. Это обычно считается плохой вещью.

Однако обычно в эти дни вы избегаете name за исключением полей формы (где это имя элемента управления) и param (где это специфичный для плагина идентификатор параметра). Это только два значения, с которыми нужно бороться. Следует избегать использования старой школы name для идентификации таких элементов, как <form> или <a> на странице (вместо этого используйте id).

28 голосов
/ 06 августа 2010

Единственное реальное ограничение на то, какие символы могут появляться в именах элементов управления формы, - это когда форма отправляется с помощью GET

"Метод" get "ограничивает значения набора данных формы до символов ASCII." ссылка

Здесь есть хорошая нить здесь .

7 голосов
/ 19 марта 2017

Хотя комментарий Аллена и ответил на прямой вопрос OP, а bobince предоставил некоторую блестящую исчерпывающую информацию, я полагаю, что многие люди приходят сюда в поисках ответа на более конкретный вопрос: «Могу ли я использовать символ точки в атрибуте входного имени формы?»

Поскольку эта тема возникла как первый результат, когда я искал это знание, я догадался, что я также могу поделиться тем, что нашел.

Во-первых, Матиас заявил, что:

символ.заменены на _

Это не соответствует действительности.Я не знаю, выполнял ли браузер такую ​​операцию еще в 2013 году - хотя я сомневаюсь в этом.Браузеры отправляют точечные символы такими, какие они есть (речь идет о данных POST)!Вы можете проверить это в инструментах разработчика любого приличного браузера.

Пожалуйста, обратите внимание на крошечный небольшой комментарий от abluejelly, который, вероятно, пропущен многими:

Я хотел бы отметитьчто это вещь для сервера, а не для браузера.Протестировано на Win7 FF3 / 3.5 / 31, IE5 / 7/8/9/10 / Edge, Chrome39 и Safari Windows 5, и все они отправили "test this.stuff" (четыре ведущих пробела) в качестве имени в POST длясервер разработки ASP.NET в комплекте с VS2012.

Я проверил его с помощью сервера Apache HTTP (v2.4.25), и действительно, имя входа, например "foo.bar", было изменено на "foo_bar".Но в названии типа "foo [foo.bar]" эта точка не заменяется на _!

Мой вывод: Вы можете использовать точки, но я бы не стал их использовать, так как это может привести к некоторымнепредвиденное поведение в зависимости от используемого HTTP-сервера .

0 голосов
/ 06 августа 2010

Вы имеете в виду атрибуты id и name тега ввода HTML?

Если это так, я бы очень хотел ограничить (или преобразовать) разрешенные "входные" символы имени в только az (AZ), 0-9 и ограниченный диапазон знаков препинания (".", "," И т. Д.), Только для того, чтобы ограничить потенциал для эксплойтов XSS и т. Д.

Кроме того, почему пользователь должен контролировать любой аспектвходного тега?(Возможно, в конечном итоге с точки зрения валидации не будет проще сохранить имена входных тегов «custom_1», «custom_2» и т. Д., А затем отобразить их при необходимости.)

...