前段時間，公司裏開發一個項目，其中一個需求是要能上傳超大文件（4G），以後可能會更大。研究了下asp.net的FileUpload控件，最大可以上傳2G，超過2G就不支持了（web.config文件根本就不允許超過2G的設置）。
綜合資料，想到了一種讓FileUpload控件上傳超過2G的方法。就是在Global.asax文件裏，在Application_Start（）函數中，截獲Http頭，在Application處理http之前，將上傳文件內容保存到文件中。結果試驗下來，
好處：
1. 可以上傳任意大小文件。
壞處：
1. 不能在讀取上傳內容之前獲得文件大小(表示Content-Length的變量是一個32位的整數, 最多能表示2G).
2. 不能用FileUpload控件的saveas這些功能.
3. 保存文件的代碼和FileUpload控件代碼分離, 不利於日後維護.
4. 最關鍵的是, 只有IE能支持這種上傳方式, 不是所有瀏覽器都支持超大文件上傳. 比如FireFox, Google的Chrome, 當文件超過2G是,頁面上的所有button都實效了, 按下去沒任何反應.
基於以上優劣, 最終決定選擇用ActiveX, 自己做一個上傳控件.
在選擇用VC開發ActiveX之前, 曾經也想過用C#做COM, 開發ActiveX. 最終放棄, 原因是, 不是所有機器上都安裝了.Net Framework; C#編譯的文件太大, 而且這種模擬ActiveX的開發, 總會出現一些莫名的問題(可能是自己研究不夠深刻).
下面就講講如何用VC9開發ActiveX控件.
ActiveX控件, 說到底其實就是一種COM. VC9開發ActiveX可以選則MFC和ATL兩種， 放棄MFC主要是WTL能替代MFC，而且開發出來的東西要小得多。
首先要明確，ActiveX是客戶端運行的程序，所以，ActiveX是不能直接訪問C#代碼，服務器的代碼也不能直接訪問ActiveX的數據、接口。兩者之間的交互就設計到客戶端與服務端交互的問題。這種交互，用Javascript做中間橋樑，用於初始化ActiveX。數據的傳遞，ActiveX用Wininet API向服務器發送數據，服務器用Response接收數據。關於Wininet API與Asp.net的交互，請看我的另一篇blog《使用Wininet API上傳文件到Web Server》。
其次，文件的上傳是受Http協議的限制的。而不同的web服務器對Http的支持也不一樣的，比如IIS，Tomcat，他們對服務器接收Http內容大小的限制不一樣。所以要使ActiveX上傳的文件超過2G，需要對上傳文件分塊，以較小文件上傳，最終在服務器端還原。
最後要提醒的是，ActiveX是運行在客戶端的。瀏覽器在運行ActiveX之前，要將ActiveX的CAB包下載下來、註冊，之後才能運行。這就要求ActiveX關聯的dll儘量小，功能儘可能簡單（複雜往往意味着更多的關聯文件）；要將所有ActiveX關聯的文件都要打包到CAB文件中。
使用ActiveX的優劣：
優：
客戶端運行，ActiveX給開發者極大的自由度，可以實現任何需求。
劣：
ActiveX只能在Windows平臺運行，ActiveX需要數字簽名（需要額外money），ActiveX需要客戶端安裝。
總之，ActiveX不是一個很好的解決方案。雖然它能滿足目前的需求，但ActiveX的特點就註定了不具有良好的擴展性，不具有跨平臺性，還涉及到客戶端的安全性問題。對於一個Web方面的設計，要儘量不使用ActiveX技術。
綜合資料，想到了一種讓FileUpload控件上傳超過2G的方法。就是在Global.asax文件裏，在Application_Start（）函數中，截獲Http頭，在Application處理http之前，將上傳文件內容保存到文件中。結果試驗下來，
好處：
1. 可以上傳任意大小文件。
壞處：
1. 不能在讀取上傳內容之前獲得文件大小(表示Content-Length的變量是一個32位的整數, 最多能表示2G).
2. 不能用FileUpload控件的saveas這些功能.
3. 保存文件的代碼和FileUpload控件代碼分離, 不利於日後維護.
4. 最關鍵的是, 只有IE能支持這種上傳方式, 不是所有瀏覽器都支持超大文件上傳. 比如FireFox, Google的Chrome, 當文件超過2G是,頁面上的所有button都實效了, 按下去沒任何反應.
基於以上優劣, 最終決定選擇用ActiveX, 自己做一個上傳控件.
在選擇用VC開發ActiveX之前, 曾經也想過用C#做COM, 開發ActiveX. 最終放棄, 原因是, 不是所有機器上都安裝了.Net Framework; C#編譯的文件太大, 而且這種模擬ActiveX的開發, 總會出現一些莫名的問題(可能是自己研究不夠深刻).
下面就講講如何用VC9開發ActiveX控件.
ActiveX控件, 說到底其實就是一種COM. VC9開發ActiveX可以選則MFC和ATL兩種， 放棄MFC主要是WTL能替代MFC，而且開發出來的東西要小得多。
首先要明確，ActiveX是客戶端運行的程序，所以，ActiveX是不能直接訪問C#代碼，服務器的代碼也不能直接訪問ActiveX的數據、接口。兩者之間的交互就設計到客戶端與服務端交互的問題。這種交互，用Javascript做中間橋樑，用於初始化ActiveX。數據的傳遞，ActiveX用Wininet API向服務器發送數據，服務器用Response接收數據。關於Wininet API與Asp.net的交互，請看我的另一篇blog《使用Wininet API上傳文件到Web Server》。
其次，文件的上傳是受Http協議的限制的。而不同的web服務器對Http的支持也不一樣的，比如IIS，Tomcat，他們對服務器接收Http內容大小的限制不一樣。所以要使ActiveX上傳的文件超過2G，需要對上傳文件分塊，以較小文件上傳，最終在服務器端還原。
最後要提醒的是，ActiveX是運行在客戶端的。瀏覽器在運行ActiveX之前，要將ActiveX的CAB包下載下來、註冊，之後才能運行。這就要求ActiveX關聯的dll儘量小，功能儘可能簡單（複雜往往意味着更多的關聯文件）；要將所有ActiveX關聯的文件都要打包到CAB文件中。
使用ActiveX的優劣：
優：
客戶端運行，ActiveX給開發者極大的自由度，可以實現任何需求。
劣：
ActiveX只能在Windows平臺運行，ActiveX需要數字簽名（需要額外money），ActiveX需要客戶端安裝。
總之，ActiveX不是一個很好的解決方案。雖然它能滿足目前的需求，但ActiveX的特點就註定了不具有良好的擴展性，不具有跨平臺性，還涉及到客戶端的安全性問題。對於一個Web方面的設計，要儘量不使用ActiveX技術。
