C# сокращение строки для URL-адреса

StackOverflow https://stackoverflow.com/questions/2052394

  •  20-09-2019
  •  | 
  •  

Вопрос

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

какое было бы лучшее решение?

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

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

Решение

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

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

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

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

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

  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.

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

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

Сервер генерирует глобально уникальные идентификаторы

Опять же, основным преимуществом вышеизложенного является то, что Клиенты могут генерировать свои 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, что все равно довольно много :)

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

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

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

Например:www.google.com с руководством F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4 -> http://www.mysite.com/?q=CEB2

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

Надеюсь это поможет.

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