Работа с данными со страницы в PHP

Сквозной пример с сохранением в MySQL через PDO: от HTML-формы до записи в базу данных. Загрузка файлов в форме: Загрузка файлов и валидация в PHP.

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору

Работа с данными со страницы

Работа с данными, вводимыми пользователем через веб-страницу, — фундаментальная задача любого веб-приложения. Это процесс, в котором данные передаются от клиента (браузера) на сервер, обрабатываются и используются для формирования ответа, хранения в базе данных или выполнения других операций. В основе этого процесса лежат HTML-формы, HTTP-методы, серверные языки (в данном случае — PHP), а также принципы безопасности и корректной обработки информации.

Что такое данные со страницы

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

HTML предоставляет средства для создания таких элементов, а протокол HTTP — для их передачи. Серверный язык программирования, такой как PHP, принимает эти данные, проверяет их корректность, преобразует и использует по назначению.

Именование элементов — name и id

Каждый элемент формы в HTML должен иметь атрибут name, если он предназначен для отправки данных на сервер. Именно значение этого атрибута становится ключом в массивах $_GET или $_POST в PHP.

Пример:

<input type="text" name="username" />

Разбор:

Атрибут name="username" задаёт ключ, под которым значение поля попадёт на сервер.
Тип text означает обычный однострочный ввод без встроенной строгой валидации формата.
Без name значение поля не попадёт в $_POST/$_GET, даже если пользователь что-то введёт.
Это базовый кирпич для связки "HTML-форма -> PHP-обработчик".

При отправке формы на сервер PHP получит значение в переменной:

$username = $_POST['username'];

Разбор:

Код читает значение поля username из тела POST-запроса.
Ключ в $_POST должен точно совпадать с name в HTML, включая регистр.
В production лучше использовать $_POST['username'] ?? '', чтобы избежать предупреждения при отсутствии ключа.
После чтения значение нужно валидировать и нормализовать, а не использовать напрямую.

Атрибут id используется исключительно на стороне клиента — для стилизации через CSS или манипуляций через JavaScript. Он не влияет на передачу данных на сервер.

Важно:

Имена (name) должны быть уникальными в пределах одной формы, если речь не идет о группах элементов (например, чекбоксы с одинаковым именем).
Имена чувствительны к регистру: UserName и username — разные ключи.
Имена могут содержать буквы, цифры, дефисы, подчеркивания, но не должны начинаться с цифры.

Теги и атрибуты форм

Основной тег для сбора данных — <form>. Его ключевые атрибуты:

action — URL, на который отправляются данные.
method — HTTP-метод (GET или POST).
enctype — способ кодирования данных (особенно важен при загрузке файлов).

Пример формы:

<form action="/submit.php" method="POST">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email" required />
  
  <label for="message">Сообщение:</label>
  <textarea id="message" name="message"></textarea>
  
  <button type="submit">Отправить</button>
</form>

Разбор:

action="/submit.php" задаёт endpoint, куда браузер отправит форму.
method="POST" отправляет данные в тело запроса, а не в URL-строку.
Связка <label for> и id улучшает доступность и UX: клик по подписи фокусирует поле.
required на email добавляет клиентскую проверку, но серверная валидация всё равно обязательна.

Основные элементы форм

Элемент	Назначение
`<input type="text">`	Однострочное текстовое поле
`<input type="email">`	Поле для email (браузер проверяет формат)
`<input type="password">`	Скрытое поле для пароля
`<textarea>`	Многострочное текстовое поле
`<select>` + `<option>`	Выпадающий список
`<input type="checkbox">`	Флажок (можно несколько с одинаковым `name[]`)
`<input type="radio">`	Переключатель (группа с одинаковым `name`)
`<input type="file">`	Загрузка файла (требует `enctype="multipart/form-data"`)
`<button type="submit">`	Кнопка отправки

HTTP-методы — GET и POST

GET

Метод GET добавляет данные в URL в виде строки запроса:

https://example.com/search?q=книги&category=fiction

Особенности:

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

В PHP данные доступны через суперглобальный массив $_GET.

POST

Метод POST отправляет данные в теле HTTP-запроса, скрывая их от пользователя.

Особенности:

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

В PHP данные доступны через $_POST.

📌 Внимание
Никогда не используйте GET для операций, изменяющих данные (удаление, покупка, регистрация). Это нарушает принципы REST и создает уязвимости.

Как составлять HTML-формы для работы с PHP

Форма должна быть правильно структурирована:

Обязательно указывайте method="POST" для операций записи.
Указывайте action явно (или оставляйте пустым, если обработка на той же странице).
Используйте семантические теги — <label>, <fieldset>, <legend>.
Добавляйте атрибуты валидации — required, minlength, pattern — они работают на клиенте, но не заменяют серверную проверку.

