c# сокращение строки для url

Я хочу уникально сократить идентификаторы строк-файлов для использования в URL-адресах, таких как бит.ly etc. Я могу использовать идентификаторы из БД, но я хочу, чтобы URL-адреса были случайными.

Что было бы лучшим решением?

сайт будет мобильным сайтом, поэтому я хочу, чтобы он был как можно короче

6
bit.ly c# url-shortener

5 ответов

вы не можете "однозначно сократить" произвольные строки. Принцип ячейки и все такое.

то, что вы хотите сделать (и, AFAIK, что делают службы сокращения url),-это сохранить базу данных всего представленного и короткую строку. Тогда вы можете посмотреть его в базе данных.

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

7

существует два метода реализации картографического сервиса, подобного описанному вами.

  1. клиенты отправляют глобально уникальные идентификаторы или
  2. сервер генерирует глобально уникальные идентификаторы

клиенты представляют глобально уникальные идентификаторы

насколько я знаю, 1. следует пытаться только с Guids, Если вы не изобрели аналогичное средство, чтобы втиснуть достаточно различную информацию в короткий байтовый поток. В любом случае, если у вас есть поток байтов, представляющих глобальный уникальный идентификатор, вы можете сделать что-то вроде этого

// source is either a Guid, or some other globally unique byte stream
byte[] bytes = Guid.NewGuid ().ToByteArray ();
string base64String = Convert.ToBase64String (bytes).Trim ("=");

чтобы получить читаемую пользователем строку буквенно-цифровых символов, которая выглядит случайной, но избегает столкновений, присущих другим случайным схемам. А Guid содержит 16 байт или 128 бит, что переводится примерно в 19 символов для полной кодировки Base64.

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

если вы идете по этому маршруту, рассмотрите Google ' ING глобально уникальные потоки байтов или такие. О, и ДЕРЖИТЕСЬ ПОДАЛЬШЕ ОТ СЛУЧАЙНЫХ БАЙТОВ, в противном случае вам придется построить разрешение столкновения НА ваш крошечный генератор Uri.

сервер генерирует глобальный уникальный ids

опять же, основным преимуществом вышеизложенного является то, что клиент может генерировать свои Uris априори. Особенно удобно, если вы собираетесь отправить длительный запрос, который вы хотите проверить. Это может быть не особенно актуально для вашей ситуации и может обеспечить только ограниченную ценность.

таким образом, в стороне, сервер-ориентированный подход, в котором один орган генерирует и выдает идентификаторы, может быть более привлекательным. Если это маршрут вы выберите, тогда единственный вопрос в том, как долго вы хотели бы ваш Uri?

предполагая желаемую длину 5 символов, и предположим, что вы идете с кодировкой Base64, каждый идентификатор может представлять до 5 символов по 7 бит на символ, равный 35 битам или 2^35 [34 359 738 368] различные значения. Это довольно большой домен. *

тогда возникает вопрос о возврате значения для данного представления. Вероятно, есть очень много способов сделать это, но я бы пошел с что-то вроде этого,

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

улучшения или оптимизации могут включать

  • не перечисляйте каждое значение в диапазоне [0, 2^35], вместо этого перечислите управляемое подмножество, скажем, 100 000 значений за раз, и когда все значения потребляются, просто создайте другое 100 000 значений в последовательности и продолжения
  • добавьте дату истечения срока действия к значениям и утилизируйте просроченные значения в конце дня
  • распространяйте свой сервис, при распараллеливании вашего сервиса просто раздайте небольшие взаимоисключающие подмножества вашего бесплатного списка распределенным сервисам

вывод

суть в том, что вы хотите гарантировать уникальность, поэтому столкновения - это большое нет-нет.

*=34 359 738 368 размер из необработанного домена это все идентификаторы длины от 0 до 5. Если вы заинтересованы в ограничении всех идентификаторов минимальной и максимальной длиной 5, то ваш домен выглядит как все идентификаторы длиной от 0 до 5 (2^35) меньше всех идентификаторов длиной от 0 до 4 (2^28) 2^35 - 2^28 = 34 091 302 912, который все еще довольно большой:)

5

хранить случайные буквенно-цифровые строки и использовать для коротких URL. сделайте это длину, которую вы считаете лучшей для своего сайта, и это пользователи, такие как www.yoursite.com/d8f3

0

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

0

Эй, nll, как вам сказали несколько других людей.. Если вы начнете сжимать url-адрес во что-то маленькое, вы не сможете сохранить его уникальным. Тем не менее, вам нужно сделать свое собственное кодирование для каждого url, представленного вам. Один из способов (простой) сделать это-попытаться создать базу данных из представленных URL-адресов, а затем создать поле guid для каждого, а затем получить подстроку из него, гарантируя, что каждый раз, когда вы регистрируете что-то, полностью отличается от предыдущего.

для пример: www.google.com с guid F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4 ->http://www.mysite.com/?q=CEB2

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

надеюсь, что это помогает.

-2