Какие символы разрешены в атрибуте HTML Name внутри тега input?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DLH:

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

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

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

Хотя комментарий Аллена действительно ответил на прямой вопрос 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.

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

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

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

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

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