Пример безопасной формы регистрации:

Код ITЗагрузка примера кода…

Получение данных в PHP

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

$_GET — данные из URL (метод GET)
$_POST — данные из тела запроса (метод POST)
$_REQUEST — объединяет $_GET, $_POST и $_COOKIE (рекомендуется избегать из-за неоднозначности)

Пример получения:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $email = $_POST['email'] ?? '';
    $message = $_POST['message'] ?? '';
}

Использование оператора нулевого слияния (??) предотвращает ошибку Undefined index, если поле не было отправлено.

Валидация данных

Валидация — проверка корректности и соответствия ожидаемому формату.

Базовые правила

Проверяйте наличие: убедитесь, что поле отправлено.
Проверяйте тип — строка, число, email и т.д.
Проверяйте длину: минимум/максимум символов.
Проверяйте формат: регулярные выражения для сложных паттернов.
Проверяйте бизнес-логику: уникальность email, корректность даты и пр.

Пример валидации:

$errors = [];

$email = trim($_POST['email'] ?? '');
if (empty($email)) {
    $errors[] = "Email обязателен";
} elseif (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    $errors[] = "Некорректный формат email";
}

$password = $_POST['password'] ?? '';
if (strlen($password) < 8) {
    $errors[] = "Пароль должен быть не короче 8 символов";
}

Разбор:

$errors = []; создаёт накопитель ошибок, чтобы показать пользователю все проблемы за один ответ.
trim($_POST['email'] ?? '') убирает пробелы и защищает от отсутствующего поля.
filter_var(..., FILTER_VALIDATE_EMAIL) проверяет реальный формат email вместо самописных regex.
Проверка длины пароля через strlen реализует минимальное требование безопасности.
При таком подходе бизнес-логика сохранения вызывается только если $errors пуст.

PHP предоставляет встроенную функцию filter_var() для стандартных проверок:

FILTER_VALIDATE_EMAIL
FILTER_VALIDATE_URL
FILTER_VALIDATE_INT
FILTER_VALIDATE_BOOLEAN

Экранирование данных

Экранирование — защита от внедрения вредоносного кода при выводе данных в HTML.

Если вы получили строку от пользователя и сразу вставляете её в HTML без обработки, это открывает путь к XSS-атакам (межсайтовому скриптингу).

Пример уязвимости:

// ПЛОХО!
echo "<p>Привет, {$_POST['name']}!</p>";
// Если пользователь введёт: <script>alert('hacked')</script>
// — скрипт выполнится в браузере другого пользователя.

Правильный подход — экранировать специальные HTML-символы:

$name = htmlspecialchars($_POST['name'] ?? '', ENT_QUOTES, 'UTF-8');
echo "<p>Привет, {$name}!</p>";

Функция htmlspecialchars() преобразует:

< → <
> → >
" → "
' → '

Всегда используйте ENT_QUOTES и явно указывайте кодировку (UTF-8).

Обработка данных — от формы до базы

Интерактивная лаборатория

Play ITЗагрузка интерактивного демо…

Демо визуализирует полный путь данных: HTML-форма и POST → $_POST и валидация на PHP → PDO (prepare, execute) → MySQL. Режимы — пошаговая анимация отправки формы, поток INSERT/SELECT, CRUD-лаборатория с таблицей subscribers, сравнение PDO / mysqli / небезопасной конкатенации и жизненный цикл соединения. Сквозной код без фреймворка — в статье От HTML-формы до записи в базу.

Типичный цикл обработки:

Пользователь заполняет форму.
Данные отправляются методом POST.
Сервер получает данные через $_POST.
Выполняется валидация.
При наличии ошибок — форма перерисовывается с сообщениями.
При успехе — данные экранируются или экранируются на уровне БД (через подготовленные запросы).
Данные сохраняются в базу или используются для генерации ответа.

Пример безопасного сохранения в MySQL с использованием PDO:

Код ITЗагрузка примера кода…

Разбор:

new PDO(...) открывает соединение, а PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION переводит ошибки БД в исключения.
prepare(...) + execute([...]) формируют параметризованный запрос и защищают от SQL-инъекций.
password_hash(..., PASSWORD_DEFAULT) сохраняет только хеш пароля, а не открытый текст.
try/catch разделяет успешный путь и обработку ошибок, чтобы не раскрывать внутренние детали пользователю.
error_log(...) отправляет детали в логи, что помогает диагностике без утечки в UI.

Обратите внимание:

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

Работа с таблицами и повторяющимися данными

Если форма содержит таблицу или список однотипных элементов (например, список товаров), используйте имена в виде массивов:

<input name="items[0][name]" value="Товар 1" />
<input name="items[0][price]" value="100" />

<input name="items[1][name]" value="Товар 2" />
<input name="items[1][price]" value="200" />

