Длинные ссылки

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

http://www.olx.ru/cat-378#%7B%22genes%22%3A%20%5B%22ad_type--1%22%2C%20%22ad_type--2%22%2C%20%22car_brand--hyundai%22%2C%20%22st--1%22%5D%2C%20%22collapsed%22%3A%20%5B%5D%2C%20%22params%22%3A%20%7B%22catg%22%3A%20%7B%22378%22%3A%20%22catg%3D378%22%7D%2C%20%22set_city_filter%22%3A%20%7B%22clear%22%3A%20%22set_city_filter%3Dclear%22%7D%2C%20%22set_city_id_filter%22%3A%20%7B%22clear%22%3A%20%22set_city_id_filter%3Dclear%22%7D%2C%20%22set_zip_filter%22%3A%20%7B%22clear%22%3A%20%22set_zip_filter%3Dclear%22%7D%2C%20%22set_zip_distance_filter%22%3A%20%7B%22clear%22%3A%20%22set_zip_distance_filter%3Dclear%22%7D%2C%20%22nf%22%3A%20%7B%221%22%3A%20%22nf%3D1%22%7D%2C%20%22o%22%3A%20%7B%2269%22%3A%20%22o%3D69%22%7D%2C%20%22p%22%3A%20%7B%221%22%3A%20%22p%3D1%22%7D%7D%7D

Укоротить, что бы получить что то более короткое и человеческое
И что бы потом еще из того короткого формата получать обратно все GET параметры как они были на начальном этапе.

То есть, нужен алгоритм кодирования-декодирования длинных УРЛ-ов.

ПС: Желательно конечно что бы работал быстро
Сам попробую найти способы реализации, и буду здесь их описать. Прошу всех кому интересно, участвовать.

Способ №1.
Не кодировать-декодировать эти параметры а держать их в сессию.
Недостаток. Нельзя хранить ссылки с найденными результатами, что бы зайти позже смотреть.

Параметры запроса можно хранить в сессии, а урл сделать нормальным

На хабре совсем недавно описывали хороший способ, только направление было - поиск в БД по многим параметрам.

AlekartRu, тут то же самое. Перейдите по ссылке, поймете.

WebDesignStudio, так у вас вопрос как сделать, или просто статью забабахать хотите?

Вопрос как лучше сделать. Это для себя нужно. На практику. Та же доска объявлений, ради которой я тут много тем создавал.
Она для меня уже родная. Плюс, думаю и другим полезный материал будет.

Satist, нужен не сервис а алгоритм.

Сервис - и есть намек на алгоритм )

Способ №2.
Каждую комбинацию из GET (или POST) параметров записать в таблицу, и обращаться к ней по ID.
Способ имеет право на жизнь, когда таких комбинаций будет не много. Если параметров большое количество, количество строк тоже будет огромной, естественно скорость будет падать от этого.

Способ №3.
Использовать логику из вот этой темы посилання
Но тут проблема как УРЛ типа ?v1=1&v2=2&v3=3....&vn=n перевести в числовое значение
Или может я туплю, и такой метод тут не пойдет?

Цитата ("WebDesignStudio"):

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

А нельзя передавать параметры формы методом PUT:

<form action="http://your.ser.ver/your/script" method="PUT">

Заодно и логи на сервере, в случае нужды, читать проще будет.

Цитата ("Illarion_SA"):

method="PUT"

А что это за метод? Первый раз о нем слышу.

Можно просто использовать POST. После отсылки формы записывать запрос в табличку, хэшировать и по хэшу потом отдавать повторно.

Цитата ("WebDesignStudio"):

Цитата ("Illarion_SA"):

method="PUT"

а что это за метод? Первый раз о нем слышу.

По умолчанию, данные формы передаются на сервер методом GET: браузер пользователя формирует из параметров формы строку вида name1=value1&name2=value2&... и через знак "&", "пристегивает" ее к концу URL указанного в параметре action тега form. Второй способ передачи параметров - метод POST, этот метод указывается параметром "action=POST" тега form. При использовании метода POST, сервер, после обработки URL, открывает входной поток данных (STDIN) и браузер передает параметры формы во входной поток сервера в виде пар name=value, а сервер перенаправляет полученный поток данных на STDIN скрипта запускаемого по URL. На уровне прикладного скрипта и при использовании соответствующей библиотеки (например модуль CGI perl) доступ к параметрам переданных методами GET и PUT отличий не имеет. К достоинствам метода POST можно отнести существенно больший объем передаваемых формой данных, поскольку при использовании метода GET, все данные формы на стороне сервера помещаются в переменную окружения (QUERY_STRING) максимальная длина которой ограничена в недрах операционной системы (порядка единиц килобайт). К недостаткам метода POST относится то, что переданные параметры не протоколируются в логах сервера (это же, впрочем, можно рассматривать как и достоинство, например, с точки зрения защиты от протоколирования трафика на прокси серверах).

PS. Тысячу извинений: в первом сообщении неправильно указал название метода, вместо "PUT" должно быть "POST".

WebDesignStudio, посилання

Illarion_SA, зачем ему PUT? Никогда не видел чтобы его использовали. GET и POST - да.

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

Цитата ("frig"):

Можно просто использовать POST

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

Цитата ("Crist"):

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

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

WebDesignStudio, это же простой запрос к одной таблице, если правильно настроить все, то будет быстро работать и на миллионе-другом записей. Да и почему бы не чистить таблицу от старых записей? Сомневаюсь, что кому-то нужны поисковые запросы даже и недельной давности статистику можно вести отдельной таблицей.