Почему веб-сайты генерируют случайные алфавитно-цифровые строки для URL вместо того, чтобы использовать идентификаторы строки?

На самом деле это не случайные строки. Обычно это числа (обычно идентификаторы строк), закодированные в кодировке Base-36 (очевидно, не всегда , но многие используют его).

Почему они его используют? Потому что числовая строка в кодировке Base-36 короче оригинала.

Например: 1234567890 в Base-36 kf12oi , почти на 50% короче.

См. Эту статью в Википедии . Проверьте раздел «Использование на практике», чтобы узнать, кто его использует.

Я полагаю, это для сокрытия информации и добавления / увеличения количества информации, которую можно передать с помощью этого параметра.

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

В некоторых средах это также используется для установки переменных состояния для сеанса. Например, если у вас есть приложение ASP.Net, которое использует сеансы без файлов cookie, вы найдете аналогичный код в URL-адресе.

Честно говоря, я не уверен, почему они не использовали уникальный идентификатор (или ObjectID, или что-то еще в зависимости от базы данных). представляя идентификатор в базе 10, они представляли его в более высокой базе (например, 64 или что-то еще, что поддерживается в URL-адресах), чтобы идентификатор был более компактным в строке запроса? (прочтите: wli4l73Chc0 - некоторое число в десятичной системе счисления)

Наличие необработанных идентификаторов строк или других немодифицированных параметров базы данных в URL-адресах является плохой практикой безопасности. Намного лучше иметь хэши в каком-нибудь большом домене.

Я поддержал ответ Роба, но я также немного остановлюсь на одном из рисков.

Если вы публикуете ссылку типа Почему веб-сайты генерируют случайные буквенно-цифровые строки для URL-адресов вместо использования идентификаторов строк? где 258510 - это идентификатор базы данных, кто-то пытается взломать ваш сайт и попытается подключиться к https://stackoverflow.com/questions/2581511 .

При использовании stackoverflow это может не быть идентификатором базы данных, а вопросы о stackoverflow не должны быть частными, так что это не имеет большого значения, даже если это так.

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

Конечно, есть вещи, которые вы можете и должны сделать, чтобы заставить его отказаться от показа данных, если они не принадлежат им, но все же лучше сделать так, чтобы URL-адрес не определял идентификатор базы данных. Как заметил Роб, лучше иметь хэш в каком-то гораздо более крупном домене или индекс на основе сеанса в наборе данных, уже определенных как подходящие для отображения пользователю и доступных только в рамках сеанса, вошедшего в систему.