Как создать короткий URL из 6‑символьного кода на базе 62

We need to produce final answer. The analysis above is too long. Let’s produce final translation.A 6‑символьный код может хранить 62⁶ ≈ 56 миллиардов уникальных значений, так что в нём можно разместить кучу URL‑ов.
Если использовать автоинкрементный ID, просто преобразуйте это число в систему счисления base‑62; это даст уникальный, безколлизийный код, который естественно растёт вместе с базой данных.
Можно также применить собственный делитель‑или хеш‑схему, но она будет выглядеть чуть более «шикарной» и всё равно потребует проверки коллизий, если вы не будете считать ID источником истины.
Base‑62 — самый прямолинейный, широко поддерживаемый и легко обратимый вариант, поэтому обычно он и выбирают для простого сокращения URL.

Содержание

• Почему 6 символов достаточно
• Base‑62 кодирование автоинкрементного ID
  • Алгоритм преобразования
  • Обработка ведущих нулей и паддинга
• Подходы с пользовательским делителем
  • Сопоставление с пользовательским алфавитом
  • Плюсы и минусы по сравнению с base‑62
• Генерация кода на основе хеша или случайных чисел
  • Обработка коллизий
  • Когда стоит использовать хеш
• Практические советы по реализации
• Итоги и рекомендации

Почему 6 символов достаточно

Вы когда‑то задумывались, почему 6 символов хватает?
Набор a–z, A–Z, 0–9 даёт 62 символа.
Кол‑во различных 6‑символьных строк равно 62⁶ = 56 800 235 584.
Даже при миллиардах URL‑ов пространство остаётся огромным, а вероятность «перехода» в конец практически нулевая для большинства приложений — так что в ближайшее время с дефицитом не столкнётесь.
Если же вы предвидите более 50 миллиардов URL, просто увеличьте длину до 7 или 8 — это всё ещё удобно читается. Просто поднимите длину.

Base‑62 кодирование автоинкрементного ID

Давайте разберём шаги.

Алгоритм преобразования

1. Начинаем с целого ID (например, 123456).
2. Повторно делим число на 62, записывая остаток каждый раз.
3. Сопоставляем остаток с символом (0‑9 → 0‑9, 10‑35 → a‑z, 36‑61 → A‑Z).
4. Разворачиваем собранные символы, чтобы получить окончательный код.

def to_base62(num):
    alphabet = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
    if num == 0:
        return alphabet[0]
    digits = []
    while num:
        num, rem = divmod(num, 62)
        digits.append(alphabet[rem])
    return ''.join(reversed(digits))

Согласно статье в Википедии о Base‑62, этот алгоритм гарантирует взаимно однозначное отображение между числами и строками, обеспечивая уникальность и отсутствие коллизий — ни один ID не пересечётся.

Обработка ведущих нулей и паддинга

Если хотите, чтобы каждый код был ровно 6 символов, добавьте паддинг слева (или любой выбранный символ) до длины 6. Так все коды будут одинаковой длины.
Поскольку 62⁶ покрывает все 6‑символьные комбинации, паддинг не создаст дубликатов.

Подходы с пользовательским делителем

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

Сопоставление с пользовательским алфавитом

Вместо 62 можно взять, например, 95 печатаемых ASCII‑символов и составить собственный алфавит, исключив путаницу (0, O, I, l). Так можно избежать ошибок при чтении.
Алгоритм остаётся тем же, только алфавит меняется. Некоторые сервисы используют «URL‑дружелюбный» алфавит, который исключает неоднозначные символы.

Плюсы и минусы по сравнению с base‑62

Для большинства задач лучше держаться base‑62, чтобы не тратить время на отладку и ошибки, пока не будет веская причина исключать конкретные символы. Это и есть обычный совет.

Генерация кода на основе хеша или случайных чисел

Если вам нравится идея хеширования, вот что нужно знать.

Обработка коллизий

Хеш длинного URL (например, SHA‑256, MurmurHash) и обрезка до 6 символов дают детерминированный короткий код, но это не гарантирует отсутствие коллизий.
Обрезка вводит теоретическую коллизию: два разных URL могут получить одинаковую 6‑символьную строку.
Поэтому всегда проверяйте базу данных перед вставкой; если коллизия, генерируйте новый код (например, добавьте счётчик, используйте другой хеш или добавьте соль).

Когда стоит использовать хеш

• Вы хотите, чтобы один и тот же длинный URL всегда давал один и тот же короткий код в разных развертываниях (детерминированное отображение).
• Вы хотите избежать хранения длинного URL, хранить только его хеш.
• Вы готовы к редким проверкам коллизий и повторным попыткам.

Для типичного URL‑сокращателя, где каждый пользователь ожидает уникальный код и вы контролируете базу, автоинкремент + base‑62 проще и гарантирует уникальность без проверок во время выполнения. Это самый надёжный вариант.

Практические советы по реализации

Небольшой чек‑лист:

1. Используйте автоинкрементный PK (id AUTO_INCREMENT) как источник истины.
2. Кешируйте преобразование в памяти или в ключ‑значном хранилище, если трафик чтения высок.
3. Добавьте уникальный индекс на колонку code в БД, чтобы гарантировать уникальность.
4. Не публикуйте raw ID в URL; всегда используйте закодированный код.
5. Следите за счётчиком; когда приближаетесь к 62⁶, подумайте о переходе на 7‑символьный формат или о комбинированном ключе.
6. Используйте готовые библиотеки (hashids, shortid, nanoid), если хотите библиотечное решение с поддержкой пользовательских алфавитов и коллизий.

Итоги и рекомендации

В итоге:

• Base‑62 + автоинкремент даёт чистый, безколлизийный, обратимый код.
• Паддинг до 6 символов делает все коды одинаковой длины; пространство легко хватает миллиардам URL.
• Пользовательский алфавит полезен, если нужно исключить неоднозначные символы; иначе base‑62 проще.
• Хеш‑схемы пригодятся, если нужна детерминированность, но требуют проверки коллизий и усложняют код.
• Держите схему БД простой: id, long_url, short_code с уникальным индексом на short_code.
• При приближении к пределу 62⁶ переходите на 7‑символьный формат или комбинируйте ключи.

Следуя этим рекомендациям, вы создадите URL‑сокращатель, который будет надёжным, масштабируемым и простым в обслуживании.