Есть длинная ссылка типа 
_http://joostina-cms.ru/index.php?option=com_boss&task=show_content&contentid=31&catid=1&directory=5

Есть механизм ЧПУ, который сделает что-то такое
_http://mysite.ru/article/content/5/31/1.html

Но иногда когда статей очень много и хочется получить короткую ссылку, типа
_http://mysite.ru/jHyeg.html

Вопрос как это сделать? 

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

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

PS
можно конечно md5? но они уж точно не короткие будут 


Это сообщение отредактировал(а) Gold Dragon - 30.7.2013, 16:12

создай собственную функцию хеширования, или используй другую

например? чтобы получился "коротки" адрес, да и коллизии не было 

Я вот думаю чтобы что-то такое битовое придумать по типу архиваторов, но знаний не хватает видимо

епт, это ж невозможно...
Нельзя [A,B] взаимно однозначно соотнести с [C,D,E]. Или что лишнее. Или что-то одно соотнесется к нескольким.

Другое дело, что не все символы там обязательны для того, чтобы дать серверу понять, чего вам надо...



В зависимости от ограничений того, что стоит на месте 5, 31 и 1 можно еще больше запаковать. Например:

где R - сокращение для /article/content/
дальше числа 62-ичной системе счисления (описываются символами 0-9a-zA-Z)
5 - число от 0 до Z (0-9a-zA-Z), одна позиция - 62 варианта
00u - число от 000 до ZZZ, 3 позиции - 238328 вариантов
01 - число от 00 до ZZ, 2 позиции - 3844 вариантов

На строне сервера парсится абсолютно однозначно и так же, как если бы по /article/content/5/31/1, вытягиваются данные из базы, только с небольшой предобработкой параметров.

Это сообщение отредактировал(а) Arantir - 31.7.2013, 00:34

Arantir, что-то ты наговорил много, я половина не понял...

Вот смотри самый простой способ. Для ЧПУ однозначно используется таблица ссылок по типу
URL-ссылка -> ЧПУ-ссылка
, т.е. оригинальная -> преобразованная

Как работает ЧПУ.. При формировании контента все ссылки по определённому правилу преобразуются в ЧПУ-ссылки. Записываются в таблицу. заодно проверяются дубликаты: или они по правилу исправляются автоматически или записываются в отдельную таблицу для ручной правки.

А вот самый простой способ создания "коротких" ссылок - это также заносить ссылки в таблицу и получать идентификатор записи.. Т.е. получаются
_http://mysite.ru/1.html
_http://mysite.ru/2.html
_http://mysite.ru/....html
_http://mysite.ru/777.html
не нравятся цифры, можно заменить буквами
_http://mysite.ru/a.html
_http://mysite.ru/b.html
_http://mysite.ru/....html
_http://mysite.ru/afs.html

Но это всё случайно.. а мне нужно правило... Ну например если в адресе
встречается ..com.. то преобразуется в  ...c...
встречается ..abc.. то преобразуется в  ...A...
встречается ..info.. то преобразуется в  ...I...

Вот и нужен механизм сокращения адреса

коллизии однозначно будут, но их можно будет обойти

...

Сколько у тебя вариантов вроде "/article/content/"? Вероятно, не так уж много. Всего несколько. Под которыми может быть много разных страниц. Под остальными же не так уж много страниц, чтобы они послужили поводом для этой темы.
Поскольку их немного, то можно их сократить до одного или двух символов. Например, "/article/content/" соотнести с буквой "a". И хранить это в БД. Но получится всего несколько строк, а не тысячи/миллионы, как если хранить строки для всей ссылки целиком. Можно даже в htaccess эти пару строк прописать, вообще без БД.

Большие числа всегда можно упаковать в какую-то k-ичную систему счисления с большим k. Например, записывать с помощью цифр и латинских букв обоих регистров. Таким образом в трехзначное число влезут 4-х, 5-и и некоторые 6-значные десятичные числа. А в 4 символа даже некоторые 8-значные. 

Если заранее известна длина параметров, то и слэши не нужны. программа сможет и без них порезать строку на нужные части.
Итого вполне можно спаковать /article/content/5/31/1 во что-то типа /r500u01 или /r50u1, если числа не могут быть очень большими. И это не то что однозначно, а даже обратно конвертируемо в /article/content/5/31/1.

Не знаю как вообще можно проще объяснить... Шаблонные строки пакуешь в пару символов. Большие числа пакуешь в систему счисления с более компактной записью.


Это вполне можно так и назвать... Если так понятнее...

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

