11

他の訪問者を送ってくれるユーザーにプロモーションを提供しています。これはクライアント側で行われます。

動的 GET パラメータを使用してこれをhttp://www.mysite.com?app_source=user_id行うことができます。たとえば、ハッシュを使用してこれを行うことができますhttp://www.mysite.com#app_source,user_id。

これらの方法のいずれかに長所と短所はありますか?

4

9 に答える 9

8

GET リクエストに対してこれを行う標準的な方法は、単純にクエリ文字列を使用することです。

http://www.mysite.com?app_source=user_id

次のような URL アンカーを使用する場合

http://www.mysite.com#app_source,user_id

アンカー部分 ( #app_source,user_id)はサーバーに送信されません

たとえば、この関連する質問を参照してください。

ここに別の関連する質問があります

アンカーは、ページ上のどこに移動するかをブラウザーに伝えるためのクライアント側のフラグにすぎません。

リダイレクトの問題に対処するには、リダイレクトする前にクエリ文字列を処理し、必要なキーと値のペアを追加/削除してからリダイレクトします。

PHP を使用すると、クエリ文字列に直接アクセスできます。$_SERVER['QUERY_STRING']

解析request.uriできるRailsの用途

また、 のような空想的なものを見るfacebook.com/#stuffと、アンカー部分はクライアント側の JavaScript で処理されます。したがって、これを行うことはできますが、この回答の上部で推奨されているような通常の GET リクエストを送信する ajax コードを作成することになります。

複雑さを加える理由 #よりも見た目が好き?ですか？

于 2012-07-12T17:39:25.363 に答える
7

アプローチを使用し?ます。なんで？それは、ページ間で任意のデータを渡す方法だからです。

#特にページアンカーに使用されます。

セマンティクスとベスト プラクティスはさておき、これには実際的な理由もあります。ユーザーが訪問者をページのアンカーに送ったときに何が起こるかを考えてみてください。ハッシュ アプローチを使用することはできません (少なくとも単純な方法では)。

したがって、ここで概説したアプローチに従います。

function $_GET(q,s) {
    s = s ? s : window.location.search;
    var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
    return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}

var app_source = $_GET('app_source');

次に、次のような URL を持つことができます。http://www.mysite.com?app_source=user_id#anchor

于 2012-07-12T17:44:10.043 に答える
5

クエリ文字列

  • Google アナリティクス、サーバー ログなどには URL の記録があり、後の分析に役立つ場合があります。
  • URL が複数あるとキャッシュが難しくなり、Google が混乱する可能性がわずかにあります。

ハッシュ

  • 分析とサーバー ログは、ハッシュ パラメータを表示しない/注意を払わない

これを処理するよりセマンティックな方法は、おそらくクエリ文字列パラメーターを使用することですが、それほど強力ではありません。上記のポイントのいずれも関連しない場合は、クエリ文字列の方が一般的であるため、おそらくクエリ文字列に固執するでしょう.

他の人が統合するサービスを構築していて、(クエリ文字列を介して) アプリケーションに情報を返す必要がないようにする場合は、ハッシュ パラメーターを使用するのが確実なオプションのように思えます。

于 2012-07-12T17:42:22.010 に答える
3

W3Cはここで言います：

当然のことながら、サーバーが GET 要求を実行した結果として副作用を生成しないことを保証することはできません。実際、一部の動的リソースはそれを機能と見なしています。ここでの重要な違いは、ユーザーが副作用を要求したわけではないため、副作用について責任を負うことはできないということです。

于 2012-07-12T17:51:01.473 に答える
3

ハッシュを使用します。

なんで？

サードパーティのプラグインを開発しており、引数のいずれかがサイト開発者によるユーザーではないかどうかがわからないためです。使用されている get パラメーターの 1 つをオーバーライドすると、ネイティブ アプリ開発者によってサーバーに渡されたいくつかの重要な情報が破棄される可能性があります。また、http: //somepage.com/とhttp://somepage.com/?app_source=user_idのような重複したページを持つアプリ ホルダーを作成したくありません。多くのユーザーがそのページを参照するため、次のようになります。それらの多くを作成します。

ハッシュは最も安全なオプションであり、すべてのページで使用できます。

于 2012-07-13T09:09:35.360 に答える
2

ハッシュは行く方法です。

選択肢は 2 つしかありません。1 つは GET パラメータで、2 番目は # です。

? パラメータを取得

get パラメータは、検索エンジンと 2 つの URL によってインデックス化でき、2 つのhttp://www.yoursite.com/別々のhttp://www.yoursite.com/?app_id=123ページにすることができます

私のサイトの1つでこれを使用しましたが、Googleから次のようなメールが届きました While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:

彼らが言及したリンクは問題なく正常に機能していますが、それでもこれらのエラーが発生し始めています。

# ハッシュ

ハッシュは、SEO の動作を変更しないため、優れています (多くの人は影響があると言うでしょうが、私はそうは思いません)。

最後に、app_sourceJavascript を使用して を取得し、それをサーバーに渡すだけです。だから、好きなようにできます。もし私があなただったら、きっと HASH を使うでしょう

于 2012-07-17T16:07:43.177 に答える
1

あなたの方法はどちらも良くありません。これを行う究極の方法は、URL セグメントを使用することです。

App と UserId で区別したい場合:

http://www.mysite.com/appName/UserID/

または UserId のみ:

http://www.mysite.com/UserID/

しかし、私は個人的に AppName と UserName の両方を使用します。

http://www.mysite.com/appName/UserName/
于 2012-07-12T18:14:47.190 に答える
0

「#」記号を促進した今日のいくつかの最新の Web アプリケーションに基づいて、Twitter のような SPA (Single Page Application) をサポートするのに非常に役立ちます。「?」のみを使用してください。サイン。

于 2012-07-12T17:40:43.770 に答える
0

簡単な方法は、ユーザー ID を指定した GET パラメーターを使用して、誰かによって参照されているかどうかを確認することです。

http://www.mysite.com/?ref=1128721

次に、紹介について詳しく知りたい場合は、ユーザーが実際にリンクをクリックした URL を確認することもできます$_SERVER['HTTP_REFERER'](php を使用している場合)。このようにして、リンクがジャンクの場所や「自動アクセス」されていないことを確認できます.

于 2012-07-13T07:36:57.923 に答える