В PHP это придет как вложенный массив:

$items = $_POST['items'] ?? [];
foreach ($items as $item) {
    $name = $item['name'] ?? '';
    $price = $item['price'] ?? 0;
    // обработка
}

Альтернатива — использовать name="items[]" для простых списков:

<input name="colors[]" value="red" />
<input name="colors[]" value="blue" />

→ $_POST['colors'] будет массивом ['red', 'blue'].

Защита от CSRF

При работе с формами важно защищаться от межсайтовой подделки запроса (CSRF). Злоумышленник может заставить пользователя выполнить действие на вашем сайте без его ведома.

Решение — использовать токен CSRF:

При генерации формы создайте случайный токен и сохраните его в сессии.
Вставьте токен в скрытое поле формы.
При получении данных сверьте токен из формы с тем, что в сессии.

Пример:

// Генерация токена (в начале страницы с формой)
session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

В форме:

<input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf_token'] ?>" />

При обработке:

if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    die('Недопустимый запрос');
}

Функция hash_equals() защищает от атак по времени.

Итоги и лучшие практики

Всегда проверяйте и фильтруйте входные данные.
Никогда не доверяйте данным от клиента.
Используйте POST для операций изменения.
Экранируйте вывод с помощью htmlspecialchars().
Применяйте подготовленные запросы к базе данных.
Хешируйте пароли.
Защищайтесь от CSRF.
Не показывайте внутренние ошибки пользователю.
Используйте HTTPS в продакшене.

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

Работа с файлами через HTML-формы

Загрузка файлов — частый сценарий взаимодействия пользователя с веб-приложением. Для этого используется элемент <input type="file">, а форма должна содержать специальный атрибут enctype.

Подробный разбор валидации, MIME, расширений, finfo_file и правил Laravel extensions / mimes — в статье Загрузка файлов и валидация в PHP.

Настройка формы для загрузки файлов

<form method="POST" enctype="multipart/form-data" action="/upload.php">
  <label>
    Выберите файл:
    <input type="file" name="document" required />
  </label>
  <button type="submit">Загрузить</button>
</form>

Атрибут enctype="multipart/form-data" указывает браузеру, что данные должны быть закодированы как набор частей (parts), каждая из которых может содержать двоичные данные.

Получение файла в PHP

В PHP загруженные файлы доступны через суперглобальный массив $_FILES. Он содержит следующие ключи для каждого поля:

name — оригинальное имя файла на клиенте;
type — MIME-тип файла;
tmp_name — путь к временному файлу на сервере;
error — код ошибки (0 при успехе);
size — размер файла в байтах.

Пример обработки:

Код ITЗагрузка примера кода…

📌 Внимание
Никогда не используйте $_FILES['name'] напрямую в путях без фильтрации. Это открывает возможность для атак типа Path Traversal.

Рекомендуется:

Генерировать уникальные имена файлов (например, через uniqid() или хеш);
Хранить оригинальное имя в базе данных, а не в файловой системе;
Ограничивать размер и типы файлов;
Сканировать файлы антивирусом при необходимости.

Обработка множественных файлов

Для загрузки нескольких файлов используется атрибут multiple:

<input type="file" name="photos[]" multiple />

PHP получит массив значений в $_FILES['photos'], но структура будет "перекошена": каждый параметр (name, tmp_name и т.д.) сам является массивом.

Пример безопасной обработки:

if (!empty($_FILES['photos']['name'][0])) {
    $count = count($_FILES['photos']['name']);
    for ($i = 0; $i < $count; $i++) {
        if ($_FILES['photos']['error'][$i] === UPLOAD_ERR_OK) {
            $tmp = $_FILES['photos']['tmp_name'][$i];
            $origName = $_FILES['photos']['name'][$i];
            // ... обработка одного файла
        }
    }
}

AJAX и отправка данных без перезагрузки страницы

Современные веб-приложения часто используют JavaScript для отправки данных без полной перезагрузки страницы. Это достигается через объект XMLHttpRequest или более современный fetch.

Пример с `fetch` и FormData

Код ITЗагрузка примера кода…

Объект FormData автоматически собирает все поля формы, включая файлы, и кодирует их в формате multipart/form-data.

На стороне PHP обработка остаётся той же: данные приходят в $_POST и $_FILES как обычно.

💡 Совет
При использовании AJAX важно корректно обрабатывать ошибки и показывать пользователю статус операции. Не стоит скрывать неудачные запросы.

Безопасность — защита от подделки запросов и инъекций

Помимо CSRF и XSS, необходимо учитывать:

SQL-инъекции

Если данные из формы попадают в SQL-запрос, они обязательно должны передаваться через параметризованные запросы (prepared statements).

Плохо:

