Какой метод может быть использован для передачи файла из формы

Обновлено: 06.07.2024

Сама форма обычно предназначена для получения от пользователя информации для дальнейшей пересылки её на сервер, где данные формы принимает программа-обработчик. Такая программа может быть написана на любом серверном языке программирования вроде PHP, Perl и др. Адрес программы указывается в атрибуте action элемента <form> , как показано в примере 1.

Пример 1. Отправка данных формы

В этом примере данные формы, обозначенные атрибутом name ( login и password ), будут переданы в файл по адресу handler.php. Если атрибут action не указывать, то передача происходит на адрес текущей страницы.

Передача на сервер происходит двумя разными методами: GET и POST. Для задания метода в <form> применяется атрибут method , а его значениями выступают ключевые слова, соответственно, get и post . Если атрибут method не задан, то по умолчанию данные отправляются на сервер методом GET. В табл. 1 показаны различия между этими методами.

Какой метод используется легко определить по адресной строке браузера. Если в ней появился вопросительный знак и адрес стал похож на этот, то это точно GET.

Уникальное сочетание параметров в адресной строке однозначно идентифицирует страницу, так что страницы с адресами ?q=node/add и ?q=node считаются разными. Эту особенность используют системы управления контентом (CMS, Content management system) для создания множества страниц сайта. В реальности же используется один файл, который получает запрос GET и согласно ему формирует содержимое документа.

Ниже перечислены типовые области применения этих методов на сайтах.

Передача небольших текстовых данных на сервер; поиск по сайту.

Данные для поисковых систем и поиска по сайту всегда отправляются методом GET, это позволяет делиться результатами поиска с друзьями, слать ссылку по почте или выкладывать её на форуме.

Работа с формой по умолчанию происходит в текущей вкладке браузера, при этом допустимо при отправке формы изменить этот параметр и открывать обработчик формы в новой вкладке или во фрейме. Такое поведение задаётся через «имя контекста», которое выступает значением атрибута target элемента <form> . Популярные значения — _blank для открытия формы в новом окне или вкладке; имя фрейма, которое задаётся атрибутом name элемента <iframe> (пример 2).

Пример 2. Открытие формы во фрейме

Элементы формы традиционно располагаются внутри <form> , тем самым определяя те данные, которые будут передаваться на сервер. В то же время в HTML5 есть возможность отделить форму от её элементов. Это сделано для удобства и универсальности, поскольку сложный макет может содержать несколько форм, которые не должны пересекаться меж собой или к примеру, некоторые элементы выводятся с помощью скриптов в одном месте страницы, а сама форма находится в другом. Связь между формой и её элементами происходит в таком случае через идентификатор формы, а к элементам следует добавить атрибут form со значением, равным этому идентификатору (пример 3).

Пример 3. Связывание формы с полями

Хотя параметры передачи формы традиционно указываются внутри <form> , их можно перенести и в кнопки отправки формы ( <button> и <input type="submit"> ). Для этого применяется набор атрибутов formaction , formmethod , formenctype и formtarget , которые являются аналогами соответствующих атрибутов без приставки form. В примере 4 показано использование этих атрибутов.

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

Предварительные знания:	Базовая компьютерная грамотность, понимание HTML и базовые знания по HTTP и программированию на стороне сервера.
Задача:	Понять, что происходит при отправке данных формы, в том числе получить представление о том, как данные обрабатываются на стороне сервера.

Куда отправляются данные?

Здесь мы обсудим, что происходит с данными при отправке формы.

О клиентской/серверной архитектуре

Примечание: Для получения более полного представления о том, как работают клиент-серверные архитектуры, ознакомьтесь с модулем «Первые шаги в программировании на стороне сервера».

На стороне клиента: определение способа отправки данных

Элемент <form> определяет способ отправки данных. Все его атрибуты предназначены для того, чтобы вы могли настроить запрос на отправку, когда пользователь нажимает кнопку отправки. Двумя наиболее важными атрибутами являются action и method .

Атрибут action

Этот атрибут определяет, куда отправляются данные. Его значение должно быть действительным URL. Если этот атрибут не указан, данные будут отправлены на URL-адрес страницы, содержащей форму.

