瀏覽器提供商雖然在實現公共接口方面投入了很多精力，但結果仍然是每一種瀏覽器都有各自的長處，也都有各自的缺點。即使是那些跨平臺的瀏覽器，雖然從技術上看版本相同，也照樣存在不一致性問題。面對普遍存在的不一致性問題，開發人員要么采取遷就各方的“最小公分母”策略，要么(也是更常見的)就得利用各種客戶端檢測方法，來突破或者規避種種局限性。

迄今為止，客戶端檢測仍然是Web開發領域中一個飽受爭議的話題。一談到這個話題，人們總會不約而同地提到瀏覽器應該支持一組最常用的公共功能。在理想狀態下，確實應該如此。但是，在現實當中，瀏覽器之間的差異以及不同瀏覽器的“怪癖”( quirk)，多得簡直不勝枚舉。因此，南昌網站建設公司開發工程師認為,客戶端檢測除了是一種補救措施之外，更是一種行之有效的開發策略。

檢測Web客戶端的手段很多，而且各有利弊。但最重要的還是要知道，不到萬不得已，就不要使用客戶端檢測。只要能找到更通用的方法，就應該優先采用更通用的方法。一言以蔽之，先設計最通用的方案，然后再使用特定于瀏覽器的技術增強該方案。

客戶端能力檢測

最常用也最為人們廣泛接受的客戶端檢測形式是能力檢測(又稱特性檢測)。能力檢測的目標不是識別特定的瀏覽器，而是識別瀏覽器的能力。采用這種方式不必顧及特定的瀏覽器如何如何，只要確定瀏覽器支持特定的能力，就可以給出解決方案。能力檢測的基本模式如下：

if (obj ect .propertyInQuestion)(

//使用o]oj ect.propertyInQuestion

)

舉例來說，lE 5.0之前的版本不支持document.getElementsByld()這個DOM方法。盡管可以使用非標準的doclunent.all屬性實現相同的目的，但IE的早期版本中確實不存在document.getElementsByld()。于是，也就有了類似下面的能力檢測代碼：

function getElement( id)t

if (document.getElementByld)(

return document.getElementByld( id);

} else if( document.all){

return document.all[id];

} else{

throw new Error( "No way to retrieve element!”);

}

}

這里的getElement()函數的用途是返回具有給定ID的元素。南昌網站設計公司技術員告訴大家,因為document.getElementByld()是實現這一目的的標準方式，所以一開始就測試了這個方法。如果該函數存在(不是未定義)，則使用該函數。否則，就要繼續檢測document.all是否存在，如果是，則使用它。如果上述兩個特性都 不存在(很有可能)，則創建并拋出錯誤，表示這個函數無法使用。

要理解能力檢測，首先必須理解兩個重要的概念。如前所述，第一個概念就是先檢測達成目的的最常用的特性。對前面的例子來說，就是要先檢測document.getElementByld()，后檢測document.all。先檢測最常用的特性可以保證代碼最優化，因為在多數情況下都可以避免測試多個條件。

第二個重要的概念就是必須測試實際要用到的特性。一個特性存在，不一定意味著另一個特性也存在。來看一個例子：

function getWindowWidth(){

if(document.all){//假設是IE

return document.do cumentElement.clientWidth：//錯誤的用法!!!

} else{

return window.innerWidth;

}

}

這是一個錯誤使用能力檢測的例子。getWindowWidth()函數首先檢查document.all是否存在，如果是則返回document.documentElement.clientWidth，第8章曾經討論過，IE確實不支持window.innerWidth屬性。但問題是document.all存在也不一定表示瀏覽器就是IE。實際上，也可能是Opera; Opera支持document.all，也支持window.innerWidth。

檢測某個或某幾個特性并不能夠確定瀏覽器。下面給出的這段代碼(或與之差不多的代碼)可以在許多網站中看到，這種“瀏覽器檢測”代碼就是錯誤地依賴能力檢測的典型示例：

//錯誤!還不夠具體

var isFirefox=!!(navigator.vendor&&navigator.vendorSub);

//錯誤!假設過頭了

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

這兩行代碼代表了對能力檢測的典型誤用。以前，確實可以通過檢測navigator.vendor和navigator.vendorSub來確定Firefox瀏覽器。但是，Safari也依葫蘆畫瓢地實現了相同的屬性。于是，這段代碼就會導致人們作出錯誤的判斷。為檢測IE，代碼測試了document.all和document.uniqueID。這就相當于假設IE將來的版本中仍然會繼續存在這兩個屬性，同時還假設其他瀏覽器都不會實現這兩個屬性。最后，這兩個檢測都使用了雙邏輯非操作符來得到布爾值(比先存儲后訪問的效果更好)。

實際上，根據瀏覽器不同將能力組合起來是更可取的方式。如果你知道自己的應用程序需要使用某些特定的瀏覽器特性，那么最好是一次性檢測所有相關特性，而不要分別檢測。看下面的例子：

//確定瀏覽器是否支持Netscape風格的插件

var hasNSPlugins= !!(navigator.plugins&&navigator.plugins.length);

//確定瀏覽器是否具有DOMI級規定的能力

var hasDOMl= !!(document.getElementByld&&document.createElement&&

document.getElementsByTagName);

以上例子展示了兩個檢測：一個檢測瀏覽器是否支持Netscapte風格的插件;另一個檢測瀏覽器是否具備DOMI級所規定的能力。得到的布爾值可以在以后繼續使用，從而節省重新檢測能力的時間。

南昌網絡公司工程師提醒廣大開發人員,在實際開發中,應該將能力檢測作為確定下一步解決方案的依據,而不是用它來判斷用戶使用的是什么瀏覽器.

本文僅限內部技術人員學習交流,不得作于其他商業用途.文章出自:南昌網站建設公司-百恒網絡 http://m.51yjwy.com 如轉載請注明出處!