浏览器user-agent详解

特性检测并非浏览器检测

一、浏览器们的家族史

较古的浏览器

1993年,NCSA 发布了首款 web 浏览器 Mosaic。它的 user-agent 字串非常简洁:

Mosaic/0.9

虽然当时由于它对操作系统和平台的依赖性,但是基本格式还是很简单明了。在文本中,斜杠前面是产品名称(可能会显示为 NCSA Mosaic 或是其他类似的字),斜杠后面是产品版本号。

Netscape Communications 开发了 web 浏览器 Mozilla(当时号称“Mosaic 杀手”)。他们首款公开发行版本: Netscape Navigator 2 的user-agent 字串具有如下格式:

Mozilla/Version [Language] (Platform; Encryption)

Netscape 按之前的做法在 user-agent 字串的前半部分使用了产品名称和产品版本,但在后面增加了下列信息:

  1. Language - 表示应用程序用的是哪个语言
  2. Platform - 表示应用程序是在什么操作系统和/或平台中运行
  3. Encryption - 表示应用程序包含了什么安全加密类型。其中的值可能是U(128位加密)、I(40位加密)、N(没加密)。

Netscape Navigator 2 的 user-agent 字串的示例:

Mozilla/2.02 [fr] (WinNT; I)

上面的字串指: Netscape Navigator 2.02 、法语 、Windows NT 、40位加密。在当时,通过 user-agent 字串中的产品名称,可以正确判断使用的是哪个 web 浏览器。

Netscape Navigator 3 、Internet Explorer 3

1996年,Netscape Navigator 3 发布,它远远超过 Mosaic 成为当时最流行的 web 浏览器。而 user-agent 字串只有些小的变化:去掉了语言部分,多了个放操作系统或CPU的可选信息。格式如下:

Mozilla/Version (Platform; Encryption [; OS-or-CPU description])

在 Windows 系统中 Netscape Navigator 3 的 user-agent 字串的示例:

Mozilla/3.0 (Win95; U)

上面的字串指:Netscape Navigator 3 、Windows 95 、128 位加密。在 Windows 系统中,字串里面不会显示 OS 或 CPU 的信息。

Netscape Navigator 3 发布不久,微软公布了它的首款 web 浏览器: IE 3 ¹,但是 Netscape 是当时首选浏览器,大多数服务器在加载页面前都会检查 user-agent 是否为该款浏览器。IE 如果不兼容Netscape user-agent 字串,使用 IE 的用户就根本打不开这些页面,于是造就了如下格式:

Mozilla/2.0 (compatible; MSIE Version; Operating System)

在 Windows 95 中 IE 3.02 的 user-agent 字串的示例:

Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)

由于当时的浏览器嗅探只查 user-agent 字串中的产品名称部分,结果 IE 摇身一变被识别成了 Mozilla,伪装成 Netscape Navigator。这个做法引发了对浏览器识别的争论。从此以后,浏览器真正的版本埋没在了字串的中间。

Netscape Communicator 4 、Internet Explorer 4至8

1997 年8月,Netscape Communicator 4 发布(发布的名称中 Navigator 换成了 Communicator),它的 user-agent 字串格式与 3 版本一致。Windows 98 中 4 版本的 user-agent 字串如下:

Mozilla/4.0 (Win98; I)

Netscape 浏览器在更新时,版本也相应增加。4.79 版本的 user-agent 字串如下:

Mozilla/4.79 (Win98; I)

微软发布 IE 4 时,user-agent 字串更新了版本,格式如下:

Mozilla/4.0 (compatible; MSIE Version; Operating System)

在 Windows 98 中 IE 4 的 user-agent 字串的示例:

Mozilla/4.0 (compatible; MSIE 4.0; Windows 98)

可以看出,Mozilla 的版本与 IE 实际的版本一致,这样就可以识别第4代浏览器了。但遗憾的是,不久 IE 4.5 马上就发布了(只在 Mac 平台),虽然 Mozilla 版本仍是 4,但是 IE 的版本改成如下:

Mozilla/4.0 (compatible; MSIE 4.5; Mac_PowerPC)

此后,IE 的版本一直到 7 都沿用了这个模式。

而 IE 8 的 user-agent 字串添加了呈现引擎(rendering engine)版本:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)