// УЯЗВИМЫЙ КОД
$query = "SELECT * FROM users WHERE email = '{$_POST['email']}'";

Хорошо:

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$_POST['email']]);

Командная инъекция

Если вы вызываете системные команды (например, через exec()), никогда не передавайте пользовательские данные напрямую.

Плохо:

exec("ping " . $_POST['host']);

Хорошо:

$host = escapeshellarg($_POST['host']);
exec("ping " . $host);

Или ещё лучше — вообще избегать вызова shell-команд с пользовательскими данными.

Обработка JSON-данных

Иногда клиент отправляет данные не как форму, а как JSON (например, из SPA-приложения).

Пример отправки:

fetch('/api/Данные', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username: 'alice', role: 'admin' })
});

В PHP такие данные не попадают в $_POST. Их нужно читать из входного потока:

$input = file_get_contents('php://input');
$data = json_decode($input, true);

if (json_last_error() !== JSON_ERROR_NONE) {
    http_response_code(400);
    die('Некорректный JSON');
}

$username = $data['username'] ?? '';
$role = $data['role'] ?? '';

⚠️ Предупреждение
При работе с JSON всегда проверяйте структуру данных — наличие ключей, типы значений, допустимые диапазоны.

Локализация и кодировка

Убедитесь, что:

HTML-страница указывает кодировку: <meta charset="UTF-8">;
Форма отправляется в той же кодировке;
Сервер обрабатывает данные в UTF-8;
База данных использует UTF-8 (например, utf8mb4 в MySQL).

В PHP можно явно установить внутреннюю кодировку:

mb_internal_encoding('UTF-8');

Это предотвращает искажение символов (особенно кириллицы, эмодзи и других Unicode-символов).

Итоговая структура надёжной формы

Код ITЗагрузка примера кода…

И соответствующая обработка в PHP:

Проверка метода запроса;
Валидация CSRF-токена;
Фильтрация и валидация каждого поля;
Экранирование при выводе;
Безопасное сохранение файлов;
Использование подготовленных запросов к БД.

Валидация на стороне клиента и её ограничения

HTML5 предоставляет встроенные средства клиентской валидации — атрибуты required, minlength, maxlength, pattern, type="email", type="url" и другие. Они позволяют браузеру проверять корректность данных до отправки формы.

Пример:

<input type="email" name="email" required />
<input type="password" name="pass" minlength="8" required />

Эти проверки удобны для пользователя — они мгновенны и не требуют обращения к серверу. Однако они не заменяют серверную валидацию по следующим причинам:

Пользователь может отключить JavaScript или использовать устаревший браузер.
Злоумышленник может отправить данные напрямую через инструменты вроде Postman, curl или собственный скрипт, минуя HTML-форму.
Клиентская логика легко обходится — достаточно изменить атрибуты элемента через DevTools.

Следовательно, вся валидация должна дублироваться на сервере. Клиентская валидация — лишь улучшение пользовательского опыта, но не механизм безопасности.

Обработка ошибок и повторный вывод формы

После отправки формы с ошибками (например, пустое поле или неверный email) пользователь должен увидеть:

Список ошибок;
Сохранённые ранее введённые данные (чтобы не заполнять форму заново).

В PHP это реализуется так:

Код ITЗагрузка примера кода…

А в HTML-форме значения подставляются обратно:

Код ITЗагрузка примера кода…

Обратите внимание:

Все значения экранируются через htmlspecialchars() при выводе в HTML;
Ошибки также экранируются — даже если вы сами их генерируете, это хорошая привычка;
Форма остаётся на той же странице, что упрощает UX.

Работа с таблицами и динамическими формами

Современные интерфейсы часто содержат динамически добавляемые строки — список товаров, контактов, задач. Для передачи таких данных используются массивы в именах полей.

Пример:

<div class="item">
  <input name="items[0][name]" />
  <input name="items[0][price]" type="number" />
</div>
<div class="item">
  <input name="items[1][name]" />
  <input name="items[1][price]" type="number" />
</div>

PHP получит структуру:

$_POST['items'] = [
    0 => ['name' => 'Товар А', 'price' => '100'],
    1 => ['name' => 'Товар Б', 'price' => '200']
];

Для динамического добавления строк через JavaScript используйте шаблон:

let counter = 2;
function addRow() {
    const container = document.getElementById('items');
    const html = `
        <div class="item">
            <input name="items[${counter}][name]" />
            <input name="items[${counter}][price]" type="number" />
        </div>
`;
    container.insertAdjacentHTML('beforeend', html);
    counter++;
}

На сервере обрабатывайте как обычный массив:

$items = $_POST['items'] ?? [];
foreach ($items as $item) {
    $name = trim($item['name'] ?? '');
    $price = filter_var($item['price'] ?? 0, FILTER_VALIDATE_FLOAT);
    if ($name && $price > 0) {
        // сохранить
    }
}