Здесь мы используем относительный URL - данные отправляются на другой URL на сервере:

Если атрибуты не указаны, как показано ниже, данные из формы <form> отправляются на ту же страницу, на которой размещается данная форма:

Многие старые страницы используют следующий синтаксис, чтобы указать, что данные должны быть отправлены на ту же страницу, которая содержит форму; это было необходимо, потому что до появления HTML5 атрибут action был обязательным. Это больше не нужно.

Атрибут method

Метод GET

Рассмотрим следующую форму:

Данные добавляются в URL как последовательность пар имя / значение. После того, как URL веб-адрес закончился, мы добавляем знак вопроса ( ? ), за которым следуют пары имя / значение, каждая из которых разделена амперсандом ( & ). В этом случае мы передаём две части данных на сервер:

say , со значением Hi
to , со значением Mom

Примечание: вы можете найти этот пример на GitHub — смотрите get-method.html (see it live also).

Метод POST

Давайте рассмотрим пример — это та же самая форма, которую мы рассматривали в разделе GET выше, но с атрибутом method , установленным в post .

Заголовок Content-Length указывает размер тела, а заголовок Content-Type указывает тип данных, отправляемых на сервер. Мы обсудим эти заголовки позже.

Примечание: вы можете найти этот пример на GitHub — смотрите post-method.html (see it live also).

Нажмите F12
Выберите Network
Выберите "All"
Выберите "foo.com" во вкладке "Name"
Выберите "Headers"

Затем вы можете получить данные формы, как показано на рисунке ниже.

Единственное, что отображается пользователю — вызываемый URL. Как упоминалось раннее, запрос с методом GET позволит пользователю увидеть информацию из запроса в URL, а запрос с методом POST не позволит. Две причины, почему это может быть важно:

На стороне сервера: получение данных

Пример: Чистый PHP

Пример: Python

Этот пример показывает, как вы можете использовать Python для решения той же задачи — отобразить отправленные данные на странице. В этом примере используется Flask framework для визуализации шаблонов, поддерживающих форму отправки данных (смотри python-example.py).

Два шаблона из коде выше взаимодействуют так:

: Та же форма, что и выше The POST method , только с использованием action к > . (Это Jinja2 шаблон, который изначально HTML, но может содержать вызовы Python кода в фигурных скобках, которые запустятся веб-сервером. url_for('hello') буквально говорит: после отправки данных переадресуй их в /hello .) : Этот шаблон просто содержит строку, которая отображает два бита данных, переданных ему при отображении. Это сделано с помощью функции hello() , указанной выше, которая выполняется, когда запрос направляется в /hello URL.

Примечание: Опять же, этот код не будет работать, если вы просто попробуете загрузить его прямо в браузер. Python работает немного иначе, чем PHP — чтобы запустить этот код, нужно установить Python/PIP, потом установить Flask используя команду: pip3 install flask . После этого, вы сможете запустить файл из примера, используя команду: python3 python-example.py , потом открыть localhost:5000 в своём браузере.

Другие языки и фреймворки

для Python (немного тяжеловеснее, чем Flask, но больше инструментов и опций) для Node.js для PHP для Ruby для Elixir

Стоит отметить, что использование фреймворков и работа с формами - это не всегда легко. Но это намного легче, чем пытаться написать аналогичную функциональность с нуля, и это определённо сэкономит время.

Примечание: Обучению фреймворкам и работе с серверами не входит в рамки этой статьи. Если хотите узнать больше, ссылки ниже помогут в этом.

Особый случай: отправка файлов

Атрибут enctype

Этот атрибут позволяет конкретизировать значение в Content-Type HTTP заголовок, включённый в запрос, при генерировании отправки формы. Этот заголовок очень важен, потому что указывает серверу, какой тип данных отправляется. По умолчанию это: application/x-www-form-urlencoded . На человеческом это значит: "Это форма с данными, которые были закодированы в URL параметры."

