Сокращение URL: какую кодировку лучше всего использовать?

Я добавляю в свой проект функцию, в которой мы создаем ссылки на внутренние материалы нашего веб-сайта, и мы хотим, чтобы эти ссылки были как можно короче, поэтому мы создадим наш собственный «Сокращение URL-адресов».

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

Я подумал о нескольких вариантах:
- Цифры, прописные + строчные (основание 62)
- Цифры, только строчные (основание 36)
- Базовые 32 (http://www.crockford.com/wrmg/base32.html)
- linkpot.net (используется общий сокращенный английский слова)

Конечно, вторые два лучше подходят для других целей, кроме щелчка, а первые два лучше для Twitter.

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

  • Какие символы я могу использовать в URL-адресах, которые не будут закодированы?
  • Какие символы следует использовать? Могут ли некоторые из них оказаться проблематичными? Я думаю, например, о слеш и точка.

Что вы думаете?

ПРИМЕЧАНИЕ. Основная цель этих URL-адресов - Twitter. Имея это в виду, мы, вероятно, должны иметь максимально большой алфавит, поскольку большинство людей будут щелкать мышью. Однако меня интересует ваш опыт общения с людьми, использующими короткие URL-адреса другими способами (по телефону, в печатных материалах и т. Д.). Насколько вероятно, что это могло произойти?

ПРИМЕЧАНИЕ 2: я не делаю «еще один инструмент для сокращения URL», пожалуйста, не осуждайте меня отрицательными голосами. Мы генерируем короткие URL-адреса для внутреннего содержимого на нашем сайте, не позволяя никому сокращать какой-либо URL. Представьте, что Google Maps дает вам короткие URL-адреса, когда вы создаете ссылку на определенную координату.


person Community    schedule 11.09.2009    source источник


Ответы (3)


Я бы пошел с Base-62, он самый короткий. Сокращенный URL-адрес в любом случае не предназначен для ввода вручную, поэтому не беспокойтесь о чувствительности к регистру.

person ZZ Coder    schedule 11.09.2009

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

Вот страница, на которой обсуждается один из способов сделать это.

Вы можете посмотреть RFC2396, чтобы точно выяснить, какие символы безопасны в URI, если вы хотите перепроверить.

person Laurence Gonsalves    schedule 11.09.2009

Мне было бы любопытно узнать немного больше о реализации. Каким образом эти URL-адреса будут «неукороченными» или внутренние страницы, к которым осуществляется доступ, будут сохранены как сокращенные URL-адреса? В любом случае, даже если вы выбрали кодировку [A-Z], вы могли бы сослаться на 26 * 26 * 26 = 17 576 страниц всего с 3 символами; о скольких внутренних веб-страницах вы говорите?

В общем, я бы опирался на требования вашего варианта использования для выбора правильного набора кодировок. Планируете ли вы, что эти ссылки будут доступны "не для щелчка"? Что это за использование и как вы подозреваете, что они изменят кодировку? (Например, использование частей URL-адреса в качестве имени файла в файловой системе без учета регистра уменьшает доступный набор символов.)

Вот информативная страница с набором символов, который вам доступен, когда написание URL.

person fbrereto    schedule 11.09.2009
comment
Спасибо за ваш ответ. Внутри у меня будут сущности, созданные пользователями, которые будут иметь уникальный целочисленный идентификатор. Затем я покажу их как сокращенный URL-адрес, чтобы сделать его короче для твиттера ... Итак, у вас может быть mydomain.com/1525343 или mydomain.com/a4D, что будет означать то же самое для меня, но это будет короче. - person Daniel Magliola; 11.09.2009
comment
Если они будут использоваться внешними клиентами, я бы больше склонялся к более простому диапазону кодирования, например [0-9a-z]. Я бы не стал включать [A-Z], чтобы пользователи могли вручную вводить URL-адреса, не беспокоясь о верхнем / нижнем регистре. Даже с таким диапазоном из 36 символов вы добьетесь огромного сокращения. Например, только 5 символов дают вам 60 466 176 уникальных сокращенных URL. - person fbrereto; 11.09.2009