Защита от повторной отправки (Post/Redirect/Get)

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

Решение — паттерн Post/Redirect/Get (PRG):

Пользователь отправляет форму методом POST.
Сервер обрабатывает данные.
При успехе — перенаправляет (header('Location: ...')) на другую страницу (например, "спасибо").
Пользователь оказывается на GET-странице, которую можно безопасно обновлять.

Пример:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    // валидация и обработка
    if (empty($errors)) {
        saveData($_POST);
        header('Location: /thank-you.php');
        exit;
    }
}
// иначе — показать форму с ошибками

Это стандартная практика в веб-разработке и обязательна для всех операций, изменяющих состояние системы.

Локализация и многоязычность форм

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

Простой подход — хранить переводы в массиве:

$translations = [
    'ru' => [
        'email_required' => 'Email обязателен',
        'invalid_email' => 'Некорректный email'
    ],
    'en' => [
        'email_required' => 'Email is required',
        'invalid_email' => 'Invalid email format'
    ]
];

$lang = $_COOKIE['lang'] ?? 'ru';
$t = $translations[$lang] ?? $translations['ru'];

Затем использовать $t['email_required'] вместо жёстко заданных строк.

Для крупных проектов применяются специализированные системы локализации (gettext, Symfony Translator и др.), но для небольших сайтов массивов достаточно.

Итоговая рекомендация по архитектуре обработки форм

Определите цель формы — регистрация, заказ, комментарий — каждая имеет свои правила.
Создайте чистую HTML-структуру с семантическими тегами и правильными атрибутами.
Добавьте клиентскую валидацию для удобства, но не полагайтесь на неё.
На сервере всегда проверяйте:
- Наличие данных;
- Тип и формат;
- Допустимые диапазоны;
- Бизнес-логику (уникальность email, наличие товара и т.д.).
Экранируйте всё при выводе в HTML.
Используйте подготовленные запросы к базе данных.
Хешируйте пароли.
Защищайтесь от CSRF.
Применяйте PRG-паттерн после успешной обработки.
Логируйте ошибки, но не показывайте их пользователю.

Соблюдение этих принципов обеспечивает надёжность, безопасность и удобство взаимодействия с пользователем.

Многошаговые формы и состояние между шагами

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

Подходы к хранению промежуточных данных

Сессии (Session)
Наиболее распространённый способ. PHP предоставляет механизм $_SESSION, который хранит данные на сервере и связывает их с пользователем через cookie.

Пример:

   session_start();
   if ($_SERVER['REQUEST_METHOD'] === 'POST') {
       // Сохраняем данные шага 1
       $_SESSION['step1'] = [
           'email' => $_POST['email'],
           'name' => $_POST['name']
       ];
       header('Location: /step2.php');
       exit;
   }

Преимущества:

Безопасность: данные не видны клиенту.
Надёжность: не зависят от размера данных.

Недостатки:

Требует поддержки сессий на сервере.
Не масштабируется без shared storage в распределённых системах.

Скрытые поля (Hidden inputs)
Все данные передаются на каждый шаг через скрытые <input type="hidden">.

Пример:

   <input type="hidden" name="email" value="<?= htmlspecialchars($email) ?>" />
   <input type="hidden" name="name" value="<?= htmlspecialchars($name) ?>" />

Преимущества:

Простота реализации.
Не требует серверного хранилища.

Недостатки:

Данные видны в HTML и могут быть изменены.
Риск превышения лимита на размер POST-запроса.
Не подходит для больших объёмов данных.

Хранилище на стороне клиента (localStorage, sessionStorage)
Используется при полностью клиентской навигации (SPA). Данные хранятся в браузере и отправляются только на финальном шаге.

Недостатки:
- Не надёжен: пользователь может очистить хранилище.
- Не безопасен: данные доступны для чтения/изменения.
- Требует JavaScript.
Временная запись в базу данных
Создаётся черновик записи с уникальным ID. На каждом шаге обновляется эта запись. После завершения — статус меняется на "активный".

Преимущества:
- Полная надёжность.
- Возможность восстановления после перезагрузки.
- Поддержка аналитики (сколько пользователей дошло до шага 3?).
Недостатки:
- Сложность реализации.
- Требует очистки старых черновиков.

📌 Рекомендация
Для большинства веб-приложений оптимальный выбор — сессии. Они просты, безопасны и интегрированы в PHP.

Валидация на каждом шаге

Каждый шаг должен валидироваться независимо. Нельзя полагаться на то, что данные с предыдущего шага уже проверены — они могли быть изменены вручную или повреждены.

Структура обработки:

Код ITЗагрузка примера кода…

При отображении формы шага 2 — данные из $data['step1'] не показываются, но сохраняются в сессии.

