Вопрос

У меня есть пара форм поиска: одна с ~50 полями, а другая с ~100.Обычно, как сказано в спецификации HTML, я выполняю поиск с использованием метода GET, поскольку данные не изменяются.Я еще не сталкивался с этой проблемой, но мне интересно, скоро ли у меня закончится место для URL-адреса?

Предел Интернет Эксплорер составляет 2083 символа.В других браузерах есть гораздо более высокий предел.Я использую Apache, поэтому ограничение составляет около 4000 символов, а IIS — 16384 символа.

При 100 полях, скажем, средняя длина имени поля 10 символов, это уже 5000 символов... потрясающе в форме из 100 полей, у меня еще не было никаких ошибок.(25% полей выбираются несколькими способами, поэтому длина поля намного больше.)

Итак, мне интересно, какие у меня есть варианты.(Укорачивать формы не вариант.) Вот мои идеи:

  • Используйте ПОСТ.Мне это не очень нравится, потому что сейчас пользователи могут добавлять в закладки свои поисковые запросы и выполнять их снова позже — чертовски приятная функция.
  • Запустите JavaScript по форме, чтобы определить, какие поля отличаются от полей по умолчанию, заполните другую форму и отправьте ее.Пользователь, конечно, оставит в закладках сокращенную версию.

Есть еще идеи?

Кроме того, кто-нибудь знает, является ли длина закодированной длиной или просто текстом?

Я разрабатываю PHP, но, вероятно, это не имеет значения.

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

Это было полезно?

Решение

Будут ли ваши пользователи действительно использовать все 50–100 полей для поиска?Если они используют только несколько, почему бы не отправить поиск на «промежуточную» страницу, которая с помощью header() перенаправляет их на страницу результатов с только измененными пользователем полями в URL-адресе?На странице результатов будут использоваться значения по умолчанию для полей, которых нет в URL-адресе.

Другие советы

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

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

В порядке предпочтения я бы

  1. Разделите форму и используйте сохранение состояния на стороне сервера.
  2. Переключитесь на POST, а затем сгенерируйте и перенаправьте на более короткий URL-адрес POST, который разрешится с тем же результатом.
  3. Сдаться ;)

В комментарии вы упоминаете, что многие поля «скрыты и могут быть открыты по мере необходимости».

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

Это вариант форм «Марка и модель», онлайн-страхования и т. д.использование страниц - выберите марку, отправьте обратно на сервер и получите список моделей этого производителя.

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

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

TinyURL — хороший пример:Вы даете ему очень длинный URL-адрес, он сохраняет его в БД, дает вам уникальный идентификатор для этого URL-адреса, а позже вы можете запросить длинный URL-адрес, используя этот идентификатор.

В PHP это будет что-то вроде:

<?php
if (isset($_GET['token']))
{
    $token = addslashes($_GET['token']);
    $qry = mysql_query("SELECT fields FROM searches WHERE token = '{$token}'");
    if ($row = mysql_fetch_assoc($qry))
    {
        performSearch(unserialize($row['fields']));
        exit;
    }
    showError('Your saved search has been removed because it hasn\'t been used in a while');
    exit;
}
$fields = addslashes(serialize($_POST));
$token = sha1($_SERVER['REMOTE_ADDR'].rand());
mysql_query("INSERT INTO searches (token, fields, save_time) Values ('{$token}', '{$fields}', NOW())");
header('Location: ?token='.$token);
exit;
?>

И запускайте скрипт ежедневно:

<?php
mysql_query('DELETE FROM searches WHERE save_time < DATE_ADD(NOW(), INTERVAL -200 DAY)');
?>

Кроме того, кто -нибудь знает, является ли длина кодированная длина или просто простой текст?

Я предполагал, что это закодированная длина.Я сделал простой тест:текстовая область и кнопка отправки в упрощенном PHP-скрипте.
Загрузил страницу в IE6, вставил в текстовое поле текст на французском языке, 2000 символов.Если я нажму кнопку «Отправить», ничего.Мне пришлось сократить длину текста, чтобы иметь возможность отправить его.

Другими словами, ограничение в 2083 символа — это в точности максимальная длина URL-адреса, обнаруженного в адресной строке после отправки запроса GET.

Я бы выбрал решение JavaScript:при отправке проанализируйте форму, создайте вторичную форму с hidden атрибуты и отправьте их.

Некоторые стратегии по сокращению выпуска:

  • Как вы заметили, вы уже можете пропустить все значения, оставленные по умолчанию (нет поля, нет значения).
  • Если у вас есть форма, подобная той, что на Обработка поиска по форуму вы можете сгруппировать все состояния флажков только в одной переменной, например.с помощью буквенной кодировки.
  • Используйте короткие value атрибуты (в select например).

Примечание:если страница поиска на самом деле состоит из нескольких независимых форм, где пользователи заполняют только тот или иной раздел, можно сделать несколько отдельных форм.
Может не относиться к вашему случаю и может показаться очевидным, но стоит упомянуть для протокола...^_^

Можно философски взглянуть на отправку результатов поиска POST как на создание сохраненного поиска (особенно, когда поиск является таким же сложным объектом, как тот, который создают ваши пользователи).В этом случае вы можете принять сообщение для создания поиска, а затем перенаправить его с помощью GET для получения соответствующих результатов поиска (post/redirect/get).

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top