Mozilla Hacks

用户代理检测、历史和清单

Avatar photo 作者：Robert Nyman [名誉编辑]

发布日期：2013 年 9 月 12 日 分类：Firefox 和 移动

历史

User-Agent: <something> 是 HTTP 客户端（浏览器、机器人、日历应用程序等）发送到服务器的每个 HTTP 请求的字符串。1991 年定义的 HTTP 协议 中没有此字段，但1992 年定义的下一个版本 在 HTTP 请求头中添加了User-Agent。它的语法定义为“软件产品名称，可选斜杠和版本标识符”。这段文字已经邀请人们将其用于分析和识别具有实现问题的产品。

如果存在，这行代码将给出原始客户端使用的软件程序。这是为了统计目的以及跟踪协议违规行为。它应该被包含在内。

快进到 2013 年 8 月，HTTP/1.1 规范正在修订，并且也定义了User-Agent。

用户代理不应生成包含
不必要的细粒度细节的 User-Agent 字段，并且应限制添加
第三方子产品。过长和详细的 User-Agent
字段值会增加请求延迟，并增加用户被
识别违背其意愿的风险（“指纹识别”）。

同样，鼓励实现不要使用其他实现的产品
标记来声明与它们的兼容性
，因为这会规避该字段的目的。如果用户
代理伪装成不同的用户代理，接收方可以假设
用户有意希望看到为
该标识的用户代理量身定制的响应，即使它们可能不适合
实际使用的用户代理。

基本上，HTTP 规范从一开始就劝阻检测User-Agent 字符串来定制用户体验。目前，用户代理字符串已经变得过长。它们以各种可能的方式被滥用。它们包含详细的信息。它们对自己的真实身份撒谎，并且用于宣传和广告它们运行的设备。

用户代理检测

用户代理检测（或嗅探）是用于解析User-Agent 字符串并推断有关设备及其浏览器的物理和应用程序属性的机制。但让我们把记录摆正。用户代理嗅探是一种未来失败策略。从设计上来说，你只会检测到已知的东西，而不会检测到将来的东西。小型设备（智能手机、功能手机、平板电脑、手表、Arduino 等）的空间是一个发展非常快的空间。物理特性方面的多样性只会增加。更新用于正确识别的数据库和算法是一项非常高维护的任务，它注定会在将来的某个时刻失败。网站会被放弃，库得不到维护，网站会崩溃，仅仅因为它们没有为未来的设备做好计划。所有这些都会造成资源和品牌成本。

正在开发新的解决方案来帮助人们调整用户体验，根据产品的功能，而不是它的名称。响应式设计有助于创建适应不同屏幕尺寸的网站。每次检测到产品或功能时，都要彻底了解为什么要尝试检测此功能。你可能会陷入与用户代理检测算法中存在的陷阱相同的陷阱。

我们每天都要处理滥用用户代理检测来屏蔽 Firefox OS 和/或 Android 上的 Firefox 的情况。不仅是 Mozilla 产品，每个产品和品牌都必须在某个时刻处理被排除在外的事实，因为它们没有通过错误编码的算法所需的正确标记。用户代理检测会导致这种情况，即即使新玩家拥有正确的技术集，也很难进入市场。请记住，创建一个对多种情况具有弹性的系统，具有巨大的优势。

有些公司会使用User-Agent 字符串作为标识符，来绕过付费墙或在营销活动期间为一组用户提供特定内容。乍一看，这似乎是一个简单的解决方案，但它会创建一个易于通过欺骗用户代理来绕过的环境。

Firefox 和移动

Firefox OS 和 Android 上的 Firefox 具有非常简单且有文档记录的User-Agent 字符串。

Firefox OS

Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

Android 上的 Firefox