Защита от прямого доступа к шагам

Пользователь не должен иметь возможность перейти на /step3.php, если не прошёл шаги 1 и 2.

Решение:

session_start();

// Проверяем, что предыдущие шаги пройдены
if (!isset($_SESSION['form_data']['step1']) || !isset($_SESSION['form_data']['step2'])) {
    header('Location: /step1.php');
    exit;
}

Это обеспечивает линейность процесса и целостность данных.

Отправка файлов на промежуточных шагах

Если на шаге 2 загружается файл (например, фото паспорта), его нельзя хранить в сессии — только путь к сохранённому файлу.

Алгоритм:

Файл загружается и сохраняется в папку /uploads/temp/.
В сессии сохраняется только имя файла: $_SESSION['passport_file'] = 'abc123.jpg';.
На финальном шаге файл перемещается в постоянное хранилище или удаляется при отмене.

Важно:

Очищать временные файлы по таймеру (например, старше 1 часа).
Генерировать случайные имена файлов.
Проверять MIME-тип и расширение.

Интеграция с внешними API

Часто данные со страницы отправляются не только на ваш сервер, но и в сторонние сервисы — CRM, почтовые рассылки, платёжные системы.

Пример отправки в CRM через cURL:

Код ITЗагрузка примера кода…

⚠️ Предупреждение
Никогда не отправляйте пароли, персональные документы или финансовые данные в сторонние API без шифрования и согласия пользователя.

Обработка ошибок внешних сервисов

Если CRM недоступна, это не должно блокировать основную логику сайта. Используйте асинхронную очередь или повторные попытки.

Простой подход — логирование ошибок:

$response = sendToCRM($data);
if (curl_errno($ch)) {
    error_log("CRM error: " . curl_error($ch));
    // Но всё равно продолжаем — данные сохранены у нас
}

Для критически важных операций (платежи) — используйте транзакции и компенсирующие действия.

Локализация форм

Если сайт поддерживает несколько языков, все подписи, плейсхолдеры и сообщения об ошибках должны соответствовать выбранному языку.

Простая реализация:

Код ITЗагрузка примера кода…

И в HTML:

<label><?= $t['email_label'] ?></label>
<input type="email" name="email" required />
<button type="submit"><?= $t['submit'] ?></button>

Доступность (Accessibility)

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

Каждое поле связано с <label> через атрибут for и id.
Используются семантические теги (<fieldset>, <legend> для групп).
Сообщения об ошибках имеют role="alert" и связаны с полями через aria-describedby.
Кнопки имеют понятные подписи.
Поддерживается навигация с клавиатуры.

Пример:

<label for="email">Email</label>
<input type="email" id="email" name="email" aria-describedby="email-error" />
<div id="email-error" role="alert" class="error">
  <?= htmlspecialchars($errors['email'] ?? '') ?>
</div>

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

Cookie — небольшие фрагменты данных, которые сервер отправляет браузеру через заголовок Set-Cookie. Браузер сохраняет их и автоматически включает в последующие запросы к тому же домену.

В PHP установка cookie:

