Смотрю на UUID в URL и морщусь: 36 символов с дефисами, красота и уродство.
/orders/550e8400-e29b-41d4-a716-446655440000
В феврале услышал в подкасте про Base32 и залип на пару вечеров. Думал, дело на пять минут: перекодировал те же 128 бит в другой алфавит, и вот тебе короткий id. Те же 16 байт, ничего не сжимается, коллизии те же. Просто другое представление.
И правда красиво выходит, 26 символов вместо 36:
/orders/AM788072KD0X99RP8HK5AH0000
Берешь Crockford-алфавит (автор который придумал JSON), а он выкинул
I L O U, чтобы не путать с единицей и нулем и не собирать случайные матерные слова. Такой ID не стыдно продиктовать по телефону.А дальше я наступил на грабли. Думал, Base32 он и есть Base32. Ага... Конечно...
Взял стандартный RFC4648 (
A-Z2-7) и сломал сортировку. Значение 25 это Z, 26 это 2, а в ASCII 2 идет раньше Z. Для UUIDv7, где время в старших битах, это больно: вроде сортируешь по времени, а строки разъезжаются как попало.Лечится сменой алфавита: Crockford или base32hex (
0-9A-V), и порядок строк снова совпадает с хронологией.Собственно, в ULID ровно так и сделано: 128 бит, 26 символов, Crockford, сортировка по времени из коробки.
Что в итоге: в стандартной либе Go этого нет, нужен свой кодек, и БД такой ID за UUID не примет. Так что либо берешь готовый ULID, либо пишешь Encode/Decode сам и не путаешь алфавиты, как я :-)
Ответ на заданный в заголовке вопрос: Скорее миф, чем реальность...