Mozilla/5.0 (Android; Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

用户代理检测的最常见情况是了解设备是否为移动设备，以便将浏览器重定向到专门为移动内容量身定制的网站。我们建议你将检测限制为尽可能简单的字符串，通过匹配小写字母mobi 子字符串。

/mobi/i

如果你是使用 JavaScript 在客户端进行检测，那么众多可能性之一就是执行

// Put the User Agent string in lowercase
var ua = navigator.userAgent.toLowerCase();
// Better to test on mobi than mobile (Firefox, Opera, IE)

if (/mobi/i.test(ua)) {

    // do something here

} else {

    // if not identified, still do something useful

}

你可能希望在if 语句中添加多个标记。

/mobi|android|touch|mini/i.test(ua)

请记住，无论你在那里放了多少标记，你都会在将来的某个时刻失败。有些设备没有 JavaScript，没有正确的标记。标记的模式或长度与你最初计划的不一致。道路上的石头很多，选择简单的道路。

总结：UA 检测清单禅宗

  1. 不要检测用户代理字符串
  2. 为你的新移动网站使用响应式设计（媒体查询）
  3. 如果你正在使用特定功能，请使用功能检测来增强，而不是屏蔽
  4. 最后，如果你正在使用 UA 检测，只使用最简单和通用的字符串。
  5. 始终提供有效的回退，无论你选择了什么解决方案。

实践。学习。想象。修改。然后重新开始。根据你的公司背景、业务需求、社会基础设施，道路上会有很多障碍。请将这份清单放在你身边，让更多人使用 Web。

关于 Robert Nyman [名誉编辑]

Mozilla Hacks 的技术布道者和编辑。发表关于 HTML5、JavaScript 和开放网络的演讲和博客文章。Robert 坚定地相信 HTML5 和开放网络，自 1999 年以来一直从事 Web 前端开发工作 - 在瑞典和纽约市。他还定期在http://robertnyman.com 上写博客，喜欢旅行和结识新朋友。

更多由 Robert Nyman [名誉编辑]撰写的文章…

24 条评论

  1. Ron

    不幸的是，有太多旧的用户代理违反了这些规则，我担心用户代理字符串永远是实际 HTTP 中无用的方面。

    2013 年 9 月 12 日 下午 03:25

    1. Ronan Cremin

      请记住，你的 UA 字符串每天都被 Google、Facebook、eBay、亚马逊、Netflix 等公司无数次地使用，以改善你的体验。所有这些主要品牌都根据它对用户体验进行微调，但做得足够好，以至于大多数人甚至都没有注意到。以 Google 为例，他们的主页在所有设备上看起来都一样，但实际上根据你使用的设备有很大差异。

      实际上，旧的 UA 字符串不会给好的实现造成问题——它们可以很好地处理边缘情况。

      2013 年 9 月 16 日 下午 03:48

      1. Karl Dubost

        @Ronan“所有这些主要品牌都根据它对用户体验进行微调，但做得足够好，以至于大多数人甚至都没有注意到。”

        这是真的。问题在于另一部分，即不在大多数人那里 ;) 例如，请参阅http://mzl.la/164Mj9x 这就是问题所在。这不是关于正常工作的情况，而是关于它失败的次数。每次失败都是因为一个人拥有不同的设备，具有不同的功能或“错误”的品牌。

        2013 年 9 月 16 日 上午 08:10

        1. Ronan Cremin

          糟糕的实施 != 糟糕的想法

          尽管偶尔会喝到不好的酒，但我仍然喜欢葡萄酒。

          我认为，人们从这项技术中获得的益处远远大于受到的伤害。这里存在一种“沉默的证据”现象——人们会注意到失败，但不会注意到成功。

          （顺便说一下，我并不是想劫持整个话题，但我认为听到不同的意见很有必要）

          2013 年 9 月 16 日 上午 08:35

  2. Olivier Mengué

    相关
    – « Introducing IE9’s User-Agent string » https://blogs.msdn.com/b/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx?Redirected=true
    – « History of the user-agent string » http://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string/

    2013 年 9 月 12 日 下午 04:39

  3. Ronan

    > 基本上，HTTP 规范从一开始就劝阻检测 User-Agent 字符串来定制用户体验。

    真的吗？看看规范。RFC 1945 (HTTP 1.0) 说道

    “User-Agent 请求头字段包含有关发起请求的用户代理的信息。这是为了统计目的，追踪协议违规行为，以及自动识别用户代理，以便根据特定用户代理的限制来定制响应。”

    RFC 2616（HTTP 1.1）也说了同样的话。

    另外两点

    > 网站会崩溃，仅仅因为它们没有为未来即将出现的设备做好准备

    这种情况只发生在那些没有合理默认值的糟糕实现中。

    > 响应式设计有助于创建适应不同屏幕尺寸的网站。

    没错，这非常有用，但响应式设计并不能帮助需要支持各种设备的网站，一直到低端功能手机。除非你的网站非常轻量级，否则用户代理检测仍然是向市场上所有设备发布的唯一现实途径。

    2013 年 9 月 12 日 上午 5:49

    1. Karl Dubost

      嗨，罗南，

      感谢你提出这些好问题。

      > RFC 1945（HTTP 1.0，1996 年 5 月）和 RFC 2616（HTTP 1.1，1999 年 6 月）也说了同样的话。

      同意这两个规范的观点。自从 1999 年以来，我们了解到这样做有多么痛苦。这就是为什么 HTTP/1.1 bis 即将完成（最后呼吁）并且很快就会发布，其中包括我在那篇文章中提到的内容。

      >> 网站会崩溃，仅仅因为它们没有为未来即将出现的设备做好准备
      > 这种情况只发生在那些没有合理默认值的糟糕实现中。

      不幸的是，我们必须面对现实。网络是一个遗留代码和内容机器。基本上，它与历史、时间在内容上的编织有关。东西会生锈，最终会崩溃。我们都同意合理的默认值。这是我的清单中的最后一点：“无论你选择什么解决方案，始终提供一个可用的回退”。

      >> 响应式设计有助于创建适应不同屏幕尺寸的网站。
      > 没错，这非常有用，但响应式设计并不能帮助需要支持各种设备的网站，一直到低端功能手机。除非你的网站非常轻量级，否则用户代理检测仍然是向市场上所有设备发布的唯一现实途径。

      是的。这是一个非常有效的观点，也是关于我们正在构建的网络类型的一个更普遍的问题。它深深地根植于你为你的网站创建响应式设计的方式。这应该是一篇关于人们如何使用功能检测和响应式设计的文章。简而言之，它基本上只是在“你可能会陷入与用户代理检测算法相同的陷阱”这句话中轻描淡写。有时，响应式设计和/或功能检测被用来降低具有较低功能的设备的用户体验。我通常更喜欢相反的方式。网站应该在没有 JS 或任何其他东西的情况下工作，并且仍然可以在低端设备上阅读。所以基本上，针对尽可能低的设备进行设计，并使用媒体查询为更大的尺寸和/或更多功能进行改进。低端应该成为规范（个人意见）。它没有解决 WAP 低端设备问题，这就是为什么清单被提议为禅宗练习而不是规则。对于一些低端设备，已经存在很长时间的解决方案：Opera Mini、UCWeb 浏览器、一些诺基亚浏览器等。在运行时执行内容自适应，即客户和设备对浏览体验的责任。如果你的网站设计了以最小值作为回退，这些浏览器的任务就会轻松很多。

      希望这能澄清。

      2013 年 9 月 12 日 上午 6:22

  4. Ronan

    感谢你的回复，卡尔。

    我认为我们主要在重要的事情上达成一致——网站应该默认提供低端体验，并使用任何他们想要的技术来丰富这种体验，如果客户端支持它。

    我原则上同意渐进增强技术和功能检测应该能够产生一个从最低端功能手机到智能手机/平板电脑逐渐增强的解决方案，但现实表明，在实践中，要实现这一点非常困难，以至于主要参与者（谷歌、eBay、雅虎、Facebook 等）都选择使用用户代理检测。你可以在这里看到这些品牌向不同设备提供的体验有多么不同：http://prism.mobiforge.com。我想不出任何一个网站能够支持完整的网络客户端范围（功能手机 -> 智能手机 -> 平板电脑 -> 台式机 -> 电视），并且能够让渐进增强发挥作用。

    关于生锈和崩溃的观点，是的，用户代理检测需要更新和维护（通常外包给服务），但他们网络发布基础设施的无数其他方面也是如此。如果没有持续的维护，这些主要参与者的网络基础设施都不会持续运行太久（甚至几天？）。这不像是一堆静态的 HTML 放在服务器上的某个地方，所以说用户代理检测是这些系统未来运行中的一个比其他任何东西都重要的弱点，这并不正确。

    2013 年 9 月 12 日 上午 7:03

  5. 伊万·德贾诺维奇

    罗南，卡尔，首先感谢你们有见地的评论。我只想问一些非常实际的问题。

    首先，你在支持低端设备时，最低限度要做到什么？这真的不是一个天真的问题，因为仍然有一些遗留浏览器不支持现代网络开发中使用的许多功能。像我这样的开发者如何才能现实地确定用户可以可靠地获得的低端体验是什么？

    其次，响应式设计很好，不要误会我的意思，我非常喜欢它。我正在将它应用于我的产品中，取得了不同程度的成功。但例如，在我的 Nexus 4 上打开 NBA 的官方网站，显示的是一个专门为移动设备设计的完全不同的网站。或者 Mozilla 附加组件网站。如果你网站或 Web 应用程序不是简单的单页演示，响应式设计很难实现。正如罗南所说，网络上的大公司，比如 Mozilla，并没有在其所有产品中使用响应式设计。既然如此，我作为一个独立开发人员，在我开发的 Web 应用程序套件上，有什么机会让它们在多种设备上都能运行，同时在用户拥有的每台设备上都能保持最丰富的用户体验，而那些拥有远远优于我的开发资源的公司却选择不使用响应式设计呢？

    为了尝试以积极的姿态结束我的评论。我会继续使用响应式设计，因为我相信这是正确的方式，我不害怕大型公司放弃使用这种想法，因为它适合他们的某些产品。我不轻易放弃：）。

    感谢你发表这篇文章。

    2013 年 9 月 13 日 上午 2:15

    1. 威尔·米切尔

      嗨，伊万，

      我也是一个独立开发人员，正在制作自己的页面。我对你的第一个问题也有同样的疑问，但对第二个问题有不同的看法。对我来说，因为我肯定没有时间或资源去追踪许多设备进行测试，所以响应式设计是唯一的选择。更大的公司可能拥有开发人员来检测多种设备并对它们进行单独处理，但我肯定没有。所以我在一开始就付出了额外的努力，并相信我可以在我的笔记本电脑、平板电脑和手机上测试响应式设计，而差距也可以接受。此外，与用户代理字符串检测相比，最终的维护节省是巨大的。

      反正，只是一些我的想法。卡尔，很棒的文章。谢谢。

      2013 年 9 月 13 日 上午 7:35

      1. Karl Dubost

        @威尔，

        是的，对许多设备进行测试、维护算法和逻辑非常占用资源……而且它会在很大程度上破坏东西。:) 而且这不是一个假想的议题。享受 http://mzl.la/1daYnoR ;)

        非常感谢你的评论。

        2013 年 9 月 13 日 上午 8:48

    2. Karl Dubost

      @伊万，

      你能定义一下什么是低端设备吗？这不是一个反问句。我认为大多数人根据自己的环境背景对什么是正常的基础有不同的假设。非洲农村地区的低端设备可能与硅谷 101 公路上的所谓低端设备不一样。这会产生许多次要问题。

      所以，如果我们谈论的是功能集不太先进的浏览器，那么我们这里有技巧。正如我之前所说，为不太先进的设备设计，并使用功能检测而不是用户代理进行改进。这不会很完美，但更多的是关于拥有一个能够升级到更高级环境的实践，而不是试图降低体验。

      呵呵，关于 NBA 的消息。我们正在与该网站的代表进行沟通。他们目前正在进行 UA 嗅探，这对 Firefox OS 来说造成了问题，因为它不在检测到的用户代理列表中。这是 UA 嗅探不起作用的完美例子。
      它在这里 https://bugzilla.mozilla.org/show_bug.cgi?id=843154

      我们很幸运，因为在 NBA 的例子中，我们团队中有非常好的响应性人员帮助我们修复了问题，并进行了适当的嗅探。据我了解，他们至少有 3 个网站：台式机、移动 WAP 和移动触控。

      现在，如果你仔细观察这 3 个网站，你会发现它们提供的不是相同的内容和信息（不是指布局）。这是一个我在这篇文章中没有涉及的话题。通常，基于用户代理检测的重定向并不是为了用针对移动设备的标记和布局显示相同的内容。这是一个不同的网站。事实上，我经常在我的 *笔记本电脑* 上使用某些网站的移动域名，因为我想要这种类型的内容。这是一个不同的应用程序。然后，当网站通过自动重定向来禁止我根据我的环境访问其中一个网站时，就会变得非常烦人。这不再是一个技术问题。这是一个 UX 和商业决策。幸运的是，一些网站会允许你从一个网站转到另一个网站。

      因此，对于响应式设计，我们应该真正将网站类型与布局的概念区分开来。人们经常将两者混为一谈。

      我没有觉得你的评论是负面的。你提出了非常好的观点。我们所做的一切都是生态系统的一部分，我们的技术与技术同时发展。我们将来会有更好的解决方案。这种情况会改变。我在过去 20 年做网络的经历中已经看到了这一点；)

      2013 年 9 月 13 日 上午 8:43

    3. Karl Dubost

      @伊万，

      当响应式设计失控时，以及为什么要以低功能为目标进行设计的另一篇好文章。
      http://stephanierieger.com/a-plea-for-progressive-enhancement/

      2013 年 9 月 13 日 下午 12:04

    4. 布里奇特

      > 像我这样的开发者如何才能现实地确定用户可以可靠地获得的低端体验是什么？

      从坚固、格式良好的 HTML 开始。网络就是从这部分开始的……而且即使它不太时尚和性感，也能很好地运行。只有当我们（过分地）引入复杂的 CSS 和 JS 时，事情才会开始“崩溃”。

      这就是为什么以智能方式利用容错性非常棒。坚持渐进增强理念，为能够利用更多功能的浏览器添加更多功能，也可以成为保持理智的救星：）。

      2013 年 9 月 15 日 下午 12:24

  6. 拉尔夫麦克

    如果我理解错误，请纠正我，但这是否意味着根据特定用户代理字符串定制响应是预期的用途？

    “如果用户代理伪装成不同的用户代理，接收方可以假设用户有意希望看到针对该识别用户代理定制的响应，即使这些响应可能不适合实际使用的用户代理。”

    2013 年 9 月 13 日 下午 07:59

    1. Karl Dubost

      您好，Ralf，

      此规范承认了日常业务现实的另一个方面。在不同的情况下，用户会伪造客户端的用户代理字符串。下面列举了一些情况。

      * 网页兼容性
      * 机器人
      * 网页测试
      * 绕过防火墙

      所有这些用例都表达了*用户意图*，而不是服务器意图。用户代理检测和服务器的定制响应所发生的情况是，它们经常会对用户做出假设。:) 很多时候这样做都可以，而且它确实有助于创建针对特定用户的服务。问题不在于 UA 检测成功时（我们不会讨论它 ;) ），而是在每次检测失败时。这种情况经常发生。

      关于用户代理伪装不是用户选择的，Opera 有 browserJS，Firefox 有 UA 覆盖，随之而来的是一系列后果。基本上，这是因为服务器对 UA 字符串做了很多假设，客户端不得不开始撒谎，告诉服务器它们到底是什么。完全伪装用户代理，或者部分伪装，例如

      Mozilla/5.0 (iPad; CPU OS 6_0_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A550 Safari/8536.25

      * Mozilla/5.0 – 不，不是这样 :)
      * KHTML – 不，不是这样，虽然它是你的爸爸 ;)
      * like Gecko – 不，真的不是这样。别骗我了。

      你看到我们掉进了兔子洞。我现在在我的驱动器上有一个文件，里面有… 386 844 个唯一用户代理字符串。

      2013 年 9 月 13 日 下午 11:58

  7. 伊万·德贾诺维奇

    Karl，感谢你的回复。对不起，如果我重新提起了旧话题，但我认为这个话题非常重要，而且我对这个话题的了解还不够。

    请将我下面的评论仅仅理解为低端设备讨论的一个例子，而不是我实际会做或建议的事情。

    当我 1997 年开始上大学的时候，没错，我已经那么老了：)，我们有一个学生可以使用的小型计算机实验室。由于计算机数量有限，一年级学生只能使用一些 UNIX 终端。我们必须使用类似 UNIX less 的程序来浏览网页。它只能在终端中显示 HTML，并且有一些基本的键盘命令用于导航。

    如果我们以此作为支持的起点，并使用功能检测来构建它，我们就能获得良好的结果，并支持各种设备。但是这种方法是否实用？我们 realistically 能找到多少用户会在如此过时的设备上使用我们的系统？

    也许更现实的方法是将我们的起点稍微提高一点。这样做不会失去太多用户（如果有的话），但却能节省开发人员很多可能不必要的工作。

    再次抱歉，如果我的语气有些消极，或者很无聊，但我认为这个话题非常重要。在我公司做了多年的桌面网页开发后，我的请求总是让它在 IE7 及以上版本的浏览器中运行，屏幕尺寸为 1024X768 及以上，我现在正在尝试开发一些可能会在 Firefox OS 上运行的开源网页应用程序。我在业余时间做完全不同的事情，努力学习如何让我的应用程序在各种设备上尽可能好地运行，其中大多数比我的六核 8GB 桌面或 Nexus 4 手机要弱得多，同时尽量减少工作量，以便我能在一个合理的时间内完成我的应用程序。

    感谢你的帮助，也感谢你提供的文章链接，我读得很愉快。

    2013 年 9 月 16 日 上午 02:53

    1. Karl Dubost

      @Ivan

      呵呵，1997 年，我已经在一家网络公司工作了两年了。所以，你还没有那么老 ;)

      非常简短的回答。为网页设计，而不是为软件或设备设计。:) 这似乎是一个简单的答案，但事实并非如此。总会有边缘情况，总会有妥协。我们每天都会遇到灾难性的 UA 检测，但这对深入技术的用户来说往往是不可见的，因为他们倾向于使用最新最炫的玩具和软件。

      正如我之前所说，网页是一台传统机器。过去，我们通过针对特定的功能来创建网站，例如屏幕尺寸或特定的 JS。如果网站现在在更新的设备上由于脚本和/或屏幕尺寸而无法运行，这恰恰说明了我们以前做错了什么。现在的趋势是为 WebKit 设计。十年后，谁知道我们又会因为这个而陷入什么样的混乱中。:)

      2013 年 9 月 16 日 上午 03:59

  8. Remi Grumeau

    在 Mozilla 网站上看到这个真是太有趣了，因为你们在十年前还在竭力反对 UA 探测，而那时的目标是探测出 IE6。;)

    为什么还要为 iPad 提供 CSS2、png 或 nojs 回退？！这会造成额外的带宽消耗，而且像 Modernizer 这样的功能检测工具对知名设备来说毫无意义。为什么还要在每次页面加载时询问 iPad 或 Nexus4 是否支持 svg、CSS 渐变或它可以播放哪些视频编解码器？！你难道每次见到你的朋友都会问他们叫什么名字，做什么工作吗？！

    很抱歉，但只有基于 UA 探测的服务器端分析机制才是今天进行严肃的响应式网页优化的最佳选择。我同意这是一个漫长而复杂的过程，需要不断更新，至少每月一次，但为数千台设备编辑内容绝非易事：接受它！

    2013 年 9 月 17 日 下午 14:08

    1. Karl Dubost

      Bonjour Remi，

      首先，你犯了一个小小的错误。我写了这篇文章，我从去年 7 月开始就是 Mozilla 的员工，但这并不意味着这篇文章代表 Mozilla，它只是社区中众多声音之一。在此之前，我在 Opera 工作… 之前在一家网络公司工作。总之 :)

      > 为什么还要为 iPad 提供 CSS2、png 或 nojs 回退？！

      我不确定我是否理解你说的意思，但我猜想你指的是设计不是移动优先的情况。我认为我们在网页设计、内容和用户体验方面进入了不同的哲学理念。

      文章中描述的问题不是关于为知名设备提供良好的体验，而是关于阻止未知设备。这就是正在发生的事情。

      正如你所说，这不仅漫长而复杂，而且经常失败。我鼓励你加入我们，联系那些做错了的网站。这是一个对任何想花点时间的人开放的工作。;) 这通常是你自己项目的良好训练。你可能会决定不在乎某些设备和浏览器，但反过来说，这又是另一种我并不喜欢的网页哲学。:)

      你参加巴黎网页 2013 吗？如果参加，别忘了给我发个 ping。我们可以现场继续讨论。:) 顺便提一句，hello-gurus 在 Firefox for Android 上显示很好，但在 Firefox OS 上却显示失败。;

      2013 年 9 月 17 日 下午 14:53

  9. Remi Grumeau

    > 用户代理探测是一种未来会失败的策略。
    这就是我要说的。它指的是一种移动优先策略，并辅以服务器端分析，以生成优化的 CSS 和 JS 文件。

    这是一个很好的例子：hello gurus 网站使用服务器端分析来优化其重量。它在 98% 的浏览器和设备上运行良好，但可能会在新的参与者，例如 FirefoxOS 上失败。我同意，这种机制需要不断工作和更新。如果这会伤害一些人，我很抱歉，但现在的网页和使用网页的真实用户并没有使用 FirefoxOS，他们甚至不知道它的存在。那么，我为什么要让我的开发人员去适应一个没有人使用的平台的网站呢？我不会支持（即测试）Bada 或 WebOS。

    但现实世界中，一个新的平台或浏览器不会凭空出现，并在几天内获得超过 10% 的市场份额。Google Chrome 投入了大量的资金用于营销，但它花了四年时间才达到 30%！Android 2.3 已经超过 3 年了，现在仍然被大多数人使用。

    正如之前所说，不要因为有些人滥用它（是的，Google 实验，我在看着你！！）就贬低这项技术。UA 探测并非未来会失败的策略，它不幸地成为了一种必要之恶。

    2013 年 9 月 18 日 上午 00:20

    1. Karl Dubost

      > 但现实世界中，一个新的平台或浏览器不会凭空出现，并在几天内获得超过 10% 的市场份额。Google Chrome 投入了大量的资金用于营销，但它花了四年时间才达到 30%！

      我之前评论中提到的。网页开发的哲学。:) 我认为我们无法解决这个问题。但感谢你提出了不同的观点。

      2013 年 9 月 18 日 上午 03:23

  10. Remi Grumeau

    （为了缓解你的压力，我修复了 hello gurus 网站的检测，现在 B2G 也被检测为移动设备（而不是 Firefox 桌面），所以你会获得移动端的 UX

    2013 年 9 月 18 日 上午 01:41

    1. Karl Dubost

      谢谢！

      2013 年 9 月 18 日 上午 06:10

本文评论已关闭。