客戶端檢測

在現實當中，瀏覽器之間的差別以及不一樣瀏覽器的怪癖，多得不勝枚舉。所以，客戶端檢測除了是一種補救措施以外，更是一種行之有效的開發策略

檢測 web 客戶端的手段有不少，並且各有利弊。但最重要的是要知道，不到萬不得已，就不要使用客戶端檢測！若是能找到更通用的方法，應優先採用更通用的方法。既是，先設計通用的方案，在針對差別加強該方案

能力檢測

能力檢測的目標不是識別特定瀏覽器，而是識別瀏覽器的能力。只要肯定瀏覽器的能力，就能夠給出特定解決方案

• 檢測的時候應該儘量精確，例如，你想檢測 sort，不該該只檢測是否存在 sort 屬性，而應該更深一步檢測 sort 是不是 function 類型的。並且須要注意 typeof 在各個瀏覽器之間的差別
• 能力檢測並不是瀏覽器檢測，並不能識別出特定的瀏覽器，由於其餘瀏覽器新版本可能會改變，致使你的檢測邏輯不嚴謹
• 檢測完，應該把檢測結果保存起來，這樣就不須要每次都進行

例如：早期針對 IE 的檢測：

function getElement(id) {
    if (document.getElementById) {
        return document.getElementById(id);
    } else if (document.all) {
        return document.all[id];
    } else {
        throw new Error('getElementById不可用');
    }
}

怪癖檢測

識別瀏覽器的特殊行爲，檢測該瀏覽器存在什麼缺陷

• 通常來講，怪癖都是個別瀏覽器獨有的，故歸爲 bug。
• 因爲檢測怪癖須要運行代碼，用來檢驗缺陷。故建議僅檢測有直接影響到，而且最好在一開始便執行- 檢測

例如 ： IE8 及更早版本，有個 bug，新增屬性若是與某個 Enumerable 標爲 false 的原型屬性同名，for in 循環沒法遍歷出它。

用戶代理檢測（user-agent）

用戶代理經過檢測用戶代理字符串來肯定實際使用的瀏覽器。在服務器端，這是一種經常使用且廣爲接受的作法，而在客戶端，則被當作萬不得已才用的作法，優先級在能力檢測和怪癖檢測以後。

識別呈現引擎：IE、 Gecko、Webkit、KHTML、Opera

因爲歷史緣由，有些引擎返回的 ua 中存在諸多不一致的地方。因此在檢測的時候，檢測的順序很重要
Opera --> Webkit --> KHTML --> Gecko --> IE.

識別瀏覽器

大多數狀況下，識別呈現引擎足以讓咱們纔去正確的操做。可是，只有呈現引擎還不能說明存在所需的 js 功能。例如，safari 和 chrome 的呈現引擎都是 webkit，但他們的 js 引擎卻不同。
瀏覽器：IE , Firefox，safari，konq，opera，chrome

識別平臺

經過 navigator.platform 來檢測不一樣的平臺。
navigator.platform 屬性可能的值包括：" Win32 " , " Win64 " , " MacPPC " , " MacIntel " , " X11 " , " Linux i686 ".

識別 windows 操做系統

經過檢測 userAgent 中的字符串，用正則識別不一樣的 windows 版本
win2000 以後，大部分瀏覽器表示操做系統的字符串大部分相同，只有版本號有變化。

識別移動設備

• ios 設備: 檢查是否是 Mac OS ，字符串中是否包含「Mobile」，而後再使用正則肯定是否存在 IOS 版本號。
• android： 搜索字符串「Android」，並取得緊隨其後的版本號

識別遊戲系統

Wii 或 playstation

小結

用戶代理檢測是客戶端檢測的最後一個選擇。只要可能應該優先採用能力檢測，怪癖檢測次之

用戶代理檢測通常適用於下列狀況：

• 爲了跟蹤分析等目的須要知道確切的瀏覽器
• 不能直接準確的使用能力檢測和怪癖檢測。
• 同一款瀏覽器在不一樣的平臺上具有不一樣的能力，這時候就須要肯定瀏覽器位於哪一個平臺。