2

次のようなURLを使用するWebアプリケーションがあります。

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

...そしてそれが生き残るかどうかを確認します。ありがとうございます。

4

7 に答える 7

4

少なくとも少し短くすることができます。現在、128ビットの数値であるGUIDを、基本的に16進数でダッシュを追加した形式で送信しています。GUIDをバイト配列として表示し、それをBase64に変換すると、状況を少し減らすことができます。同様に、「query=academic」は「q=a」である可能性があります。

GUIDは現在36文字を使用しています。Base-64に変換すると、これが22に削減され、14文字節約されます。「query=Academic＆key=」を「q= a＆k =」に置き換えると、さらに13文字が削減されます。合計27文字を削減すると、アンパサンドと等号が存在する場合でも、URLが折り返されない程度に短くなる可能性があります。

もう1つの詳細：Base-64テキストは「=」で終わります。これは「％3D」に16進エンコードされます。解決策は、パディングだけなので、その文字を切り落とすことです。

オリジナルのポスターの功績により、最善の策は次のものの組み合わせであるように見えます。

  1. base-64を使用したコンパクトなGUID。
  2. キー名と、可能であれば値を短くします。
  3. URLを中かっこで囲み、クライアントが適切に解析するように促します。
  4. 可能であれば、キー名をURL書き換えに置き換えて、パスのように見えるようにします。
于 2010-07-19T20:50:15.003 に答える
2

サードパーティのURL短縮サービスを使用できない場合、（Sunnyが提案したようにURL構造を変更する以外に）唯一のオプションは、次のようにURLを山かっこで囲むことです。

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

[ Uniform Resource Identifiers（URI）：Generic Syntax]ドキュメントにあるガイドラインに従うすべての電子メールクライアントは、クリック可能なリンクを表示する必要があります。ただし、これは絶対確実なソリューションではなく、URL短縮サービスに頼ったり、URLを再構築したりすることになります。

于 2010-07-19T20:51:33.580 に答える
1

独自の短縮サービス（理想的なソリューションIMO）をインストールする唯一の代替手段はbase64、URL全体をエンコードすることです（そしてより短いキーを使用することもできます）。ただし、これにより文字列の長さが33％増加し（電子メールクライアントでも破損する可能性が非常に高くなります）、見栄えが悪くなります。

URLをオンデマンドで次のように短縮するURL短縮サービスを構築します。

http://library.example.com/go/586c70bb-5683-419c-aae9-e596af9ab66a
于 2010-07-19T20:48:20.430 に答える
0

次のようなRESTフルURL：

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

IMOを助けるかもしれません。

ユーザーが登録されていない場合、これはそれを行い、事実を確認するメッセージを返します

ユーザーがすでに登録されている場合、アクションは実行されず、ユーザーが登録されたという通知が表示される可能性があります。

URLのルーティングやリクエストの検証などは、リクエストパイプラインを確認するモジュールに任せるのが最適な実装の詳細にすることができます。

HTH。

編集：

以下の@Stevenが指摘しているように、このソリューションには追加のステップが含まれています。

ユーザーがRESTURLをクリックすると、ユーザー名が事前に入力された確認/ログイン画面が起動します。ユーザーはアカウントにログインできます。これは、ユーザーが有効であることの確認です。彼が最初のログインを行うまで、アカウントのステータスは「未確認」である可能性があり、彼の最初のログインで、クリック/リクエストが送信された電子メールからのものであるか、および/またはWebブラウザ。

これにより、ユーザーが実際に有効なログインを行うまで、アカウントは「確認済み」ステータスにならないため、本物の電子メールアカウントでも機能することが保証されます...

于 2010-07-19T20:45:39.120 に答える
0

自分でホストできるパッケージ済みのURL短縮サービスがいくつかあります。これがコードプレックス検索です
http://www.codeplex.com/site/search?query=url%20shortener
これにより、短いURLを社内に保持することができます。


または、http： //library.example.com/Register/Academic/586c70bb-5683-419c-aae9-e596af9ab66aを台無しにするのがはるかに難しいRESTFulURLを実装する方法もあります。
このソリューションはクエリ文字列よりもうまく機能するはずです。電子メールクライアントで通常壊れているのは?、、、=および&

個人的には、RESTFulソリューションが最適だと思います。それでも、「ある程度」意味のある最もクリーンなURLが作成されるからです。

于 2010-07-19T20:47:08.417 に答える
0

GUIDSをYouTubeスタイルのキーに置き換えるのはどうですか

例えばhttp://library.example.com/Register.aspx?q=academic&k=jkGlkNu8

（base-16であるGuidの代わりに）base-64文字列を使用し、それらの厄介なダッシュをドロップすることで、適切な範囲の一意のキーを少量の文字にパックできます。

于 2010-07-19T21:12:13.193 に答える
0

ここで説明する方法の組み合わせはどうですか？

短いURLとキーのBase64エンコーディングを組み合わせると

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

の中へ

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

はるかに読みやすい、IMO。そして、のような文字の欠如？＆＆カットアンドペーストエラーのリスクを軽減します。

于 2010-07-19T21:12:44.270 に答える