Альтернатива отправке длинных URL-адресов по электронной почте?

Question

У меня есть веб-приложение, которое использует URL, которые выглядят следующим образом:

http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a

(GUID используется вместо простого int для предотвращения угадывания, и это все, что нам нужнона данный момент.)

Проблема: этот длинный URL часто разрывается при отправке по электронной почте.Это люди, отправляющие электронные письма, поэтому я не могу контролировать форматирование.Иногда это ошибка программы отправки электронной почты, иногда - получение, но, несмотря на это, я трачу слишком много времени на общение с людьми с целью устранения проблем.

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

Любые предложения?

Правки

@ Санни: Спасибо за разработку, но мойСитуация отличается от того, что вы предполагаете.Корпоративный клиент (мой) передает этот URL своим сотрудникам, и они используют его для перехода на фирменную страницу регистрации.Они должны предоставить рабочее электронное письмо как часть регистрации, и оно будет отправлено корпоративному руководителю.

Регистрация дает им доступ к базе данных, но то, что они видят, не является специфическим для корпоративного клиента.Так что случайный нарушитель не имеет большого значения;когда корпоративный руководитель отсеивает их, мы приглашаем их подписаться.

@ Everybody: разрыв электронной почты не в пунктуации (?&=), но в некоторой предопределенной строке-длина.Меня тоже удивило.Обратите внимание, что доменное имя длинное, как и путь к виртуальному каталогу, что является частью проблемы.

После прочтения ответов я собираюсь использовать base64 в качестве псевдо-сокращателя, что-то вроде:

http://a.MyLongDomainName.com/?q=a&key=base64_encoded_GUID

... и посмотреть, выживет ли это,Спасибо всем.

Answer 1

Вы можете хотя бы немного его укоротить.Прямо сейчас вы отправляете GUID, который представляет собой 128-битное число, в формате, который по существу шестнадцатеричный с дополнительными тире.Если вы рассматриваете GUID в виде байтового массива и конвертируете его в Base64, вы можете немного его сократить.Аналогично, «query = академический» может быть «q = a».

В настоящее время GUID занимает 36 символов.Преобразование в Base-64 сокращает это до 22, сохраняя 14 символов.Замена «query = acade & key =» на «q = a & k =» сбривает еще 13. Сокращение в общей сложности 27 символов может сделать ваш URL достаточно коротким, чтобы его не переносить, несмотря на наличие амперсандов и знаков равенства.

Еще одна деталь: текст Base-64 заканчивается символом «=», который затем будет закодирован в шестнадцатеричном виде в «% 3D».Решение состоит в том, чтобы отрезать этого персонажа, потому что он просто дополняет.

С учетом оригинальных постеров, похоже, что лучшая ставка - это комбинация вещей:

1. Компактный GUIDс base-64.
2. Сократите имена ключей и, если возможно, значения.
3. Оберните URL в угловые скобки, чтобы побудить клиента правильно его проанализировать.
4. Если возможно,замените имена ключей на переписывание URL, чтобы оно выглядело как путь.

Answer 2

Если вы не можете использовать стороннее средство сокращения URL-адресов, тогда ваш единственный вариант (помимо изменения структуры URL-адреса, как предлагал Санни) - заключить в URL-адрес угловые скобки, например:

<http://library.YourDomainNameHere.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a>

Любой почтовый клиент, который следует рекомендациям, изложенным в документе Унифицированные идентификаторы ресурсов (URI): общий синтаксис , должен отображать ссылку, активируемую щелчком мыши.Однако это не является надежным решением, и вы, скорее всего, в конечном итоге прибегнете к службе сокращения URL-адресов или реструктуризируете свои URL-адреса.

Answer 3

Единственной альтернативой установке собственной службы сокращения (которая была бы идеальным решением IMO), может быть base64 кодирование всего URL (и использование более короткого ключа).Но это увеличило бы длину строки на 33% (очень вероятно, что оно также сломалось бы в почтовых клиентах) и выглядело бы ужасно.

Я бы пошел с созданием службы сокращения URL-адресов, которая сокращает URL-адреса по требованию до чего-то вродеэто:

http://library.example.com/go/586c70bb-5683-419c-aae9-e596af9ab66a

Answer 4

А как насчет комбинации методов, описанных здесь?

Объединение коротких URL-адресов с кодировкой Base64 ключа приведет к

http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a

в

http://l.example.com/register/ac/WGxwu1aDQZyq6eWWr5q2ag

Намного более читабельно, ИМО. А отсутствие символов вроде? и & снижает риск ошибок при вырезании и вставке.

Answer 5

Как насчет замены GUIDS на клавиши стиля YouTube

например, http://library.example.com/Register.aspx?q=academic&k=jkGlkNu8

Используя строки base-64 (вместо Guids, которые являются base-16) и отбрасывая эти надоедливые тире,Вы можете упаковать приличный диапазон уникальных ключей в небольшое количество символов.

Answer 6

Существует несколько расфасованных URL Shorteners, которые вы можете разместить самостоятельно. Вот кодовый поиск
http://www.codeplex.com/site/search?query=url%20shortener
Это даст вам возможность хранить ваши короткие URL в доме

В качестве альтернативы вы могли бы как-то реализовать RESTFul URL, который было бы намного сложнее испортить
http://library.example.com/Register/Academic/586c70bb-5683-419c-aae9-e596af9ab66a
Это решение должно работать лучше, чем строка запроса, просто потому, что в почтовых клиентах обычно ломаются ?, = и &

Лично я считаю, что решение RESTFul лучше всего, поскольку оно создает самые чистые URL, которые все еще имеют «некоторый» смысл.

Answer 7

REST-FUL URL, как:

http://www.yourdomainhere.com/register/academic/{userName_here}

может помочь ИМО.

Если пользователь не зарегистрирован, он сделает это и вернет сообщение, подтверждающее факт

Если пользователь уже зарегистрирован, никаких действий не будет и, возможно, будет показано уведомление о том, что пользователь зарегистрирован.

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

НТН.

EDIT:

Как указано @Steven ниже, в этом решении есть дополнительный шаг:

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

Это также гарантирует, что оно будет работать для аутентичной учетной записи электронной почты, поскольку до тех пор, пока пользователь действительно не введет действительный логин, учетная запись не будет в состоянии «подтверждено» ...