一：源起
1.何為CB/S的應用程式
C/S結構的應用程式，是客戶端/服務端形式的應用程式，這種應用程式要在客戶電腦上安裝一個程式，客戶使用這個程式與服務端通訊，完成一定的操作。
B/S結構的應用程式，是瀏覽器/服務端形式的應用程式，這種應用程式不用在客戶端部署任何東西，客戶只需要通過瀏覽器與服務端通訊，來完成一定的操作。
兩種型別的程式優缺點對比：
|
對比內容
|
C/S結構的應用程式
|
B/S結構的應用程式
|
|
部署
|
較困難
|
方便
|
|
升級
|
較困難
|
方便
|
|
對客戶端的控制許可權
|
高
|
低
|
|
資料實時性
|
高
|
較高
|
|
通訊效率
|
高
|
較高
|
|
跨平臺性
|
弱
|
強
|
由上可知，兩種形式的應用程式各有利弊。架構師在做技術選型的時候，往往會根據專案需要，對比這兩種技術形式的優缺點，做出正確的選擇。
然而，國內大多數企業應用程式，需要頻繁、及時的更新升級、需要更高的客戶端控制許可權、需要更高的資料實時性和更高的通訊效率，但卻不在意部署上的問題。
這時，架構師就考慮把C/S結構的應用程式和B/S結構的應用程式結合起來，讓客戶端巢狀一個瀏覽器以與伺服器通訊，完成一定的操作。這樣的程式就是CB/S結構的應用程式。
這樣做的好處是一般的業務邏輯只要在服務端更新升級，即可體現在客戶端。對於客戶端系統許可權、基於Socket的通訊等瀏覽器核心無法完成的操作，可以由客戶端來完成。客戶端可以直接與服務端通訊，也可以通過瀏覽器核心與服務端通訊。
下圖為CB/S結構應用程式的基本示意圖：
|
目前還有一種介於C/S和B/S結構的應用程式之間的應用程式：RIA富網際網路應用程式，這種結構的應用程式一般都是基於瀏覽器外掛來執行的，它有較高的客戶端控制許可權（比B/S程式高，但比C/S程式低），通訊方式也有較多的選擇（不只是基於HTTP協議），目前較常見的RIA技術有：Adobe的flex技術、微軟的Silverlight技術、Oracle的WebStart技術。架構師在做技術選型的時候，也可以綜合權衡採用這些技術。
|
2.為何選擇QT的WebKit與Extjs開發企業應用
ExtJs是一個用於建立Web使用者介面的JS框架，提供了豐富的介面部件及佈局方式，對於web開發者來說，實現企業應用所需的各種畫面只要掌握JS語言即可。不必再引入flash或silverlight技術，而且能很容易的建立風格統一的企業應用程式。
雖然ExtJs支援各種流行的瀏覽器，甚至包括IE6，但是它在IE系瀏覽器下執行、渲染的效率不高。在谷歌瀏覽器下表現最好，FireFox瀏覽器次之（這得益於谷歌瀏覽器的JS指令碼引擎）。
然而谷歌瀏覽器和FireFox瀏覽器的核心都是WebKit（蘋果公司開源的瀏覽器核心，負責解析HTML文字，並呈現到介面上），所以，要想讓我們的CB/S+ExtJs結構的應用程式能有更好的表現，我們必須採用WebKit核心的瀏覽器。
雖然我們能很方便的獲得WebKit的原始碼，然而編譯它卻十分耗時費力，不但要選對編譯工具，還要安裝一系列的SDK，編譯時間更是長的驚人（這幾乎是大型C++專案的通病）。編譯出來的DLL使用起來也不是很方便（要翻閱大量的WebKit的API）。
幸運的是QT介面庫為我們做了這些工作，QT庫中包含webkit的瀏覽器控制元件，並且這個C++庫是跨平臺的，也就是說基於這幾項技術開發的CB/S企業應用可以部署在Linux系統內。
除了使用QT介面庫，還可以選擇gtk+和wxWidgets兩個介面庫，而且這兩個介面庫都對WebKit做過包裝，但是從開發方式，生產效率，執行速度等多方面考慮，還是QT最為合適。
QT介面庫也分為兩個版本，一個是收費的digia提供的QT，另一個是免費的qt-project提供的QT（GPL V3 LGPL V2)，這裡我們選擇免費版的QT，本文第三節會介紹如何搭建開發環境。
|
架構師除了選擇QT的WebKit做瀏覽器核心之外，還可以選擇CEF（Chromium Embedded Framework，專案地址：https://code.google.com/p/chromiumembedded/）這個專案是對谷歌瀏覽器的重新編譯、封裝，分為兩個版本線，CEF1和CEF3，我曾對此專案做過一些研究，研究的相關資料參見：http://www.cnblogs.com/liulun/archive/2013/03/18/2874276.html；另外，還有一個node webkit的專案（地址：https://github.com/rogerwang/node-webkit）也是對谷歌瀏覽器的重新編譯和封裝，但它引入了NodeJs，使用簡單的HTML JS CSS就可以編寫出絢麗的客戶端介面。node webkit目前處於V0.7.X版本。
|
二：思路
1.目標
- 搭建一個CB/S結構的企業應用程式
- 儘量保證系統的執行效率
- 儘量保證系統升級更新的便利性
- 儘量保證系統的可擴充套件性
2.方案
ExtJs框架是一個比較龐大的框架，一般B/S結構的程式使用ExtJS框架，都是把ExtJs的框架放在服務端，這樣使用者每次請求頁面的時候，都會去訪問ExtJS框架的JS檔案，從而產生大量的磁碟IO和網路消耗，這也是ExtJS框架看起來渲染很慢的一個因素。B/S結構的應用程式無法解決這個問題，主要是因為無法控制客戶端的瀏覽器，CB/S結構的程式就能輕鬆解決這個問題。可以把ExtJs框架打包進客戶端程式中，隨客戶端程式分發給使用者，使用者請求頁面時，使用的是本地的ExtJS框架的JS檔案，業務邏輯程式則仍舊使用服務端的。這樣做減少了磁碟IO和網路消耗，保證了系統的執行效率；服務端對業務邏輯程式依舊保持著很好的控制權，保證了系統升級更新的便利性
關於系統的可擴充套件性，ExtJs就能很好的處理，在下一節中會有詳細描述。
3.難點
CB/S結構的應用程式其實就是一個高度定製的瀏覽器。為了讓這個瀏覽器完成指定的功能（比如：包含ExtJs框架的js檔案，做成cookie，發起請求等）難免會有很多客戶端和瀏覽器核心的互動。這些互動涉及到C++，Js，HTML，CSS等的互操作，是系統在技術上的難點。
三：客戶端瀏覽器實現
1.搭建開發環境
我們下載基於MinGW 4.8, OpenGL建立的QT 5.1，地址為：http://qt-project.org/downloads。不選擇基於VS編譯器的QT是因為用VS編譯器編譯出的DLL依賴VS執行時，分發程式時較困難。下載並安裝後，你會看到這並不是一個簡單的介面庫，它還包含了一個IDE，Qt Creator。
安裝完成後，就可以使用Qt Creator來建立你自己的基於Qt的桌面程式，你可以在Qt Creator的歡迎介面看到入門程式、示例程式和幫助文件。Qt的開發方式並不是本文所講述的重點，建議讀者到官網學習。
雖然我們可以成功在Qt Creator內編譯併成功執行程式，但到windows目錄下通過雙擊執行編譯出的exe程式，就不能正常執行，這是因為可執行程式所需的動態連結庫並沒有與可執行程式在同一個目錄內，至於可執行程式依賴哪些動態連結庫，我們將在本文第四節詳細描述。
2.邊框和標題欄
目前大部分windows桌面程式都使用自定義的邊框和標題欄，比如QQ，360安全衛士等，使用MFC或Windows API自定義視窗的標題欄和邊框並不是一件容易的事情，使用Qt來開發Windows桌面程式也有一樣的困難。
由於我們開發的是企業應用系統，這類系統一般情況下都出於最大化狀態，所以我們在考慮自定義標題欄和邊框的時候就可以不用考慮還原按鈕、拖拽改變視窗大小和位置的功能。但是，我們需要為標題欄增加一個下拉選單按鈕，以使使用者完成系統設定、開啟偵錯程式等相關功能。
另外，為了使標題欄和業務介面中ExtJs的風格一致，我們索性去掉了主視窗的標題欄和邊框，直接使用ExtJs來生成。
在Qt中去掉標題欄和邊框是很容易的事，建立視窗的時候設定一個WindowFlags即可，見如下程式碼：
|
w.setWindowFlags(Qt::FramelessWindowHint);
|
但設定此WindowFlags之後隨之帶來的問題是，視窗將撐滿整個螢幕，把系統的工作列也遮住了，這顯然不是我們想要的，解決此問題需要重寫Qt視窗類的changeEvent槽，見如下程式碼：
|
if(event->WindowStateChange)
{
switch(this->windowState())
{
case Qt::WindowMinimized:
this->hide();
event->ignore();
break;
case Qt::WindowMaximized:
QDesktopWidget* desktopWidget =QApplication::desktop();
QRect deskRect =desktopWidget->availableGeometry();
this->resize(deskRect.width(), deskRect.height());
break;
}
}
|
這樣建立的Qt視窗將不具有標題欄和邊框，至於如何用ExtJs來渲染標題欄，以及如何實現標題欄的最小化及關閉等功能，將在後續小節講述。
3.開啟新視窗
使用Qt的WebKit非常簡單，直接把QWebView控制元件拖放到介面中去即可，但是預設的QWebView在實現上有些缺憾，比如無法開啟新視窗，無法下載檔案，無法列印等。然而這些功能是一個瀏覽器所必備的功能，我們的CB/S企業應用系統也需要這些功能。要想讓瀏覽器支撐這些功能，只能通過重寫QWebView來完成。
要想讓自制的瀏覽器開啟新視窗，需要重寫QWebView的createWindow方法，見如下程式碼：（UtmpWebView即為QWebView的子類）
|
UtmpWebView* webView = new UtmpWebView;
QWebPage* newWeb = new QWebPage;
if(type == QWebPage::WebModalDialog)
{
webView->setWindowModality(Qt::ApplicationModal);
}
webView->setAttribute(Qt::WA_DeleteOnClose,true);
webView->setPage(newWeb);
webView->show();
return webView;
|
然而，這隻能應對a標籤的target屬性為_blank的新視窗連結，無法應對使用javascript通過window.open的方式開啟新視窗的場景。要想滿足這一點，必須在QWebView的建構函式裡，更改一下瀏覽器的配置引數，程式碼如下：
|
QWebSettings* default_settings = QWebSettings::globalSettings();
default_settings->setAttribute(QWebSettings::JavascriptEnabled,true);
default_settings->setAttribute(QWebSettings::JavascriptCanOpenWindows,true);
|
4.列印
我們經常在網頁中通過javascript使用window.print的方式來呼叫印表機列印HTML頁面，常見的瀏覽器都會支援這個功能，然而QWebView預設並不支援此功能，要想讓我們定製的瀏覽器支援此功能必須為其做一個事件連結，程式碼如下：
|
connect(this->page(), SIGNAL(printRequested(QWebFrame*)),this,SLOT(customPrintRequested(QWebFrame*)));
this->page()->setForwardUnsupportedContent(true);
|
customPrintRequested槽的實現如下：
|
QPrinter* p = new QPrinter(QPrinter::HighResolution);
QPrintDialog printDialog(p, this);
printDialog.setWindowTitle("UTMP列印");
if(printDialog.exec() != QDialog::Accepted)
{
return;
}
frame->print(p);
|
5.下載
同樣QWebView預設也不支援下載檔案。所有的瀏覽器把請求的響應分為兩類，一類是瀏覽器可以解析的（Html文字），另一類是瀏覽器無法解析的（檔案），常見的瀏覽器遇到無法解析的檔案，往往會下載到本地給使用者使用，要想讓QWebView支援下載，就必須截獲瀏覽器的unsupportedContent訊號，該訊號所對應的槽的程式碼實現如下
|
ShellExecuteA(NULL, "open", reply->url().toString().toStdString().c_str(), "", "", SW_SHOW);
|
注意，要想讓上面的程式碼正確執行，必須在標頭檔案中引入windows.h（這也體現出QT框架與NativeAPI能沒有任何限制的輕鬆互動）。上面的程式碼是呼叫了系統預設的瀏覽器來完成下載。當然讀者也可以考慮自己實現下載執行緒並提示下載進度、儲存地址等。
6.與頁面指令碼互動
我們既然選擇自己開發瀏覽器，那麼瀏覽器一定能自如的讓頁面執行一些特殊指令碼，頁面也可以通過指令碼讓瀏覽器完成一些指令碼無法完成的操作。此功能一般的瀏覽器都無法支撐，只有我們自定義的QWebView可以輕鬆實現。
我們知道javascript在頁面中執行都會用到window物件，比如，我們呼叫alert()方法時，其實是呼叫window.alert()方法，使用document物件時，其實是使用window.document物件，要想讓瀏覽器能與頁面指令碼互動，我們必須讓瀏覽器給頁面的window物件註冊一個子物件（window物件的屬性）。
遇到的第一個問題並不是如何註冊此物件，而是在何時註冊。由於在頁面載入之初，window物件就已經初始化完成了，此時為其註冊子物件已為時已晚，必須在其初始化之前為其註冊，為此QWebView專門提供了javaScriptWindowObjectCleared訊號，在重新整理網頁、開啟新網頁和載入巢狀的iframe頁面時（window物件初始化時），此訊號都會被觸發。與此訊號關聯的槽，程式碼如下：
|
this->page()->mainFrame()->addToJavaScriptWindowObject("QtWinFrame", this);
|
如你所見，我們為window物件註冊了一個名為QtWinFrame的物件。這就像瀏覽器為window物件註冊document子物件一樣，要想讓頁面指令碼能呼叫瀏覽器核心的方法，必須為讓瀏覽器核心提供相應的方法才行，由於我們在第二小節已經把視窗預設的標題欄和邊框去掉了，所以必須通過頁面javascript來關閉瀏覽器和最小化瀏覽器，假設我們在瀏覽器核心中實現的方法程式碼如下：
|
void UtmpWebView::SetFrameWindow(int flag)
{
switch(flag)
{
case 0:
this->close();
break;
case 1:
this->showMinimized();
break;
}
}
|
在瀏覽器頁面內，只要通過如下javascript程式碼，即可讓瀏覽器核心執行相應的操作：
|
QtWinFrame.SetFrameWindow(1);QtWinFrame.SetFrameWindow(0);
|
相對於“指令碼讓瀏覽器執行工作”來說，“瀏覽器讓指令碼執行工作”就簡單很多，只需要在瀏覽器中呼叫evaluateJavaScript方法即可，見如下程式碼：
|
this->page()->mainFrame()->evaluateJavaScript("testFun();");
|
注意：這有些類似於javascirpt中的eval()方法，如果前端框架中引入了ExtJs，最好不要直接使用此方法來呼叫ExtJs提供的函式，執行效率非常慢。可以先在頁面上用普通的js函式包裝一下ExtJs提供的函式，再來呼叫。
7.開啟指令碼偵錯程式
除錯javascript程式碼一直以來都是開發人員面臨的老大難的問題，自從有了FireBug和谷歌瀏覽器自帶的javascript偵錯程式之後，這個問題得到了很大程度的解決，所以有個好的javascript偵錯程式十分關鍵。QWebView也提供了相應的除錯工具（我認為就是谷歌瀏覽器的javascript偵錯程式，但未經驗證。）。使瀏覽器核心開啟偵錯程式的程式碼如下：
|
QDialog* d = new QDialog(this,(Qt::WindowMinimizeButtonHint|Qt::WindowMaximizeButtonHint|Qt::WindowCloseButtonHint));
d->setAttribute(Qt::WA_DeleteOnClose, true);
QWebInspector* wi = new QWebInspector(d);
wi->setPage(this->page());
d->setLayout(new QVBoxLayout());
d->layout()->setMargin(0);
d->layout()->addWidget(wi);
d->show();
d->resize(600,350);
|
由於我們在系統啟動的時候，使用Qt::FramelessWindowHint屬性禁用掉了視窗的標題欄和邊框，所以在開啟偵錯程式子視窗的時候，要恢復該子視窗的標題欄和邊框，為此我們多做了一些工作，讀者也可以自己實現QDialog型別的父類，以應對更多子視窗業務。
8.截獲瀏覽器請求
既然我們對瀏覽器有最大的控制權，那麼我們就希望當瀏覽器完成指定工作時通知我們，好讓我們做一些前期或後期的處理。最常見的工作莫過於瀏覽器發起請求了。我們知道瀏覽器解析一個網頁的過程中，可能會發起多次請求，比如圖片標籤的src路徑，iframe標籤的src路徑，js/css資源的路徑等等。要想知道這些請求何時發起，何時終結需要重寫QNetworkAccessManager，然後通過如下方式，讓瀏覽器載入自定義的QNetworkAccessManager
|
QNetworkAccessManager *oldManager = webview->page->networkAccessManager();
MyNetworkAccessManager *newManager = new MyNetworkAccessManager(oldManager, this);
webview->page->setNetworkAccessManager(newManager);
|
然後，我們可以在自定義的MyNetworkAccessManager類中重寫createRequest(QNetworkAccessManager::Operation operation,const QNetworkRequest &request, QIODevice *device)方法，其中request引數，包含了原始請求的URL資訊，此方法需要返回一個QNetworkReply物件，假設我們想改變原始請求的路徑，可以按如下操作方式來完成
|
return QNetworkAccessManager::createRequest(operation, myrequest, device);
|
9.本地化ExtJs庫
一般我們使用ExtJs（官方地址：http://www.sencha.com/products/extjs/），都是把它部署在服務端，瀏覽器請求頁面時，也會相應的載入ExtJs的資源以渲染介面，但由於ExtJs包含眾多js檔案和其他資源，通過網路來載入的話，一方面增加了伺服器IO消耗，另一方面增加了網路延時，很多使用者反應基於ExtJs的網路應用呈現速度慢，都是這兩個原因導致的。
現在我們開發自己的瀏覽器，就可以把Extjs庫（不包含業務JS程式碼，因為業務JS程式碼易於變化，不適合當作資源放在客戶端）當作資源放在客戶端，對於一個客戶端來說，體積越小越好，然而以ext4.2.1 gpl版為例，官方提供的壓縮包裡，有很多內容不適合打包到客戶端中。比如：教程、文件、原始碼、示例等，讀者可以自行將這些內容刪掉，然後把精簡後的ExtJs類庫放到瀏覽器應用程式編譯資料夾內（[appDirectory]\build-UTMP-Desktop_Qt_5_1_1_MinGW_32bit-Debug\debug）,這樣Extjs類庫就與我們的瀏覽器可執行程式在同一個目錄下了，如果讓瀏覽器使用Extjs類庫的資源，還應該在此目錄下建立一個靜態檔案，以引入同目錄下的靜態資源，程式碼如下：
|
<link href="ext-4.2.1.883/resources/Css/ext-all.css" rel="stylesheet" type="text/css" />
<script src="ext-4.2.1.883/ext-all-debug.js"></script>
|
|
<script src="http://localhost:8080/UTMP/app.js"></script>
|
|
UtmpWebView w;
QDir dir(QDir::currentPath());
QUrl url = url.fromLocalFile(dir.path()+"/debug/index.html");
w.load(url);
|
由此可見，儲存在客戶端的資源基本都是業務無關的、比較穩定的、不易變更的資源。儲存在服務端的內容，都是與業務有關的，比較容易變更的內容，這種機制主要意圖是保證了業務的可升級性。
四：服務端業務指令碼
1.OPOA模式
使用Extjs的企業應用系統大多都是OPOA模式（One Page One Application），OPOA模式的WEB系統只有一個頁面，在這個頁面中會引入extjs的資源並通過js來渲染一個框架頁面，然後根據使用者的操作載入更多的js程式碼，來完成不同的業務。對於我們的系統來說這個頁面就是放在客戶端本地debug目錄下的靜態頁面。這個頁面引入了一個伺服器端的js檔案（http://localhost:8080/UTMP/app.js），通過此檔案以及由此檔案載入的其他js檔案，我們渲染出了一個框架頁面，見如下程式碼：
|
Ext.application({
name:'UTMP',
appFolder:'http://10.0.7.109:8080/UTMP/app',
controllers:["sys.index"],
views:["sys.menuTree","sys.titleBar","sys.contentTabPanel"],
launch:function(){
Ext.create('Ext.Viewport',{
layout:'border',
items:[
{xtype: 'menuTree'},
{xtype: 'titleBar'},
{xtype: 'contentTabPanel'}
]
});
}
});
|
如你所見，這是一個Extjs系統的開始（Ext.application），而且我們使用了Extjs的MVC模式（關於ExtJs的MVC模式的相關資料請參閱：http://docs.sencha.com/extjs/4.2.1/#!/guide/application_architecture），系統介面中包含三個檢視：menuTree、titleBar和contentTabPanel。由於我們設計的瀏覽器沒有標題欄，所以檢視titleBar就是系統的標題欄，它包含了關閉、最小化按鈕。
2.定製模組載入基址
Extjs有一套獨特的模組載入機制，它可以通過js類的名稱空間來載入相應的js程式碼檔案，比如檢視檔案的名稱空間是UTMP.sys.menuTree，ExtJs框架會從appFolder指定的路徑下找sys目錄下的menuTree.js檔案。在普通的ExtJs專案中，appFolder屬性並不用設定為絕對路徑，只需要使用相對路徑即可，但由於我們的專案的主頁（靜態頁面）是放在客戶端本地的，如果使用相對路徑的話，ExtJs框架就會在客戶端本地尋找相應的資源，然而我們的業務JS檔案都是放在服務端的，所以勢必會無法載入這些資源。
3.定製AJAX請求基址
模組載入機制可以通過設定appFolder基路徑來解決，但是對於業務JS程式碼隨處可見的AJAX請求該如何處理呢？確實，AJAX請求也會面臨這種問題，而且更為突出。因為在ExtJs中對AJAX請求做了很多封裝：proxy、store、request、load等，隨處可見ajax的身影。幸而ExtJs是一個物件化程度較高的js類庫，使得這個問題能很容易的解決。
在ExtJs中所有Ajax請求都離不開Ext.data.Connection類的支撐，我們可以使用ExtJs提供的觀察者模式來註冊Ext.data.Connection類的beforerequest事件（這是一種侵入性較強的做法），這樣所有的AJAX請求，不管是proxy發起的，還是request發起的，都逃不出我們的手心，具體實現程式碼如下：
|
Ext.util.Observable.observe(Ext.data.Connection,{
beforerequest: function(conn, options, eOpts){
options.url = "http://10.0.7.109:8080/UTMP/"+options.url;
}
});
|
五：分發
1.依賴的動態連結庫
在使用QTCreator開發基於QT的應用程式時，不管是debug編譯還是release編譯，都無法到編譯目錄下，通過雙擊exe程式來執行應用（會提示“無法啟動此程式，因為計算機中丟失xxxx.dll....”的錯誤資訊），之所以在IDE內能順利執行，是因為IDE已經為程式執行建立好了環境，但倘若不解決此問題，就無法把應用程式分發給直接使用者。
要解決此問題只要把Qt類庫提供的dll檔案放在可執行程式的目錄下或其所在目錄的子目錄下即可，在C:\Qt\Qt5.1.1\5.1.1\mingw48_32\bin目錄下有Qt類庫提供的大多數dll，這些dll名稱以字母d結尾的是debug編譯的應用程式所依賴的類庫，不以字母d結尾的則是release編譯的應用程式所需要的類庫，除了此目錄內的dll外，在C:\Qt\Qt5.1.1\5.1.1\mingw48_32\plugins目錄下還有一些應用程式需要的dll類庫。
如此數量眾多的dll，都需要打包到我們最終的安裝程式中去嗎？當然不用這麼做。通過IDE執行我們的應用程式時，我們只需要通過processExplorer工具來檢視應用程式程式所依賴的dll，即可判定哪些dll是需要打包到安裝包中去的（大多數情況下可以這麼做，如果是開發人員通過程式碼動態載入的類庫，那麼我相信你也會自行甄別的）。
2.打包
可能有的讀者會問：“我可不可以把類庫靜態編譯到exe中去呢？”當然可以，但是非常麻煩，你需要自己靜態編譯整個QT工程，還需要對IDE做出相應的調整（要編譯QT的Webkit還需要做更多的工作），這是一項耗時、耗力還不一定能成功的工作，我不建議這麼做。
當我們找到應用程式依賴的所有dll後，我們就可以使用打包工具來製作應用程式的安裝包，當然也可以自己開發安裝包工具（可以參見我的部落格：http://www.cnblogs.com/liulun/archive/2011/12/12/2284360.html）。
國內外有很多不錯的打包工具，我推薦使用inno setup（http://www.jrsoftware.org/），它支援編寫指令碼來控制安裝過程，使用LZMA壓縮演算法來打包程式（壓縮效率非常高，是7-zip使用的壓縮演算法），但它並不支援中文安裝介面，目前社群有開發者提供了針對inno setup的中文語言包，使用起來也非常方便。
請不要讓我除錯程式碼，老夫很忙！懶的管！