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

请求参数

  • 谷歌分析、服务器日志等都会有URL的记录，可能对以后的分析有帮助。
  • 多个 URL 使缓存变得更加困难，并有可能使 Google 感到困惑

哈希

  • 分析和服务器日志不会看到/关注哈希参数

处理这个更语义化的方式可能是通过查询字符串参数，但它不是很强大。如果上述几点都不相关，我可能会坚持使用查询字符串，因为它更常见。

如果您的意思是您正在构建其他人集成的服务，并且您不希望他们必须将信息传递回他们的应用程序（通过查询字符串），那么使用哈希参数似乎是一个不错的选择。

于 2012-07-12T17:42:22.010 回答
3

W3C在这里说：

当然，不可能确保服务器不会因为执行 GET 请求而产生副作用；事实上，一些动态资源认为这是一个特性。这里的重要区别是用户没有请求副作用，因此不能对它们负责。

于 2012-07-12T17:51:01.473 回答
3

使用哈希。

为什么？

因为您开发了 3rd 方插件，并且不知道是否有任何参数不是站点开发人员的用户。当您覆盖使用的 get 参数之一时，您可以破坏本机应用程序开发人员传递给服务器的一些重要信息。此外，您不想让应用程序持有人具有重复的页面，例如：http ://somepage.com/和http://somepage.com/?app_source=user_id将是重复的，因为许多用户会引用该页面，您将创造许多。

哈希是最安全的选项，可以在每个页面上使用。

于 2012-07-13T09:09:35.360 回答
2

哈希是要走的路。

只有2个选择，一个是GET Parameter，第二个是#。

? 获取参数

get参数可以被搜索引擎和两个URL索引，http://www.yoursite.com/可以http://www.yoursite.com/?app_id=123是2个单独的页面

在我的一个网站上，我使用了这个，我收到来自谷歌的电子邮件，说明 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_source并使用 Javascript 将其传递给您的服务器。所以你可以随心所欲。如果我是你，我会粗暴地使用 HASH

于 2012-07-17T16:07:43.177 回答
1

你的两种方法都不好。最终的方法是使用 URL Segments：

如果你想通过 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 应用程序，对于支持 SPA（单页应用程序）如 Twitter 非常有用。请只使用“？” 符号。

于 2012-07-12T17:40:43.770 回答
0

简单的方法是使用带有 userID 的 GET 参数来验证它是否被某人引用。

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

然后，如果您想了解更多关于推荐的信息，您还可以检查用户实际使用哪个 url 点击了您的链接$_SERVER['HTTP_REFERER']（如果您使用 php）。这样，您可以确保您的链接不在垃圾位置或“自动访问”。

于 2012-07-13T07:36:57.923 回答