Какие символы разрешены в атрибуте HTML Name внутри входного тега?
У меня есть PHP-скрипт, который будет динамически генерировать , поэтому мне было интересно, нужно ли мне фильтровать какие-либо символы в атрибуте name .
Я знаю, что имя должно начинаться с буквы, но я не знаю других правил. Я считаю, что квадратные скобки должны быть разрешены, так как PHP использует их для создания массивов из данных формы. Как насчет скобок? Пробелы?
3 ответа
Единственное реальное ограничение на то, какие символы могут появляться в именах элементов управления формы, - это когда форма отправляется с помощью GET
"Метод" get "ограничивает значения набора данных формы ASCII символы." ссылка
Там есть хорошая ветка здесь .
Вы имеете в виду атрибуты id и name тега ввода HTML?
Если это так, я бы очень хотел ограничить (или преобразовать) разрешенные «входные» символы имени только в az (AZ), 0- 9 и ограниченный диапазон знаков препинания («.», «,» И т. Д.), Хотя бы для ограничения возможности использования XSS-атак и т. Д.
Кроме того, зачем позволять пользователю управлять любым аспектом входного тега? (Может быть, в конечном итоге не будет проще с точки зрения проверки сохранить имена входных тегов «custom_1», «custom_2» и т. Д., А затем сопоставить их по мере необходимости.)
Любой символ, который можно включить в файл [X]HTML, можно поместить в . Как сказано в комментарии Аллейна, определяется как содержащий 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 имен полей в заголовки подчастей multipart. В любом случае, спецификация HTML, определяющая multipart/form-data, не говорит напрямую, что следует использовать RFC2231, и, опять же, это сломало бы серверы, если бы вы попытались.
Итак, реальность ситуации такова, что нет способа узнать, какая кодировка используется для имен и значений в форме отправки, независимо от того, какого типа эта форма. То, что браузеры будут делать с именами и значениями полей, содержащими символы, отличные от ASCII, одинаково для GET и обоих типов POST-форм: они кодируют их, используя кодировку, которую использовала страница, содержащая форму. Имена форм GET, содержащие не-ASCII символы, ломаются не больше, чем все остальные.
DLH:
Значит, у name другой тип данных, чем у других элементов?
На самом деле единственный элемент, чей атрибут name не является CDATA - это . См. список атрибутов в спецификации HTML4 для всех различных вариантов использования name; это перегруженное имя атрибута, имеющее множество различных значений для различных элементов. Обычно считается, что это плохо.
Однако в наши дни обычно избегают name, за исключением полей формы (где это имя элемента управления) и param (где это идентификатор параметра, специфичного для плагина). That's only two meanings to grapple with. The old-school use of name for identifying elements like or on the page should be avoided (use id instead).