Это сообщение отредактировал(а) Arantir - 1.8.2013, 03:36

Arantir, где-то мысль уже бродит моя, никак не могу её привести в код  Но уже где-то на правильном пути.. Да, та прав , нужно использовать несколько подходов к адресу...

Сколько угодно.. Это движок, так что компонентов может быть сколько угодно и какие угодно.. Да и при стандартном наборе их придостаточно 
В этом же и суть, мы не знаем какие будут адреса

Я понимаю что вы хотите запаковывать url перебирая сжимая слова по хитрому алгоритму, хранить то будите в базе?
А что если запаковывать не UTL а AI в таблице?

Не которые, не заморачиваются а генерируют рандомное слово из 6  символов.

Это сообщение отредактировал(а) Sanchezzz - 1.8.2013, 12:29

ну конечно..

это что такое?

так это не проблема  если таблицу очистить и заново сгенерить "короткие" ссылки, то они конечно не совпадут. И если кто-то на другом сайте сделал ссылку на конкретный материал, то конечно по ней уже не попасть куда нужно  Да и генерить не нужно, тостаточно идентификатор использовать

AI он же A_I -  Авто инкремент в таблице.  А вот этого делать не стоит=)

Друзья, вопрос бы не стоял если этого "делать не стоит" 

Оставь четверть символов, и будет тебе счастье. 
Вероятность коллизий увеличится многократно, конечно.
Но в реальности, если только специально не подбирать, будет не более одного или двух совпадений.
Поскольку ссылки будут хранится  в базе - проверяй на совпадение, и если совпадает - добавляй, например, [1],[2], итд.

Это сообщение отредактировал(а) Чучмек - 1.8.2013, 14:53

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

Результат


Функция пре это эквивалент print "<pre>"; print_r($arr);
В ходе 1м итераций совпадений не обнаружено не одного.
Чем меньше число тем меньше ссылка Рекомендую начинать с 10 по 1 символ с 62+ по 2 символа итд в геометрической прогрессии.
Число это ID в таблице 
ID(A_I)  link(URL) code(сгкнкрированный код)


И меня тоже интересует ответ на вопрос заданный krundetz

Это сообщение отредактировал(а) Sanchezzz - 5.8.2013, 10:33

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


Sanchezzz, ну это понятно 

Ту так как тебе вариант, а то мне то любопытно)

Sanchezzz, это же не хеш, это перевод индекса в 62ричную систему. И совпадений понятное дело не будет. 
Но это функция от индекса, а не от ссылки.
Да и если добавь два символа  до 64ричной,  преобразование можно сделать на порядок быстрей.

Sanchezzz, это всё работает и это сокращает код, но как правильно сказал Чучмек, это не решает проблему.. Преобразовывать нужно URL а не идентификатор 

PS
кстати, не  уверен что разный регистр букв это разные адреса

наверное решить мою задачу не получится... Или адрес получается длинным или правило не получается..

Как тут предложили, можно просто преобразвоть в md5 и взять только часть строки.. конечно шанс коллизии возможен, но очень маловероятен  

Хотя можно пойти ещё дальше... 
- получить MD5()
- делим на 4
- получаем таблицу из настоящего адреса и 4-х кусков md5
В принципе можно использовать любую часть в адресе, а если вдруг появится дубликат, просто взять за основу другую часть

Тоже самое получается что и я предложил.
Восстановить ссылку исходную по хешу не получится, так зачем мудрить если несколько постами верху готовое.
случаи когда упретесь в лимит числа в PHP можно пойти путем добавления прификса к сылке как на ютубе 
w1<разделитель>sssss
я думаю там похожий алгоритм используется. 
 

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

Чучмек, интересное решение!
но(!) попробуй


ps
как велика вероятность коллизии?

Это сообщение отредактировал(а) Gold Dragon - 5.8.2013, 15:59

Может тогда проще настроить правильный бэкап БД?

Друзья, есть задача, хочется услышать ответ  А то получается, человек спрашивает как починить термостат на "жигулях", а ему отвечают, купи "мерседес"   

krundetz, конечно ты прав и всё это заложено.. Но хочется иметь и такую страховку.. Вот представь сайт висит в сети лет 5, куча ссылок на его материалы в Инете. А тут бах (ну ведь всё бывает) и пути поменялись.. И теперь в интернете куча 404. А как отреагируют на это Поисковики? Однозначно "понижением рейтигна" 

