У мене є PHP-скрипт, який буде генерувати <input>s динамічно, тому мені було цікаво, чи потрібно мені фільтрувати символи в nameатрибуті.
Я знаю, що ім’я має починатися з букви, але я не знаю жодних інших правил. Я вважаю, що квадратні дужки повинні бути дозволені, оскільки PHP використовує їх для створення масивів із даних форми. Як щодо дужок? Простори?
Відповіді:
<a>і більшість елементів, але відрізняється від<meta>
<input>із усілякими лайнами name, і це перевірено в HTML 4.01 Strict. Прийнято!
Зверніть увагу, що не всі символи подаються для nameатрибутів полів форми (навіть при використанні POST)!
Пробіли символи обрізаються, а внутрішні пробіли, а також символ .замінюються на _. (Перевірено в Chrome 23, Firefox 13 та Internet Explorer 9, всі Win7.)
first[second]замість first.second.
Будь-який символ, який ви можете включити в 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, в обох «не вказано» як робочих, і multipart/form-dataзамість цього слід використовувати POSTed .
На жаль, у реальному світі жоден браузер не визначає кодування полів, навіть якщо це теоретично могло, у заголовках підрозділів multipart/form-data тіла запиту POST. (Я вважаю, що Mozilla намагалася реалізувати це один раз, але відступила, оскільки зламала сервери.)
І жоден браузер не реалізує напрочуд складний і потворний стандарт RFC2231, який був би необхідний для вставки закодованих імен полів, що не належать до ASCII, у заголовки підрозділів багаточастинної частини. У будь-якому випадку, специфікація HTML, яка визначає multipart/form-data, прямо не говорить про те, що слід використовувати RFC2231, і, знову ж таки, це призведе до поломки серверів, якщо ви спробуєте.
Тож реальність ситуації полягає в тому, що неможливо дізнатися, яке кодування використовується для імен та значень у поданні форми, незалежно від того, якого типу це форма. Те, що браузери будуть робити з іменами полів та значеннями, що містять символи, що не є ASCII, однаково для GET та обох типів форми POST: він кодує їх, використовуючи кодування сторінки, що містить використовувану форму. Імена форм, що не належать до ASCII, є не більшими, ніж усі інші.
DLH:
Тож ім’я має інший тип даних, ніж для інших елементів?
Насправді єдиним елементом, nameатрибут якого не CDATAє, є <meta>. Перегляньте список атрибутів специфікації HTML4 для різних видів використання name; це перевантажена назва атрибута, що має багато різних значень для різних елементів. Зазвичай це вважається поганим.
Однак зазвичай в ці дні ви уникаєте, nameкрім випадків у полях форми (де це ім'я елемента керування) та param(де це ідентифікатор параметра, що відповідає плагіну). Це лише два значення, з якими можна боротися. Слід уникати використання старої школи nameдля ідентифікації елементів, таких як <form>або <a>на сторінці ( idзамість цього використовуйте ).
Незважаючи на те, що коментар Аллайна відповів на пряме запитання ОП, і бобінс подав блискучу поглиблену інформацію, я вважаю, що багато людей приходять сюди, шукаючи відповіді на більш конкретне питання: "Чи можу я використовувати крапковий символ у атрибуті введеного імені форми?"
Оскільки ця тема з’явилася як перший результат, коли я шукав ці знання, я здогадувався, що можу поділитися тим, що знайшов.
По-перше, Матіас стверджував, що:
характер. замінюються на _
Це неправда. Я не знаю, чи справді браузер виконував подібні операції ще в 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" тощо, а потім зіставити їх за необхідності.)
nameчи відрізняється тип даних<input>для інших елементів, ніж для інших елементів? Цікаво.