新增的呈现引擎非常重要!这样 IE8 以 MSIE 7.0 兼容模式运行时,Trident 版本保持不变,而原先 IE7 的 user-agent 字串不包括 Trident 版本。这样可以区分 IE7 与 IE8 运行的兼容模式。

注意:别指望能从 Mozilla 版本中得到什么靠谱的信息。

Gecko

Gecko 是 Firefox 的呈现引擎。Gecko 首次开发是作为 Mozilla 浏览器 Netscape 6 的一部分。Netscape 6 的 user-agent 字串的结构是面向未来的,新版本反应出从 4.x 版本的简单变得较为复杂,它的格式如下:

 Mozilla/MozillaVersion (Platform; Encryption; OS-or-CPU; Language; PrereleaseVersion)Gecko/GeckoVersion ApplicationProduct/ApplicationProductVersion

为了更好的理解上面的 Gecko user-agent 字串格式,下面来看看各种从基于 Gecko 浏览器中取得的字串。

在 Windows XP 中的 Netscape 6.21:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

在 Linux 中的 SeaMonkey 1.1a:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060823 SeaMonkey/1.1a

在 Windows XP 中的 Firefox 2.0.0.11 :

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Mac OS X 中的 Camino 1.5.1:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.6) Gecko/20070809 Camino/1.5.1

上面都是基于 Gecko 的浏览器所取得的 user-agent 字串,区别只是版本有所不同。Mozilla 版本 5.0 是自从首款基于 Gecko 发布后就一直不变,而且以后有可能也不会变²

WebKit

2003 年,Apple 宣布发布首款他们自主开发的 web 浏览器:Safari。它的呈现引擎叫 WebKit。它是 Linux 中的 web 浏览器 Konqueror 呈现引擎 KHTML 的一个分支,几年后,WebKit 的开源吸引了呈现引擎的开发人员。

这款新浏览器和呈现引擎的开发人员也遇到了曾经 IE 3.0 类似的问题:怎样才能溶入主流而不被踢出局?答案是:在 user-agent 字串中放详尽的信息,以便骗取网站的信任使它与其它流行的浏览器兼容。user-agent 字串格式如下:

Mozilla/5.0 (Platform; Encryption; OS-or-CPU; Language) AppleWebKit/AppleWebKitVersion (KHTML, like Gecko) Safari/SafariVersion

下面是示例:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1

这 又是个挺长的 user-agent 字串,其中包括的信息既有 Apple WebKit 的版本,也有 Safari 的版本。凡是基于 WebKit 的浏览器都将自己伪装成了 Mozilla 5.0,与基于 Gecko 浏览器完全一样。但 Safari 的版本是浏览器的构建版本号(build number)。Safari 1.25 在 user-agent 字串中号为 125.1(如上所示)。Safari 版本 3 的 user-agent 字串包括了实际的 Safari 版本:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/522.15.5 (KHTML, like Gecko) Version/3.0.3 Safari/522.15.5

其 中的“(KHTML, like Gecko)”在 Safari 1.0 预览版本中就有了,这字串部分是最耐人寻味又饱受诟病。Apple 的野心是为了让开发人员把 Safari 当成 Gecko,所以采取了当初微软 IE user-agent 的类似做法:Safari 是兼容 Mozilla 的,否则 Safari 用户会认为用的浏览器不受支持。

而其它基于 WebKit 的浏览器与 Safari 不同的是,没有上面说的这个情况,所以检测断定浏览器是否基于 WebKit 比看有没有明确标 Safari 更有用。

Konqueror

Konqueror 是款在 KDE Linux 桌面环境中的浏览器,基于 KHTML 开源呈现引擎。它只发布了在 Linux 的版本,但是拥有活跃的用户群。为了兼容性最大化,user-agent 字串的格式也紧跟 IE 的后尘:

Mozilla/5.0 (compatible; Konqueror/Version; OS-or-CPU)

Konqueror 3.2 为了与 WebKit user-agent 字串变化保持一致,它将 KHTML 作为它的标识:

Mozilla/5.0 (compatible; Konqueror/Version; OS-or-CPU) KHTML/KHTMLVersion (like Gecko)

如下所示:

Mozilla/5.0 (compatible; Konqueror/3.5; SunOS) KHTML/3.5.0 (like Gecko)