Что-то странное тут творится. Arantir уже давно указал красивое, надежное и эффективное решение проблемы, не требующее БД. Но автор темы продолжает проектировать кривой костыль. Зачем? Решение непонятно? Или отпугивает необходимость дополнительных преобразований сложнее, чем применение стандартной хэш-функции? Ну так эти трудности вполне решаемы, было бы желание.

Уважаемы AVA12, видимо у вас не так много опыта в построении ЧПУ в CMS. Если кратко, то.... если не использовать базу данных (и кеширование), а использовать "преобразование на ходу", то сайт в один прекрасный момент умрёт от увеличении посещяаемости и количества ссылок на странице

Что касается решения Arantir`а, то он привёл преобразование только на основе тех примеров которые я дал  Да и то не доработаное и применимое только для статичных сайтов.

Но для CMS это ничто: ссылки могут быть любые с любым набором и с любым количеством как символов так значений. При этом адрес
это уже ЧПУ-ссылка, преобразованная по определённому правилу(!)
реальная типа таких


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


Это сообщение отредактировал(а) Gold Dragon - 7.8.2013, 12:37

Что мешает  делать из этого  вот это  вместо этого ?
Правило простое - меньше букв (вместо длинных слов) и короче цифры. Можно еще слеши вырезать.

И, вообще... в конце-то концов... ничего не мешает эти же /R500u01 хранить в базе данных. Я привел лишь способ преобразования. Аналог хеш-функции. Ни о каком "преобразовании на ходу" я не говорил. Я лишь говорил об обратимости такого способа сжатия.

Я привел решение в ответ на вот это 
и на это , что, кстати, не противоречит этому
, и плюс ко всему
, то все ссылки можно заново сгенерировать по тому же несложному правилу и они будут точно такими, как до "если вдруг".


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

Arantir, я не про твой код говорил, а отвечал AVA12    (это про "преобразовании на ходу")

что касается твоего решения, то мы просто не можем знать ЧТО заменять на R, сколько таких ЧТО есть и ещё будет. С числами то всё понятно, хотя есть и такие адреса


Понимаешь, что твой вариант наверное идеальное решение для сайтов, где уже известны или возможно узнать все URL, ну или URL имеют очень чёткий формат

Это сообщение отредактировал(а) Gold Dragon - 7.8.2013, 13:29

Смутно подозреваю, что автор темы некорректно поставил задачу, и миелофон выдал коллизию хэша. Давай сначала:

Дано: множество урлов с некоего сайта, множество ЧПУ-урлов с того же сайта. Вопрос: сайт один или их много? Это наш(и) сайт(ы) или посторонние? Мы можем добавить на сайт свой модуль для работы с короткими ссылками? Мы (или админы сайта/ов) можем оперативно отслеживать изменение структуры сайта/ов и обновлять правила преобразования ссылок?

Что нужно получить: короткие ссылки, какждая из которых однозначно соответствует определенному урлу. Вопрос: какие требования предъявляются к коротким ссылкам (макс. длина, набор символов)? Короткая ссылка генерируется для конкретного урла или же для конкретной страницы сайта? Как быть с проблемой изменения структуры сайта/ов и, соответственно, изменения урлов (может, просто игнорировать проблему)?

AVA12, хватит путать всех. В моём вопросе (первое сообщение в теме) чётко сказано что есть и что мне нужно... 

Механизм пишется для полноценной CMS, где возможно установка любых стороних расширений в любом количестве (компонентов, модулей, плагинов и т.п.)


- Да однозначно соответствовать
- Чем меньше тем лучше (сможешь уложить любой адрес в 3 буквы-цифру заплачу)
- Любой допустимый набор символов, но при условии что это ЧПУ, т.е. человекопонятный. (и я не уверен что буквы разного регистра приемлимы, а не одно и тоже)
- короткая ссылка конечно же для всего сайта (за некоторым исключением: внешние ссылки, ajax, ссылки управления и администрирования и т.п.)
- Структура однозначно может быть любой и меняться как угодно...

Я же сказал, что полноценный ЧПУ-механизм в моей CMS есть. Но я хочу сделать ещё один для определённых типов сайтов, например, каталогов или магазинов


Это сообщение отредактировал(а) Gold Dragon - 7.8.2013, 14:39

Ага, значит, миелофон сработал штатно, и строить деревянный небоскреб не нужно.

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

Если же модулю генерации коротких урлов неизвестны правила формирования исходных ссылок, то задача выглядит невыполнимой. Урл может содержать транслитерированное название объекта или раздела - и что с ним делать? Кодировать побуквенно смысла нет. Искать ид объекта в БД по этому имени? А в какой таблице? Как быть с совпадающими именами? А может, эти имена вообще не нужны, а вставлены только для красоты и человекопонятности?

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

1. дело в том что тебе ответили, и ответили абсолютно верно
2. ты говоришь что тебе этот вариант не подойдет
3. хорошо, спрашиваем по чему
4. ты отвечаешь, что по той то и той то причине
5. ну так поэтому тебя и говорят, что при существование записей об однозначном соответствии урлов страницам в бд, то что ты придумываешь избыточно. Тебе бы слово никто ни сказал об избыточности, если бы аписей в БД не было, и какую страницу отдать по урлу определялось на лету.

В том то и дело что это не будет страховкой. 
Если у тебя все хранится в базе, и если у тебя по какой то причине БД накроется, а бэкап окажется битым, то ты все равно не восстановишь урлы в первоначальном виде. У тебя ничего для этого не будет ни страниц ни указания соответствий урлов страницам. Сами то урлы можно будет узнать со сторонних сайтов, только толку тебе от них будет 0.

можем, в том то и дело что R четко соответствует article, это правило которое мы закладываем, другие слова будут сокращаться по другим правилам, причем мы можем сделать автоматическую генерацию правил в файл или БД.

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

Это сообщение отредактировал(а) krundetz - 7.8.2013, 16:33

любой не получиться, в три буквы и цифру влезет всего (28+10)!/(3!*(28+10-3)!) = 8436 урлов всего, что для серьезного проекта мизер


тебе нужен не еще один, а изменить этот, особенно учитывая это


ИМХО тебе следует расписать детальный план что есть на входе, что должно быть на выходе, а самое главное почему именно так, пока ты смутно представляешь общию картину, либо не можешь объяснить ее нам

Это сообщение отредактировал(а) krundetz - 7.8.2013, 16:50

сколько эмоций... ну начну тогда по порядку.. 

немножко не правильный подход.. Если разработчик не придумал, это должен сделать "владелец" CMS. А разработчик может отказаться от "стандартной" переработки URL`а в более "компактное"