Указать method атрибут POST , поскольку содержимое файла, как и сам файл, не могут быть отображены в URL параметрах.
Установить в enctype значение multipart/form-data , потому что данные будут разбиты на несколько частей: одна часть на файл (две части на два файла), и одна часть на текстовые данные (при условии, если форма содержит поле для получения тестовых данных).
Подключите один или более File picker виджетов, чтобы позволить своим пользователям выбрать, какие и сколько файлов будут загружены.

Примечание: Некоторые браузеры поддерживают multiple атрибут элемента <input> , который позволяет выбрать больше одного файла для загрузки, при использовании одного элемента <input> . То, как сервер работает с этими файлами, напрямую зависит от технологий, используемых на сервере. Как упоминалось ранее, использование фреймворков сделает вашу жизнь намного легче.

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

Проблемы безопасности

Каждый раз, когда вы отправляете данные на сервер, вы должны учитывать безопасность. HTML-формы являются наиболее распространёнными векторами атак на серверы(места, где могут происходить атаки). Проблемы вытекают не из самих форм HTML, а из-за того, как сервер обрабатывает данные из этих форм.

В зависимости от того, что вы делаете, вы можете столкнуться с некоторыми очень известными проблемами безопасности:

XSS "Межсайтовый скриптинг" и CSRF "Подделка межсайтовых запросов"

Межсайтовый скриптинг (XSS "Cross Site Request Forgery") и подделка межсайтовых запросов (CSRF "Cross-Site Scripting") - это распространённые типы атак, которые происходят при отображении данных после ответа сервера или другого пользователя.

Межсайтовый скриптинг (XSS "Cross Site Request Forgery") позволяет злоумышленникам внедрить клиентский скрипт в веб-страницы, просматриваемые другими пользователями. Подделка межсайтовых запросов (CSRF "Cross-Site Scripting") может использоваться злоумышленниками для обхода средств контроля доступа, таких как одна и та же политика происхождения. Последствие от этих атак может варьироваться от мелких неудобств до значительного риска безопасности.

CSRF-атаки аналогичны XSS-атакам в том, что они начинаются одинаково - с внедрения клиентского скрипта в веб-страницы - но их конечные цели разные. Злоумышленники CSRF пытаются назначить права пользователям с более высоким уровнем прав доступа(например, администратору сайта), чтобы выполнить действие, которое они не должны выполнять (например, отправка данных ненадёжному пользователю). Атаки XSS используют доверие пользователя к веб-сайту, в то время как атаки CSRF используют доверие веб-сайта к пользователю.

Чтобы предотвратить эти атаки, вы всегда должны проверять данные, которые пользователь отправляет на ваш сервер, и (если вам нужно отобразить их) стараться не отображать HTML-контент, предоставленный пользователем. Вместо этого вы должны обработать предоставленные пользователем данные, чтобы не отображать их слово в слово. Сегодня почти все платформы на рынке реализуют минимальный "фильтр", который удаляет элементы HTML <script> , <iframe> (en-US) и <object> (en-US) полученных от любого пользователя. Это помогает снизить риск, но не исключает его полностью.

SQL - вброс

SQL -вброс представляет собой тип атак, при которых осуществляется попытка выполнения действия с базой данных, используемой целевым веб-сайтом. В этих случаях обычно осуществляется отправка SQL-запроса в надежде, что сервер выполнит этот запрос (обычно при попытке сервера приложения сохранить данные, отправляемые пользователем). Данный вид атак является одним из самых направленных атак на веб-сайты.