Konqueror 和 KHTML 的版本号比较一致,唯一的区别就是下点处不同,比如Konquerer 3.5、KHTML 3.5.1。

Chrome

Google Chrome 浏览器以 WebKit 作为呈现引擎,JavaScript 引擎却用了另一种。最初发布的版本是 0.2,它的 user-agent 字串格式是在 webKit 信息的基础上又增加了如下:

Mozilla/5.0 (Platform; Encryption; OS-or-CPU; Language) AppleWebKit/AppleWebKitVersion (KHTML, like Gecko) Chrome/ChromeVersion Safari/SafariVersion

Chrome 0.2 user-agent 信息的示例如下:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.29 Safari/525.13

虽我不敢完全保证,但很可能 WebKit 版本和 Safari 版本总会保持同步。

Opera

Opera 浏览器默认 user-agent 字串是现代浏览器中最合理的--正确的标识了它自己及其版本。 在 Opera 8.0 前,它的 user-agent 字串格式如下:

Opera/Version (OS-or-CPU; Encryption) [Language]

在 Windows XP 中 Opera 7.54 user-agent 字串示例:

Opera/7.54 (Windows NT 5.1; U) [en]

Opera 8 user-agent 字串的语言部分移到了括号内。

Opera/Version (OS-or-CPU; Encryption; Language)

在 Windows XP 中 Opera 8 user-agent 字串示例:

Opera/8.0 (Windows NT 5.1; U; en)

当 时 Opera 做为主流浏览器之一,它的 user-agent 字串是唯一使用产品名称和版本完全真实的标识了它自己。但是由于大量的浏览器嗅探代码在 Internet 上像蝗虫飞过般只吃标 Mozilla 产品名的 user-agent 字串,造成了 Opera 的 user-agent 字串发生了完全的改变。

Opera 9 user-agent 字串有两种修改的方式:一种方式是将自己标识为 Firefox 或 IE 浏览器。在这种方式下,user-agent 字串与 Firefox 或 IE 的几乎一样,只不过末尾附加了“Opera”及版本号。如下所示:

Mozilla/5.0 (Windows NT 5.1; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0 Opera 9.50
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.50

前 一字串将 Opera 9.5 标识为 Firefox 2。后一字串将 Opera 9.5 标识为 IE 6,在两个字串中都带有 Opera 版本信息。虽然这种方式是作为 Firefox 或 IE 打开的,但也能识别出 Opera。另一种方法则是浏览器 user-agent 字串标识伪装成 Firefox 或 IE,同时也找不到“Opera”字串及其版本信息。这样从字面上去区分 Opera 浏览器便成了“不可能完成的任务”。³

结论

user-agent 字串史可以说明曾对 user-agent 嗅探说不的原因:IE 想要将自己识别为 Netscape 4,Konqueror 和 WebKit 想要识别为 Firefox,Chrome 想要识别为 Safari。这样使得除 Opera 外所有浏览器的 user-agent 嗅探区别很小,想要从一堆茫茫浏览器海洋中找出有用的标识太少了。关于嗅探要记住:一款浏览器与其它浏览器是兼容的,这样造成了不能完全准确的断定是哪款 浏览器。

比如说 Chrome ,它声称任何可以在 Safari 3 访问的网站 Chrome 也都可以访问,但是对检测 Chrome 没有一点用。为了浏览器的兼容--这便是这个声明的理由。

 

 

----------------------------------------------在此分割----------------------------------------------

 

 

起初前端工程师们就极力反对浏览器检测,他们认为类似user-agent嗅探的方法是很不好的,理由是它并不是一种面向未来的代码,无法适应新版的浏览器。更好的做法是使用特性检测,就像这样:

if (navigator.userAgent.indexOf("MSIE 7") > -1){ //do something }

而更好的做法是这样:

if(document.all){ //do something }

这两种方式并不相同。前者是检测浏览器的特殊名称和版本;后者却是检测浏览器的特性。UA嗅探能够精确得到浏览器的类型和版本(至少能得知浏览器类型),而特性检测却是去确定浏览器是否拥有某个对象或者支持某个方法。注意这两者是完全不同的。

因为特性检测依赖于哪些浏览器支持,当出现新版本浏览器的时候需要繁琐的确认工作。例如DOM标准刚出现的时候,并不是所有浏览器都支持getElementById()方法,所以一开始代码可能是这样:

if(document.getElementById){ //DOM element = document.getElementById(id); } else if (document.all) { //IE element = document.all[id]; } else if (document.layers){ //Netscape < 6 element = document.layers[id]; }

这是特性检测很好的一个例子,亮点在于当其它浏览器开始支持getElementById()方法时不必修改代码。

混合方式

后来前端工程师们考虑改进的写法,代码变化成这样:

//AVOID!!! if (document.all) { //IE id = document.uniqueID; } else { id = Math.random(); }

这个代码的问题是通过检测document.all属性来确定是否是IE。当确定是IE后,假定使用私有的document.uniqueID属性也是安全的。然而,目前所作的只是确定是否支持document.all,并非是去辨识浏览器是否为IE。仅仅支持document.all的话也不意味着document.uniqueID是可用的。

后来人们开始这样写,用下面那行代替上面的:

var isIE = navigator.userAgent.indexOf("MSIE") > -1; //下面这行代替上面那行 var isIE = !!document.all;

这些变化说明大家对“不要使用UA嗅探”存在误解——不再对浏览器的详细信息进行检测,取而代之的是通过特性的支持来推断。这种基于浏览器特性检测的方式非常不好。

后来前端们发现document.all并不可靠,更好的检测IE变为:

var isIE = !!document.all && document.uniqueID;

这种实现方式陷入歧途。不仅需要费时费事地去识别浏览器所增加的特性支持,另外也不能确定其它浏览器开始支持相同的特性。

如果你认为这样的代码并未被广泛使用,那么看看来自于老版本的Mootools代码片段吧:

//from MooTools 1.1.2 if (window.ActiveXObject) window.ie = window[window.XMLHttpRequest ? 'ie7' : 'ie6'] = true; else if (document.childNodes && !document.all && !navigator.taintEnabled) window.webkit = window[window.xpath ? 'webkit420' : 'webkit419'] = true; else if (document.getBoxObjectFor != null || window.mozInnerScreenX != null) window.gecko = true;

注意它是如何使用特性检测的。我可以指出它一系列的问题,比如通过检测window.ie会将ie8误认为ie7。

余波

随着浏览器的快速发展,使用特性检测变得越来越困难和不可靠。但是Mootools 1.2.4仍然使用这一方法,例如:getBoxObjectFor()

//from MooTools 1.2.4 var Browser = $merge({ Engine: {name: 'unknown', version: 0}, Platform: {name: (window.orientation != undefined) ? 'ipod' : (navigator.platform.match(/mac|win|linux/i) || ['other'])[0].toLowerCase()}, Features: {xpath: !!(document.evaluate), air: !!(window.runtime), query: !!(document.querySelector)}, Plugins: {}, Engines: { presto: function(){ return (!window.opera) ? false : ((arguments.callee.caller) ? 960 : ((document.getElementsByClassName) ? 950 : 925)); }, trident: function(){ return (!window.ActiveXObject) ? false : ((window.XMLHttpRequest) ? ((document.querySelectorAll) ? 6 : 5) : 4); }, webkit: function(){ return (navigator.taintEnabled) ? false : ((Browser.Features.xpath) ? ((Browser.Features.query) ? 525 : 420) : 419); }, gecko: function(){ return (!document.getBoxObjectFor && window.mozInnerScreenX == null) ? false : ((document.getElementsByClassName) ? 19 : 18); } } }, Browser || {});

应该怎么做?

特性检测是个应该避免的方法,尽管直接进行特性检测是个很好的方法,并且大部分情况下能满足需求。一般只要在检测前知道这个特性是否被实现即可,而不会去考虑它们之间的关系。

我并非是说永远不使用浏览器特性检测而是基于UA嗅探,因为我相信它还是有很多用途的,然而我不相信它有很多合理的用途。如果你考虑UA嗅探的话, 请先贯彻这一思想:唯一安全的方式是针对特定浏览器的特定版本,超出范围之外都是不可靠的——例如新出的浏览器版本。其实这样做也是个明智的办法,因为相 较于向前兼容不确定的新版本而言,向后兼容老版本是最简单的做法。

----------------------------------------------在此分割----------------------------------------------

全文转自:http://www.cnblogs.com/pomp/archive/2010/09/19/1831305.html

猜你喜欢

转载自ducaijun.iteye.com/blog/1407030