目錄
瀏覽器插件是應用範圍比較廣的技術，因爲一旦涉及到b/s模式開發，總會出現web端解決不了的情況，比如操縱硬件或本地文件等。即使html5的出現增強了web端的功能，但是就目前技術和發展趨勢來看，瀏覽器插件技術無法被替代。然而在瀏覽器插件技術上，幾大瀏覽器廠商一直“各自爲政”，特別是谷歌，更是傲嬌，給國內的開發者帶來很多麻煩。
主要的瀏覽器插件技術
目前主要的瀏覽器插件技術有以下幾種：
- ActiveX 控件
ActiveX控件是 ie 瀏覽器的專屬技術，也是個比較古老的技術，國內各大銀行的網銀插件基本都是用ActiveX開發的，所以在使用網銀轉賬的時候，很多網站都僅支持ie。但是近些年來隨着手機支付技術的普遍（支付寶，手機銀行，微信等），在網銀支付這一塊ActiveX技術也在逐漸沒落。
- NPAPI 插件
NPAPI 插件同樣是個逐漸沒落的技術。瀏覽器基本是三巨頭的天下（ie，谷歌和火狐），其實我覺得也就算兩巨頭，因爲火狐雖然有自己的內核，但是在技術發展上有點唯谷歌馬首是瞻的感覺，谷歌支持啥它就跟着來，谷歌要拋棄啥它也跟着來。國內比較主流的國產瀏覽器也基本同時使用了ie和谷歌的內核，比如qq、360這樣的瀏覽器就同時支持雙方的插件技術。之所以說NPAPI逐漸沒落是因爲谷歌瀏覽器自從v45版本後就不支持NPAPI了，火狐也宣佈會拋棄NPAPI技術，現在要想使用NPAPI就必須降低瀏覽器版本。
爲啥拋棄NPAPI呢，按谷歌官方的說法是NPAPI不安全，因爲它又能操作本地文件又能控制硬件容易被不法分子使用。這一點我必須狠狠吐槽一下，怕摔倒就不走路了嗎，我們爲啥要用瀏覽器插件啊，大部分情況下不就是爲了操作本地文件或硬件嗎。比如某些情況下我需要插上ukey來驗證身份，你谷歌說哎呀不安全，你插的ukey是微軟系統加載的，我們的瀏覽器沒法直接控制，你還是別用了吧~~~說的好聽點是谷歌技術思路追求完美，說的難聽的就是仗着自己牛叉就肆意妄爲，完全不在乎開發者的想法，這一點蘋果公司和谷歌很像，希望他們早點把自己作垮臺。
- PPAPI 插件
PPAPI插件是谷歌用來替換NPAPI的，它使用了沙箱機制，所有操作全在沙箱內部完成。按谷歌的說法這是保證安全性的最佳方案。這種模式無法操作谷歌瀏覽器進程外的任何東西，所以如果需要開發能夠控制外部設備的瀏覽器插件，PPAPI是不行的。在國內，PPAPI的意義不大，因爲國內的商業項目使用插件的目的很多時候就是爲了操縱本地設備。
- 谷歌本地消息機制（Native messaging）
這種技術是谷歌特有的一種，本質上不是插件而是擴展（關於谷歌插件和擴展的區別可以參考http://www.cnplugins.com/tool/the-diff-between-extensions-plugin.html），它的原理是在谷歌擴展中啓動一個單獨的進程，通過擴展和這個進程進行通信，業務操作都在這個外部進程中。因爲是外部進程和谷歌沙箱沒有依屬關係，在這個進程中幹什麼都可以，包括操作本地文件和外部設備。
關於Native messaging 相關技術的具體介紹可以參考https://blog.csdn.net/lee353086/article/details/49362811。這種技術雖然能夠滿足插件開發的各種需求，但是有一個非常棘手的麻煩——谷歌太作了！自從v67版本後，谷歌瀏覽器不支持離線安裝擴展，開發者開發完插件必須上傳到谷歌商店上——只能在線安裝。由於衆所周知的原因，在國內基本沒法使用谷歌商店，當然使用開發者模式還是可以離線安裝的，但是商業化的時候總不能要求客戶用開發者模式來安裝產品吧。
這種現象，其實是有解決方法的，但是很不正規，說不定哪一天就不能用了，原理上就是使用hook或者破解技術強行修改谷歌瀏覽器的chrome.dll來繞過限制，這就屬於黑客技術了，實際操作會非常麻煩。雖然現在可行，但是長期來看這種技術不可取。
Native messaging本地消息通信的demo和 破解安裝的工具可以從這下載https://download.csdn.net/download/u010810750/10927754
其它類瀏覽器插件技術
上述幾種瀏覽器插件技術基本上就是各瀏覽器廠商官方提供的“標準”技術了。綜合來看如果要實現比較通用的跨瀏覽器插件解決方案只用以上方案是不太可行的，這纔有了 “類瀏覽器插件技術”。
“類瀏覽器插件技術”這個名字是我隨便起的，因爲它根本就不算插件。解決思路原理上很簡單，細節上比較複雜。主要原理就是創建一個本地進程來容納業務功能，使用 js 腳本支持的通信協議來和這個本地進程通信來進行業務操作。這種方式和谷歌的Native messaging非常像，只是Native messaging是谷歌瀏覽器特有的，而且有着離線安裝方面的缺陷，我們要實現的方案是通用的，理論上支持所有的瀏覽器，因爲它只和js的特性有關。
比較靠譜的技術有兩種：
http通信
這種方式就是在外部做一個http服務器（具體技術方案可參考https://blog.csdn.net/u010810750/article/details/81778731），js通過post或者get來和本地http服務進行通信。
這種方案首先需要解決一個跨域的問題，因爲js端和本地http服務肯定不是一個域，關於跨域限制這裏就不多說了，大家可以自行百度，這裏只說解決方案。http跨域解決方案可行的只有兩種：
一種是服務端core跨域，這種方式是服務端跨域，具體可參考https://blog.csdn.net/u014344668/article/details/54948546。解決方式其實就是在服務端返回的時候加上Access-Control-Allow-Origin就行了，例如：
mg_send_header(conn, "Access-Control-Allow-Origin","*");//允許所有外部跨域
mg_send_header(conn, "Access-Control-Allow-Methods","*");
mg_send_header(conn, "Content-Type","application/json");
mg_send_header(conn, "charset","UTF-8");
mg_send_header(conn, "Server","wz simple httpd 1.0");
mg_send_header(conn, "Connection","close");
Access-Control-Allow-Origin爲*的時候指允許所有外部域和本域之間的跨域，如果是其它具體域名，比如“http://www.baidu.com”，就是指只允許百度和本域之間的跨域。
另一中跨域方式是jsonp，關於jsonp跨域的原理不在冗述，感興趣的可以自行百度，具體方法可以參考https://www.jb51.net/article/112904.htm。jsonp跨域的缺陷在於js端只能使用get方式，如果通信數據比較大的時候需要特殊處理。
websocket通信
websocket沒有跨域限制，而且是長連接，傳遞大數據比較方便。缺陷是低版本的瀏覽器，比如ie8就不支持websocket，需要js端用http協議來模擬websocket。
還有一個問題，是websocket和http通信都存在的，就是混合域問題。
混和域指的是瀏覽器在https域下的時候原則上是不允許和http域通信的。意思就是當web端使用https的時候，如果不修改瀏覽器配置，本地服務要麼是https服務器，要麼是websockets服務器。在實際項目中做一個https或者websockets服務器成本是比較昂貴的，因爲要買證書。如果是內網環境就更麻煩了，瀏覽器根本沒有辦法驗證證書的合法性，只能是修改瀏覽器安全配置比如 添加信任站點等。但是如果到了非要修改瀏覽器配置的地步，就根本沒有必要搭建https或者websockets類型的本地服務了，因爲混合域問題也是可以通過修改瀏覽器配置來解決的，至少在目前所有的瀏覽器都是可以通過修改配置來繞過混合域問題的。
而且本地的https或者websockets服務在安全性上沒有任何意義，因爲證書在本地，任何人都可以繞過TLS的防禦。所以關於混合域問題，目前沒有完美的解決方案。
不管是websocket還是http本地服務，都額外需要開端口，本地服務肯定需要一個端口才能起來。在某些商業項目上可能會有安全性的限制，這也是一個缺陷。
Firebreath相關介紹
firebreath是前些年在谷歌沒有廢除NPAPI技術的時候一個比較流行的插件，它融合了ie的activex，谷歌的npapi，提出了統一接口而且支持linux系統，是前些年最完美的插件解決方案，具體可以參考https://blog.csdn.net/luoweifu/article/details/44603645。
目前還是可以使用的只是不支持高版本的谷歌，目前比較成熟的版本是1.7版本。如果想使用NPAPI技術，特別有linux平臺開發需求的時候，推薦直接使用firebreath1.7。
目前還有個未完成的firebreath2.0版本，目的是爲了解決NPAPI被廢棄的問題，開發團隊的想法也是通過支持谷歌本地消息機制和websocket或者http來實現通用版本。但是這個版本進度很慢，我感覺會無疾而終。
瀏覽器控件發展趨勢
目前的瀏覽器市場，谷歌是最有話語權的，但是它完全不考慮開發者的實際需求。ie插件技術支持比較完善，但是微軟在瀏覽器這一塊也是日薄西山，國內的商業瀏覽器都是吃這兩個巨頭剩下的飯，沒什麼自主創新能力。再加上國內政策上的限制，國內開發者在瀏覽器插件開發上非常被動，目前基本屬於各自瞎搞的狀態。
瀏覽器控件的使用也逐漸偏向特化，比如之前大衆都使用的網銀ukey，現在也基本被手機代替了，商業化的項目現在是還沒統一規範。瀏覽器插件的應用我感覺會逐步偏向特殊行業，比如國企和事業單位的社會服務和內部辦公使用，這一塊國家已經明確開始國產化的進程，如果進展的比較順利的話應該會由政府牽頭來形成統一的瀏覽器插件標準甚至是完全自主的國產瀏覽器。這一天能不能到來不好說，即使能到來也不是短期能有的結果，相信國內苦逼的開發者在很長時間內還會“湊合的過日子”。不過長期看來，去谷歌化會是最終的結果，因爲谷歌的不走尋常路那一套在國外還有的混，但是在中國內地，和國情衝突太大，我相信谷歌的產品和技術最終會被淘汰，同樣命運的還有蘋果公司，畢竟——這是在中國....................................