Последствия могут быть ужасающими, начиная от потери данных и заканчивая утратой контроля над всей инфраструктурой веб-сайта за счёт повышения привилегий. Это очень серьёзная угроза, поэтому никогда не сохраняйте данные, отправляемые пользователем, без выполнения фильтрации данных (например, с помощью mysqli_real_escape_string() .

Такие атаки являются самыми незаметными, но при этом могут превратить ваш сервер в зомби.

Будьте параноиком: никогда не доверяйте вашим пользователям

Как вы боретесь с такими угрозами? Этот вопрос выходит далеко за рамки данной статьи, но есть несколько общих правил, которые следует всегда соблюдать. Самое важное из них - никогда не доверяйте вашим пользователям, в том числе себе; даже проверенный пользователь может быть атакован.

Все данные, поступающие на ваш сервер, необходимо проверять и санитизировать. Все и всегда. Без исключений.

Избегайте потенциально опасных символов. Конкретные символы, с которыми следует соблюдать осторожность, зависят от контекста, в котором используются данные, а также от используемой платформы. Однако, все языки на стороне сервера имеют соответствующие функции для обеспечения такой защиты.
Ограничьте входящий объем данных для поступления только реально необходимых данных.
Помещайте загруженные файлы в песочницу (храните их на другом сервере и предоставляйте доступ к фалам только через отдельный поддомен или даже через совершенно другое доменное имя).

Соблюдая эти три правила, вы сможете избежать многих/большинства проблем. При этом следует помнить, что периодически необходимо проводить анализ защищённости, желательно квалифицированной сторонней организацией. Не считайте, что вы уже сталкивались со всеми возможными угрозами.

Примечание: В статье Безопасность веб-сайта нашего раздела серверного обучения приведено подробное обсуждение упомянутых угроз и возможных способов их устранения.

Заключение

Как мы увидели, отправлять формы просто, однако защитить приложение может быть довольно трудно. Просто помните, что фронтенд разработчики не должны задавать модель безопасности для приложения. Да, как мы увидим далее, мы можем проверить данные на стороне клиента, однако сервер не может доверять этой проверке, потому что он никогда не может по-настоящему узнать что происходит на стороне клиента.

Смотрите также

Если вы хотите узнать больше об обеспечении безопасности веб-приложений, вы можете использовать следующие источники информации:

При подготовке материала по Symfony Form я решил уделить некоторое внимание теоретической части по работе с формами со стороны клиента – что они из себя представляют, как ведут себя браузеры при отправке, в каком формате путешествуют, в каком виде поступают на сервер.

Вводная часть несколько растянулась и в итоге вылилась в отдельную небольшую статью, которая, по моему мнению, может быть интересна и другим бэкенд-разработчикам (не только PHP или Symfony).

В тексте будут использоваться два похожих термина: поле формы и элемент формы. Оба в большинстве случаев взаимозаменяемы и обозначают некоторую часть формы. Но для удобства и порядка полями чаще будут называться части, которые содержат непосредственно значения и, вероятно, будут отправлены на сервер, а элементами – декоративные части формы.

Раньше работа с формами была в каком-то смысле проще: в том виде, в котором форма приходила к пользователю, в том же она отправлялась и обратно, но уже с заполненными полями. Бэкенд-разработчики точно знали какой набор данных им следует ожидать, всё было легко и предсказуемо. С широким распространением JS всё изменилось: сегодня уже никого не удивляет поведение приложения, при котором форма приходит с одним набором полей, а отправляется с совершенно иным, когда громоздкие формы имеют в своём составе небольшие динамические подформы, которые независимо от основной могут отправляться на сервер для обработки, когда выбранные файлы загружаются в фоновом режиме, в то время как пользователь заполняет остальную часть формы. Таким образом, всё большее количество логики переносится на сторону клиента, и это отлично, в первую очередь, конечно же, для пользователя. Для разработчика процесс работы с формами несколько усложнился. Но как бы тяжело ему не было, игнорировать развитие технологий сегодня невозможно, поэтому необходимо уметь эффективно их использовать.

Бэкенд против Фронтенда

Мы постоянно стремимся к автоматизации всего, с чем нам приходится работать, особенно рутинных задач, при этом пытаемся привнести в эти процессы некий порядок. Поэтому многих разработчиков несколько пугает динамичность на клиентский стороне, которая часто воспринимается ими как неконтролируемый хаос. Можно подумать, что у фронтенд-разработчиков развязаны руки, и они могут творить подобно художникам и скульпторам, их действия ничем не ограничены, а нам потом разбирать на сервере полёты их фантазии. Нередко так и случается, но это ошибочный, тупиковый путь. Это можно сравнить со schemaless-хранилищами данных: никто вас не ограничивает жёсткой структурой хранения данных, каждый из разработчиков в рамках одного проекта может придумать свой формат хранения, потом поменять его в зависимости от настроения, что в конечном счёте, скорее всего, приведёт к печальным последствиям. Если же вы ожидаете от своего продукта гибкости, легкой расширяемости и динамичного развития, вам необходимо будет придерживаться определённых правил, которые помогут поддерживать порядок в вашем приложении. То же самое вы в праве требовать и от фронтенд-разработчиков – творите, но придерживайтесь правил.

Итак, что вам, как бэкенд-разработчику, необходимо понять и принять:

Перестаньте бояться динамики на серверной стороне.

Отправляем форму

Нажатие на кнопку отправки формы.
Вызов метода submit() у объекта формы.
Сериализация полей формы.
Создание и формирование произвольного запроса.

Пусть работает браузер

Для начала рассмотрим первую группу, оба способа которой мало чем отличаются друг от друга. В этом случае всю работу и ответственность на себя берёт браузер пользователя, причем действует он достаточно прямолинейно:

Атрибуты formmethod, formenctype и formaction нажимаемой кнопки переопределяют соответственно значения атрибутов method, enctype и action родительской формы.

Это очень простой процесс, но важно в нём разобраться, чтобы однозначно понимать, какие данные и в каком виде мы получаем на сервере.

Из всего списка наиболее интересен третий пункт – генерация пар ключ=значение. Каждый элемент формы должен иметь атрибут name, который будет использован браузером в качестве ключа. Рассмотрим на примере. Имеется следующая форма:

В этом случае браузер сформирует две пары ключ=значение: nickname=ghost и password=123456. При отправке они будут склеены с помощью символа амперсанда (&), и в результате на сервер будет отправлен запрос, тело которого содержит строку:

Получив такой запрос, PHP начнёт его разбор, примерный алгоритм которого можно посмотреть в описании функции parse_str. В результате разбора будут определены два поля и их значения, они будут помещены в суперглобальный массив $_POST, который примет следующий вид:

На что в этом процессе следует обратить внимание:

radio
checkbox
select с атрибутом multiple

Также в запрос не будут включены значения кнопок, как обычных, так и submit, которые не участвуют в отправке формы, т.е. те кнопки, по которым не было совершено нажатие. Таким образом, если отправка выполняется методом submit(), в запрос не будет включена ни одна кнопка.

Не будут отправлены также поля, находящиеся в отключённом состоянии (имеющие атрибут disabled).

Многие предполагают, что браузер каким-то образом должен решить, какое одно из двух полей необходимо отправлять в запросе. Логика подсказывает, что отправлять необходимо последнее (в данном случае второе), которое перекрывает все предшествующие поля с тем же именем. Это предположение неверно!
Браузер вообще не волнует, есть в форме какие-то конфликты имён или их нет. Непустое имя поля не является критерием исключения данного поля из отправляемого запроса. Другими словами, для браузера оба поля являются корректными и оба будут включены в набор отправляемых полей, причем в том порядке, в котором они представлены в форме.
Таким образом, приведённая выше форма при отправке на сервер примет следующий вид:

Именно такой запрос и придёт на наш сервер. Вы можете проверить это, прочитав значение php://input. Что же с этим запросом будет делать PHP? Всё как обычно – разбирает строку и формирует массив $_POST. Но, как мы знаем, ключи в массивах уникальны, поэтому первоначальное значение «John Doe» будет перезаписано значением «Mike Ross». В итоге мы получим следующий результат:

Теперь должно стать понятно, как работает хак со скрытым полем для checkbox. Посмотрим на следующую форму:

Видим два поля с одинаковыми именами. Если checkbox будет выбран, в запрос будут добавлены оба поля в том порядке, в котором они представлены в форме, а значит значение «0» поля hidden будет перезаписано значением «1» поля checkbox. Если же checkbox выбран не будет, то согласно пункту 2 его значение не отправляется, а значит в запросе будет только поле hidden со значением «0», которое и будет получено на сервере и помещено в массив $_POST.

manager_fullname

developer_fullname

Этот вариант удобно использовать для создания динамических форм, или, например, если необходимо выделить некоторые поля в логическую подформу.

Примерный алгоритм разбора такого запроса в PHP:

Таким образом, массив $_POST будет содержать следующие значения:

Форма содержит список, в котором мы можем выбрать несколько вариантов. Допустим, мы выбирали Movies, Cooking и Golf. Можно предположить, что при отправке поля будет использован некий разделитель значений. На самом же деле запрос будет выглядеть следующим образом:

Т.е. в браузере мы отправляем одно поле с тремя значениями, но серверная сторона видит это как отправку трех полей, которые содержат по одному значению. Очевидно, что согласно пункту 4 массив $_POST будет содержать только одно последнее значение golf, которое перезапишет первые два. Для решения этой проблемы необходимо воспользоваться советом из пункта 5 и изменить имя тега select на «hobbies[]».

За всё ответит разработчик

Кратко также рассмотрим вторую группу способов отправки форм. Эта группа отличается от первой тем, что созданием, формированием и отправкой запроса занимается непосредственно разработчик. Данная группа имеет лишь отдалённое отношение к рассматриваемой нами теме, так как не имеет жёсткой привязки к HTML-формам: разработчик может включать в запрос и исключать из него любые данные. Способ сериализации полей отличается от полностью произвольного запроса наличием в широко распространённых JS-фреймворках готовых алгоритмов, которые берут на себя большую часть работы. Эти способы удобны при отправке данных форм с использованием Ajax.

Рассмотрим небольшой пример использования JS-библиотеки jQuery для формирования и отправки формы таким способом.

Всю основную работу выполняет метод serialize(), который, используя имена и значения полей формы, генерирует следующую строку:

Почему из пяти полей формы в запрос включаются только два? Поле email не включается, т.к. находится в отключённом состоянии (атрибут disabled), а поля photo и submit – т.к. метод serialize() данной JS-библиотеки не включает файлы и кнопки в набор полей при формировании строки запроса.

Далее создаём Ajax-запрос с определёнными параметрами и отправляем нашу форму в виде полученной ранее строки. Тут важно понять, что при использовании данного способа от HTML-формы требуется только набор полей с их именами и значениями, все остальные параметры запроса определяет непосредственно разработчик. Таким образом, атрибуты action, method и enctype тега form игнорируются: при вызове метода ajax() мы явно указываем, что данные будут переданы методом POST в обработчик «server.php», а кодирование полей в данном методе по умолчанию – «application/x-www-form-urlencoded».

На стороне сервера такой запрос будет почти идентичен обычному, и только благодаря дополнительным заголовкам мы можем определить, что он был выполнен с использованием технологии Ajax. На основании этой информации формат и содержание ответа в большинстве случаев будет отлично от обычных запросов.

При использовании этой группы способов формирования и отправки запросов фронтенд-разработчик практически ничем не ограничен. Клиентская часть приложения может, например, передать в запросе лишь некоторую часть формы или передать эту форму в формате JSON, серверная же часть должна уметь корректно обрабатывать такие данные, поэтому для решения подобных задач взаимодействие и координация работы бэкенд и фронтенд-разработчиков должны быть усилены.

К чему вся эта статья?

Работа с формами считается одной из самых сложных задач в веб-разработке. Но если чётко понимать, как работают формы, найти удобные, функциональные и гибкие инструменты как для клиентской, так и для серверной части, наладить взаимодействие между бэкенд и фронтенд-разработчиками, задача намного упрощается.

Эта статья не отвечает на все существующие вопросы, многие не без оснований отметят, что всё описанное — это общеизвестные факты, но надеюсь, что предоставленная информация покажется кому-то полезной и заставит пересмотреть своё отношение к работе с формами, а возможно даже поможет побороть фобию перед ними.

Пример: Простая HTML-форма

Моя первая форма:
Имя:
Фамилия:

Элемент <form>

Элемент <input>

Вот некоторые значения атрибута type:

Значение	Описание
text	ввод одной строки текста
radio	элемент-переключатель (иногда их называют радио-кнопками)
password	текстовое поле для ввода пароля, в котором все вводимые символы заменяются звездочкой
checkbox	поле для установки флажка, который можно установить или сбросить
submit	кнопка, при нажатии которой происходит отправка данных, введенных в форму
reset	кнопка, при нажатии которой вся форма очищается. Точнее сказать, все элементы формы получают значения по умолчанию
button	обычная командная кнопка

Ввод текста и пароля

Одним из самых простых типов элементов формы является текстовое поле, предназначенное для ввода текста из одной строки. Данный тип ввода текста установлен по умолчанию, а следовательно, именно однострочное поле отобразится, если вы забудете указать атрибут type. Для добавления однострочного поля ввода текста в форму следует внутри элемента <input> прописать атрибут type со значением text :

Пример создания формы с полем для ввода пароля:

Пример: Поле ввода пароля

Вместе с этим атрибутом можно использовать атрибут maxlenght, значение которого определяет максимальное количество символов, которые можно ввести в данную строку. Можно также задать длину поля ввода, используя атрибут size. По умолчанию, в большинстве браузеров ширина текстового поля ограничена 20 символами. Для управления шириной элементов новых форм, вместо атрибута size, рекомендуется использовать средства каскадных таблиц стилей (CSS).
Атрибут value задает значение, которое по умолчанию отображается в текстовом поле в момент загрузки формы. Введя в поле значение по умолчанию, можно пояснить пользователю, какие именно данные и в каком формате вы хотите, чтобы пользователь сюда занес. Это как образец, ведь пользователю гораздо удобнее заполнять форму, видя перед собой пример.

Переключатели (radio)

Элемент <input> типа radio создает переключатели, которые используют принцип логического «ИЛИ», позволяя выбрать только одно из нескольких значений: если вы выбираете одно положение, то все остальные становятся неактивными. Основной синтаксис элемента-переключателя:

Пример: Использование переключателей

Сколько Вам лет?

младше 18
от 18 до 24
от 25 до 35
более 35

Флажки (checkbox)

Элемент <input> типа checkbox создает флажки, которые напоминают переключатели тем, что дают пользователю возможность выбирать из предложенных вами вариантов. Главным отличием от переключателей является то, что посетитель может выбрать сразу несколько вариантов, а сами флажки обозначаются квадратиками, а не кружочками. Как и в случае с переключателями, группа флажков создается путем назначения каждому пункту одного и того же значения атрибута name, однако каждый флажок имеет собственное значение. Основной синтаксис флажка:

Атрибут checked, как и в случае с переключателями, указывает, что данный флажок должен быть установлен по умолчанию при загрузке страницы. Данный атрибут может быть установлен одновременно для нескольких флажков группы.
В следующем примере использование флажков заданы несколько выбранных по умолчанию вариантов ответа:

Пример: Использование переключателей

Какие музыкальные жанры Вы любите?

Кнопки подтверждения (submit) и очистки (reset)

Пример: Использование submit и reset

Подпишись на рассылку новостей:

После щелчка на кнопке Reset происходит сброс любых введенных пользователем данных.

Атрибут action.

Атрибут method

Метод POST

Метод GET

Теперь вы видите имя каждого элемента формы, а также его значение, прямо здесь, в URL-адресе.
URL-адрес отделяется от остальных данных формы символом знака вопроса, а имена и значения переменных разделяются знаком амперсанд (&).
Этот метод нужно использовать, если вы не передаете больших объемов информации.
Этот метод не подойдет, если данные в вашей форме являются конфиденциальными, например хранят номер банковской карты или пароль.
Кроме того, метод GET непригоден, если вместе с формой вы хотите переслать на сервер файлы.

Группировка элементов формы

Элементы формы, связанные по смыслу, можно сгруппировать между тегами <fieldset> и </fieldset> . Браузер отобразит <fieldset> в виде рамки вокруг группы элементов формы. Внешний вид рамки может быть изменен с помощью каскадных таблиц стилей (CSS).
Чтобы добавить заголовок для каждой группы, понадобится элемент <legend> , который задает встраиваемый в рамку текст заголовка группы:

Читайте также: