Алгоритм сокращения URL - PullRequest
Новая
       6

Алгоритм сокращения URL

20 голосов
/ 01 января 2011

Теперь речь идет не только о сокращении URL, но моя цель такова, так что давайте посмотрим на это так. Конечно, шаги по сокращению URL:

  1. Взять полный URL
  2. Создайте уникальную короткую строку, которая будет ключом для URL
  3. Сохраните URL-адрес и ключ в базе данных (здесь идеально подходит хранилище значений ключей)

Теперь о втором пункте. Вот что я придумала: 

ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
UUID uuid = UUID.randomUUID();
dos.writeLong(uuid.getMostSignificantBits());
String encoded = new String(Base64.encodeBase64(baos.toByteArray()), "ISO-8859-1");
String shortUrlKey = StringUtils.left(encoded, 6); // returns the leftmost 6 characters
// check if exists in database, repeat until it does not

Это достаточно хорошо?

Ответы [ 2 ]

4 голосов
/ 01 января 2011

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

Так что ваш подход похож на то, что я сделал.

2 голосов
/ 01 января 2011

Ну, что вы подразумеваете под сокращением URL?

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

Пример с Amazon: http://www.amazon.de/Bauknecht-WA-PLUS-614-Waschmaschine/dp/B003V1JDU8/

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

Однако вы можете сохранить ссылкиочистите и проверьте, правильно ли это, и сделайте 301 переадресацию на реальный URL или поместите канонический URL, если обнаружится неправильный URL.

Однако:

Если вы хотите сделать что-то вроде TinyURL , мой ответ однозначный.

Это недостаточно хорошо.

Ну, это зависит.

Это не "безопасно".Было бы довольно легко угадать URL.Лучшим подходом было бы использование некоторой криптографической функции, такой как SHA-1 / MD5.

Когда дело доходит до столкновений, я не могу точно сказать.GUID был разработан, чтобы не было коллизий, но вы используете только первые 6 символов.Я не знаю, что именно они представляют в алгоритме.Но это определенно не оптимально.

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

В проекте, который я сделал, я использовал что-то вроде

/ database-primary-key / hash-of-primary-key-with-some-token-or-client-information /

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

...