а правило никто не скрывает.. У меня очень подробное описание механизма создания своего SEF (ЧПУ)... Если не хочешь заморачиваться, доверься встроенному, если хочешь , то пиши свой. Аналогичное должно быть и для коротких ссылок.

ну и теперь с товарищем krundetz поговорим  Хороший ты человек, и был я в Сормово  Но...

Я отлично знаю что хочу  И картина вся извстно и механизмы преобразования тоже. И хватит усложнять задачу то  Да и я уже практически решил свою задачу и подсказал мне её Чучмек. Не именно его решение , но мысль именно в том направлении.. 
А суть простая: делаем хэш и уменьшаем количество знаков до тех пор, пока количество коллизий будет критичным по отношению к количеству потерь при удалении дублей. И всё это отдаём на регулированию конечному владельцу сайту. Т.е. минимум зависит от пользователя, максимум - полный хэш.

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

Добавлено @ 19:05
и ты очень прав.. даже маленький проект может иметь очень много динамических страниц.. Мы же говорим не о выводе контента только.. Но и о выводе при определённой сортировке, постранично, полным или сокращённым вариантом, с комментариями или нет и т.п. и т.д. То есть реально имея 100 материалов мы можем получить примерно 200-400 вариантов (имеется в виду URL`ов). И получается что "короткий адрес" реально будет 6-8 знаков...
Ну и как я сказал выше... механизм в принципе понятен, остальное нужно просто отдать на решение администратору сайта... 


Это сообщение отредактировал(а) Gold Dragon - 7.8.2013, 19:11

В изначальной постановке проблемы были опасения по поводу возможной потери базы коротких ссылок. Но ведь при использовании коротких хэшей проблема остается! Так придется хранить таблицу (не кэш!) отношений (урл, короткая_ссылка) - как для обнаружения и разрешения коллизий, так и для того, чтобы сервер мог понять, что от него хотят. Даже частичная потеря этих записей практически убивает механизм коротких ссылок. Так что же, три страницы флуда - только ради тривиального и совершенно очевидного "решения", которое ни хрена не решает поставленную задачу?

Дружище, а ты вообще читаешь что я пишу и что другие пишут? У тебя есть своё мнение или своё решение? Нет ? тогда о чём вообще ты говоришь, к чему всё это? всё что ты спросил я уже ответил в той или иной степени. 

PS
кстати, что за сленг ?  Ну посмотри хотя бы его значение, ну или просто перевод с английского   (я про "флуд" и т.п.) Сам то зачем вообще тут пишешь? ( я про форум вообще)