setcookie('user_lang', 'ru', [
    'expires' => time() + 3600,
    'path' => '/',
    'domain' => '.spirzen.ru',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

Чтение:

$lang = $_COOKIE['user_lang'] ?? 'en';

📌 Внимание
Cookie передаются в каждом HTTP-запросе, поэтому не стоит хранить в них большие объёмы данных. Также они доступны через JavaScript (если не установлен флаг HttpOnly), что делает их уязвимыми к XSS.

Сессии

Сессии — более безопасный способ хранения данных на стороне сервера. При первом вызове session_start() PHP генерирует уникальный идентификатор (PHPSESSID) и отправляет его как cookie. Все последующие запросы с этим ID получают доступ к одному и тому же массиву $_SESSION.

Пример использования для защиты от CSRF:

session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

Сессии идеально подходят для:

Хранения временных данных формы;
Авторизации (хранение ID пользователя);
Флэш-сообщений ("Данные успешно сохранены!").

⚠️ Предупреждение
Никогда не храните в сессии пароли, токены API или другие чувствительные данные. Используйте только идентификаторы.

Обработка форм без перезагрузки — Fetch API и FormData

Современные веб-приложения всё чаще используют асинхронную отправку данных. Это достигается через JavaScript-объекты fetch и FormData.

FormData

Объект FormData автоматически собирает все поля формы, включая файлы, и кодирует их в правильном формате:

Код ITЗагрузка примера кода…

На стороне PHP обработка остаётся полностью идентичной обычной форме:

Данные текстовых полей приходят в $_POST;
Файлы — в $_FILES.

Это означает, что один и тот же обработчик может работать и с классической отправкой, и с AJAX.

Безопасность — защита от массовой отправки (спама)

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

1. Поле-ловушка (honeypot)

Добавьте скрытое поле, которое заполняется только ботами:

<input type="text" name="phone2" style="display:none;" tabindex="-1" />

Если это поле не пусто — запрос отклоняется:

if (!empty($_POST['phone2'])) {
    http_response_code(400);
    exit; // Спам
}

2. Ограничение частоты запросов

Храните метку времени последней отправки в сессии:

$lastSubmit = $_SESSION['last_submit'] ?? 0;
if (time() - $lastSubmit < 10) {
    die('Пожалуйста, подождите 10 секунд.');
}
$_SESSION['last_submit'] = time();

3. reCAPTCHA

Google reCAPTCHA (или аналоги вроде hCaptcha) проверяет, является ли пользователь человеком. Интеграция требует:

Регистрации сайта в консоли Google;
Добавления виджета на страницу;
Проверки токена на сервере через HTTPS-запрос к API Google.

Пример проверки:

$recaptcha = $_POST['g-recaptcha-response'] ?? '';
$response = file_get_contents("https://www.google.com/recaptcha/api/siteverify?secret=YOUR_SECRET&response={$recaptcha}");
$result = json_decode($response, true);

if (!$result['success']) {
    die('Подтвердите, что вы не робот.');
}

💡 Совет
Для внутренних систем (например, админки) достаточно honeypot и ограничения по времени. reCAPTCHA уместна только на публичных формах.

Локализация форм и мультиязычность

Если сайт поддерживает несколько языков, все элементы формы должны соответствовать выбранному языку:

Подписи (<label>);
Плейсхолдеры (placeholder);
Сообщения об ошибках;
Кнопки.

Реализация:

Код ITЗагрузка примера кода…

В HTML:

<label><?= htmlspecialchars($t['email_label']) ?></label>
<input type="email" name="email" required />
<button type="submit"><?= htmlspecialchars($t['submit']) ?></button>

Все строки экранируются через htmlspecialchars() даже если они статичны — это хорошая привычка.

Доступность (Accessibility) и семантика

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

Экранную клавиатуру;
Программы чтения с экрана (скринридеры);
Голосовое управление.

Основные правила

Каждое поле связано с <label> через атрибут for и id:

   <label for="email">Email</label>
   <input type="email" id="email" name="email" />

Группировка связанных элементов через <fieldset> и <legend>:

   <fieldset>
       <legend>Выберите способ доставки</legend>
       <input type="radio" id="delivery1" name="delivery" value="post" />
       <label for="delivery1">Почта</label>
       <input type="radio" id="delivery2" name="delivery" value="courier" />
       <label for="delivery2">Курьер</label>
   </fieldset>

Ошибки озвучиваются скринридером:

   <input aria-describedby="email-error" />
   <div id="email-error" role="alert" class="error">
       <?= htmlspecialchars($errors['email'] ?? '') ?>
   </div>

Фокус виден всегда — не удаляйте outline без замены.
Поддержка клавиатурной навигации — все интерактивные элементы должны быть достижимы через Tab.

Тестирование форм

Форма должна проходить следующие проверки:

Тип теста	Что проверяется
Валидация на клиенте	Правильные атрибуты (`required`, `minlength`, `type="email"`)
Валидация на сервере	Отказ при некорректных данных, даже если клиентская валидация обойдена
Защита от CSRF	Невозможно отправить форму извне
Экранирование вывода	Нет XSS при отображении ошибок или введённых данных
Обработка файлов	Проверка MIME-типа, размера, безопасное имя файла
Многошаговые формы	Невозможно перейти к шагу 3 без прохождения шагов 1–2
Доступность	Проходит проверку через axe или Lighthouse

Автоматизированные тесты можно писать с помощью:

PHPUnit (для серверной логики);
Playwright или Cypress (для end-to-end тестов в браузере).

Итоговая рекомендация по структуре обработчика

Любой обработчик формы должен следовать единому шаблону:

Начало сессии, если требуется.
Проверка метода запроса (POST).
Проверка CSRF-токена.
Получение и фильтрация данных ($_POST, $_FILES).
Валидация каждого поля.
Если есть ошибки — вернуть форму с сообщениями.
Если всё корректно:
- Экранировать/хешировать данные;
- Сохранить в БД или отправить во внешний сервис;
- Выполнить редирект (PRG-паттерн).

Этот подход гарантирует надёжность, безопасность и удобство.

Практика — единый конвейер обработки формы

Для больших форм полезно придерживаться одного конвейера "получить → нормализовать → валидировать → сохранить → ответить":

Код ITЗагрузка примера кода…

Этот каркас хорошо масштабируется и для обычных HTML-форм, и для AJAX-запросов.

Где расширять тему дальше

Работа с сессиями — хранение состояния, CSRF и контроль доступа.
Глобальные переменные и суперглобальные массивы — структура источников входных данных.
Загрузка файлов и валидация — отдельный глубокий разбор upload-сценариев.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

Работа с данными со страницы​

Что такое данные со страницы​

Именование элементов — name и id​

Теги и атрибуты форм​

Основные элементы форм​

HTTP-методы — GET и POST​

GET​

POST​

Как составлять HTML-формы для работы с PHP​

Получение данных в PHP​

Валидация данных​

Базовые правила​

Экранирование данных​

Обработка данных — от формы до базы​

Интерактивная лаборатория​

Работа с таблицами и повторяющимися данными​

Защита от CSRF​

Итоги и лучшие практики​

Работа с файлами через HTML-формы​

Настройка формы для загрузки файлов​

Получение файла в PHP​

Обработка множественных файлов​

AJAX и отправка данных без перезагрузки страницы​

Пример с fetch и FormData​

Безопасность — защита от подделки запросов и инъекций​

SQL-инъекции​

Командная инъекция​

Обработка JSON-данных​

Локализация и кодировка​

Итоговая структура надёжной формы​

Валидация на стороне клиента и её ограничения​

Обработка ошибок и повторный вывод формы​

Работа с таблицами и динамическими формами​

Защита от повторной отправки (Post/Redirect/Get)​

Локализация и многоязычность форм​

Итоговая рекомендация по архитектуре обработки форм​

Многошаговые формы и состояние между шагами​

Подходы к хранению промежуточных данных​

Валидация на каждом шаге​

Защита от прямого доступа к шагам​

Отправка файлов на промежуточных шагах​

Интеграция с внешними API​

Обработка ошибок внешних сервисов​

Локализация форм​

Доступность (Accessibility)​

Работа с cookie и сессиями при обработке форм​

Cookie​

Сессии​

Обработка форм без перезагрузки — Fetch API и FormData​

FormData​

Безопасность — защита от массовой отправки (спама)​

1. Поле-ловушка (honeypot)​

2. Ограничение частоты запросов​

3. reCAPTCHA​

Локализация форм и мультиязычность​

Доступность (Accessibility) и семантика​

Основные правила​

Тестирование форм​

Итоговая рекомендация по структуре обработчика​

Практика — единый конвейер обработки формы​

Где расширять тему дальше​

См. также

🗃phpMyAdmin

🗃phpPgAdmin

PHP - язык веб-разработки

Экосистема PHP-приложений

Что требуется знать перед началом изучения языка программирования PHP

Модель исполнения PHP

История языка PHP

Composer - управление зависимостями в PHP

Настройка веб-сервера для работы с PHP

Локальная среда разработки на PHP

Рекомендации по разработке на PHP

Фреймворки и библиотеки PHP

Работа с данными со страницы

Что такое данные со страницы

Именование элементов — name и id

Теги и атрибуты форм

Основные элементы форм

HTTP-методы — GET и POST

GET

POST

Как составлять HTML-формы для работы с PHP

Получение данных в PHP

Валидация данных

Базовые правила

Экранирование данных

Обработка данных — от формы до базы

Интерактивная лаборатория

Работа с таблицами и повторяющимися данными

Защита от CSRF

Итоги и лучшие практики

Работа с файлами через HTML-формы

Настройка формы для загрузки файлов

Получение файла в PHP

Обработка множественных файлов

AJAX и отправка данных без перезагрузки страницы

Пример с `fetch` и FormData

Безопасность — защита от подделки запросов и инъекций

SQL-инъекции

Командная инъекция

Обработка JSON-данных

Локализация и кодировка

Итоговая структура надёжной формы

Валидация на стороне клиента и её ограничения

Обработка ошибок и повторный вывод формы

Работа с таблицами и динамическими формами

Защита от повторной отправки (Post/Redirect/Get)

Локализация и многоязычность форм

Итоговая рекомендация по архитектуре обработки форм

Многошаговые формы и состояние между шагами

Подходы к хранению промежуточных данных

Валидация на каждом шаге

Защита от прямого доступа к шагам

Отправка файлов на промежуточных шагах

Интеграция с внешними API

Обработка ошибок внешних сервисов

Локализация форм

Доступность (Accessibility)

Работа с cookie и сессиями при обработке форм

Cookie

Сессии

Обработка форм без перезагрузки — Fetch API и FormData

FormData

Безопасность — защита от массовой отправки (спама)

1. Поле-ловушка (honeypot)

2. Ограничение частоты запросов

3. reCAPTCHA

Локализация форм и мультиязычность

Доступность (Accessibility) и семантика

Основные правила

Тестирование форм

Итоговая рекомендация по структуре обработчика

Практика — единый конвейер обработки формы

Где расширять тему дальше