大型網(wǎng)站經(jīng)歷的技術(shù)架構(gòu)演變：
- 應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器都安裝在同一臺(tái)主機(jī)
- 應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器分別安裝在不同主機(jī)
- 增加了分布式的緩存服務(wù)器
- 應(yīng)用服務(wù)器增加了好幾臺(tái)，變成集群
- 增加了CDN和反射代理服務(wù)器
- 數(shù)據(jù)庫服務(wù)器變成主從形式的服務(wù)器
- 數(shù)據(jù)庫服務(wù)器變成分布式的服務(wù)器，文件服務(wù)器也變成分布式服務(wù)器
- NOSQL分布式數(shù)據(jù)庫和搜索引擎的引入
- 應(yīng)用服務(wù)器雖然是多臺(tái)，但都是部署了同一應(yīng)用，這時(shí)將應(yīng)用拆分，每臺(tái)服務(wù)器部署不同的拆分應(yīng)用
- 雖然應(yīng)用已經(jīng)拆分，但每個(gè)應(yīng)用都是從頁面管到數(shù)據(jù)庫，這時(shí)繼續(xù)拆分，將存取數(shù)據(jù)庫的部份獨(dú)立，頁面部份
也獨(dú)立
架構(gòu)模式
- 分層，代碼放在不同的類中
- 分割，應(yīng)用放在不同的JVM中
- 分布式，部署在不同的物理機(jī)
- 集群，同一個(gè)應(yīng)用部署到不同的主機(jī)，可以負(fù)載均衡
- 緩存，CND加速、反向代理、本地緩存、分布式緩存
- 異步，消除高并發(fā)
- 冗余，多處備份
- 安全性
摘要：Java EE 7已于6月中旬正式發(fā)布，盡管新平臺(tái)包含了諸多新的特性，但是開發(fā)者對(duì)此似乎并不滿足，他們期待未來的版本Java EE 8中能夠包含更完善的特性，比如更大的CDI應(yīng)用范圍、標(biāo)準(zhǔn)的緩存API、現(xiàn)代化的安全框架等。
Java EE 7已于6月中旬正式發(fā)布，新版本提供了一個(gè)強(qiáng)大、完整、全面的堆棧來幫助開發(fā)者構(gòu)建企業(yè)和Web應(yīng)用程序——為構(gòu)建HTML5動(dòng)態(tài)可伸縮應(yīng)用程序提供了支持，并新增大量規(guī)范和特性來提高開發(fā)人員的生產(chǎn)力以及滿足企業(yè)最苛刻的需求。
下面的這個(gè)圖表包含了Java EE 7中的各種組件。橙色部分為Java EE中新添加的組件。
盡管新的平臺(tái)包含了諸多新的特性，但是開發(fā)者對(duì)此似乎并不滿足，盡管他們中的大部分還沒有遷移到Java EE 7（或許是由于Java EE 7的特性還不完善），但是這并不影響他們對(duì)于Java EE 8特性的設(shè)想。
比如，在Java EE 6發(fā)布（2009年12月10日發(fā)布）后，開發(fā)者Antonio Goncalves認(rèn)為該版本并沒有解決一些問題，因此寫了一個(gè)希望在Java EE 7中包含的特性清單。有趣的是，他寫的4個(gè)特性中，其中有2個(gè)（flows和batch）已經(jīng)包含在Java EE 7中了，而第3個(gè)特性（caching）原本也計(jì)劃包含其中，但由于開發(fā)進(jìn)度關(guān)系，在Java EE 7最終發(fā)布前被舍棄。
此舉促使開發(fā)者Arjan Tijms也寫了一個(gè)他希望在Java EE 8中出現(xiàn)的特性清單，如下。
- 無處不在的CDI（Contexts and Dependency Injection for Java EE，上下文與依賴注入）
- 更深入的Pruning（修剪）和Deprecating（棄用）
- 一個(gè)標(biāo)準(zhǔn)的緩存API
- administrative objects（管理對(duì)象）的應(yīng)用內(nèi)替代品
- 綜合的現(xiàn)代化的安全框架
- 平臺(tái)范圍內(nèi)的配置
下面就來詳細(xì)闡述這些特性的必要性。
1. 無處不在的CDI
實(shí)際上這意味著2種不同的東西：使CDI可以用在目前不能用的其他地方、基于CDI來實(shí)現(xiàn)和改造其他規(guī)范中的相關(guān)技術(shù)。
a. 使CDI可以用在其他地方
與Java EE 6相比，Java EE 7中的CDI的適用范圍已經(jīng)擴(kuò)大了很多，比如CDI注入現(xiàn)在可以工作在大多數(shù)JSF組件（artifacts）中，比如基于bean validation的約束驗(yàn)證器。不幸的是，只是大部分JSF組件，并非所有的，比如轉(zhuǎn)換器和驗(yàn)證器就不行，盡管OmniFaces 1.6將支持這些特性，但最好是在Java EE 7中能夠開箱即用。
此外，Java EE 7中的CDI也沒有考慮到JASPIC組件，在此之中注入操作將無法工作。即使http請求和會(huì)話在Servlet Profile SAM中可用，但是當(dāng)SAM被調(diào)用時(shí)，相應(yīng)的CDI作用域也不會(huì)被建立。這意味著它甚至不能通過bean管理器以編程方式來檢索請求或會(huì)話bean作用域。
還有一種特殊情況是，各種各樣的平臺(tái)artifacts可以通過一些替代的注解（如@PersistenceUnit）來注入，但早期的注入注解（@Resource）仍然需要做很多事情，比如DataSource。即使Java EE 7中引入了artifacts（如任務(wù)調(diào)度服務(wù)），但也不得不通過“古老”的@Resource來注入，而不是通過@Inject。
b. 基于CDI來實(shí)現(xiàn)和改造其他規(guī)范中的相關(guān)技術(shù)
CDI絕對(duì)不應(yīng)該只專注于在其他規(guī)范中已經(jīng)解決的那些問題，其他規(guī)范還可以在CDI之上來實(shí)現(xiàn)它們各自的功能，這意味著它們可以作為CDI擴(kuò)展。以Java EE 7中的JSF 2.2為例，該規(guī)范中的兼容CDI的視圖作用域可作為CDI擴(kuò)展來使用，并且其新的flow作用域也可被立即實(shí)現(xiàn)為CDI擴(kuò)展。
此外，JTA 1.2現(xiàn)在也提供了一個(gè)CDI擴(kuò)展，其可以聲明式地應(yīng)用到CDI托管的bean中。此前EJB也提供了類似的功能，其背后技術(shù)也使用到了JTA，但是聲明部分還是基于EJB規(guī)范。在這種情況下，可以通過JTA來直接處理其自身的聲明性事務(wù)，但是這需要在CDI之上進(jìn)行。
盡管從EJB 3版本開始，EJB beans已經(jīng)非常簡單易用了，同時(shí)還相當(dāng)強(qiáng)大，但問題是：CDI中已經(jīng)提供了組件模型，EJB beans只是另一個(gè)替代品。無論各種EJB bean類型有多么實(shí)用，但是一個(gè)平臺(tái)上有2個(gè)組件模型，容易讓用戶甚至是規(guī)范實(shí)現(xiàn)者混淆。通過CDI組件模型，你可以選擇需要的功能，或者混合使用，并且每個(gè)注解提供了額外的功能。而EJB是一個(gè)“一體”模式，在一個(gè)單一的注解中定義了特定的bean類型，它們之間可以很好地協(xié)同工作。你可以禁用部分不想使用的功能。例如，你可以關(guān)閉bean類型中提供的事務(wù)支持，或者禁用@Stateful beans中的passivation，或者禁用@Singleton beans中的容器管理鎖。
如果EJB被當(dāng)做CDI的一組擴(kuò)展來進(jìn)行改造，可能最終會(huì)更好。這樣就會(huì)只有一個(gè)組件模型，并且具有同樣有效的功能。
這意味著EJB的服務(wù)，如計(jì)時(shí)器服務(wù)（@Schedule、@TimeOut ）、@Asynchronous、 @Lock、@Startup/@DependsOn和@RolesAllowed都應(yīng)該能與CDI托管的bean一起工作。此外，現(xiàn)有EJB bean類型提供的隱式功能也應(yīng)該被分解成可單獨(dú)使用的功能。比如可以通過@Pooled來模擬@Stateless beans提供的容器池，通過@CallScoped來模擬調(diào)用@Stateless bean到不同的實(shí)例中的行為。
2. 更深入的Pruning（修剪）和Deprecating（棄用）
在Java EE平臺(tái)中，為數(shù)眾多的API可能會(huì)令初學(xué)者不知所措，這也是導(dǎo)致Java EE如此復(fù)雜的一個(gè)重要原因。因此從Java EE 6版本開始就引入了Pruning（修剪）和Deprecating（棄用）過程。在Java EE 7中，更多的技術(shù)和API成為了可選項(xiàng)，這意味著開發(fā)者如果需要，還可以包含進(jìn)來。
比如我個(gè)人最喜歡的是JSF本地托管bean設(shè)施、JSP視圖處理程序（這早在2009年就被棄用了），以及JSF中各種各樣的功能，這些功能在規(guī)范文件中很長一段時(shí)間一直被描述為“被棄用”。
如果EJB組件模型也被修剪將會(huì)更好，但這有可能還為時(shí)過早。其實(shí)最應(yīng)該做的是繼續(xù)去修剪EJB 2編程模型相關(guān)的所有東西，比如在Java EE 7中依然存在的home接口。
3. 一個(gè)標(biāo)準(zhǔn)化的緩存API
JCache緩存API原本將包含在Java EE 7中，但不幸的是，該API錯(cuò)過了重要的公共審查的最后期限，導(dǎo)致其沒能成為Java EE 7的一部分。
如果該規(guī)范能夠在Java EE 8計(jì)劃表的早期階段完成，就有可能成為Java EE 8的一部分。這樣，其他一些規(guī)范（如JPA）也能夠在JCache之上重新構(gòu)建自己的緩存API。
4. 所有管理對(duì)象（administrative objects）的應(yīng)用內(nèi)替代品
Java EE中有一個(gè)概念叫“管理對(duì)象（administrative objects）”。這是一個(gè)配置在AS端而不是在應(yīng)用程序本身中的資源。這個(gè)概念是有爭議的。
對(duì)于在應(yīng)用服務(wù)器上運(yùn)行許多外部程序的大企業(yè)而言，這可以是一個(gè)大的優(yōu)勢——你通常不會(huì)想去打開一個(gè)外部獲得的應(yīng)用程序來改變它連接的數(shù)據(jù)庫的相關(guān)細(xì)節(jié)。在傳統(tǒng)企業(yè)中，如果在開發(fā)人員和操作之間有一個(gè)強(qiáng)大的分離機(jī)制，這個(gè)概念也是有益的——這可以在系統(tǒng)安裝時(shí)分別設(shè)置。
但是，這對(duì)于在自己的應(yīng)用服務(wù)器部署內(nèi)部開發(fā)的應(yīng)用程序的敏捷團(tuán)隊(duì)來說，這種分離方式是一個(gè)很大的障礙，不會(huì)帶來任何幫助。同樣，對(duì)于初學(xué)者、教育方面的應(yīng)用或者云部署來說，這種設(shè)置也是非常不可取的。
從Java EE 6的@DataSourceDefinition開始，許多資源（早期的“管理對(duì)象”）只能從應(yīng)用程序內(nèi)部被定義，比如JMS Destinations、email會(huì)話等。不幸的是，這并不適用于所有的管理對(duì)象。
不過，Java EE 7中新的Concurrency Utils for Java EE規(guī)范中有明確的選項(xiàng)使得它的資源只針對(duì)管理對(duì)象。如果在Java EE 8中，允許以一個(gè)便攜的方式從應(yīng)用程序內(nèi)部配置，那么這將是非常棒的。更進(jìn)一步來說，如果Java EE 8中能夠定義一種規(guī)范來明確禁止資源只能被administrative，那么會(huì)更好。
5. 綜合的現(xiàn)代化的安全框架
在Java EE中，安全一直是一個(gè)棘手的問題。缺乏整體和全面的安全框架是Java EE的主要缺點(diǎn)之一，尤其是在討論或評(píng)估競爭框架（如Spring）時(shí)，這些問題會(huì)被更多地提及。
并不是Java EE沒有關(guān)于安全方面的規(guī)定。事實(shí)上，它有一整套選項(xiàng)，比如JAAS、JASPIC、JACC、部分的Servlet安全方面的規(guī)范、部分EJB規(guī)范、JAX-RS自己的API，甚至JCA也有一些自己的安全規(guī)定。但是，這方面存在相當(dāng)多的問題。
首先，安全標(biāo)準(zhǔn)被分布在這么多規(guī)范中，且并不是所有這些規(guī)范都可以用在Java EE Web Profile中，這也導(dǎo)致難以推出一個(gè)綜合的Java EE安全框架。
第二，各種安全API已經(jīng)相當(dāng)長一段時(shí)間沒有被現(xiàn)代化，尤其是JASPIC和JACC。長期以來，這些API只是修復(fù)了一些小的重要的問題，從來沒有一個(gè)API像JMS 2一樣被完整地現(xiàn)代化。比如，JASPIC現(xiàn)在仍然針對(duì)Java SE 1.4。
第三，個(gè)別安全API，如JAAS、JASPIC 和JACC，都是比較抽象和低層次的。雖然這為供應(yīng)商提供了很大的靈活性，但是它們不適合普通的應(yīng)用程序開發(fā)者。
第四，最重要的問題是，Java EE中的安全機(jī)制也遭遇到了“管理對(duì)象”中同樣的問題。很長一段時(shí)間，所謂的Java EE聲明式安全模型主要認(rèn)證過程是在AS端按照供應(yīng)商特定方式來單獨(dú)配置和實(shí)現(xiàn)的，這再次讓安全設(shè)置對(duì)于敏捷團(tuán)隊(duì)、教育工作者和初學(xué)者來說成為一件困難的事。
以上這些是主要的問題。雖然其中一些問題可以在最近的Java EE升級(jí)中通過增加小功能和修復(fù)問題來解決。然而，我的愿望是，能夠在Java EE 8中，通過一個(gè)綜合的和現(xiàn)代化的安全框架（盡可能地構(gòu)建在現(xiàn)有安全基礎(chǔ)上）將這些問題解決得更加徹底。
6. 平臺(tái)范圍內(nèi)的配置
Java EE應(yīng)用程序可以使用部署描述文件（比如web.xml）進(jìn)行配置，但該方法對(duì)于不同的開發(fā)階段（如DEV、BETA、LIVE等）來說是比較痛苦的。針對(duì)這些階段配置Java EE應(yīng)用程序的傳統(tǒng)的方法是通過駐留在一個(gè)特定服務(wù)器實(shí)例中的“管理對(duì)象”來實(shí)現(xiàn)。在該方法中，配置的是服務(wù)器，而不是應(yīng)用程序。由于不同階段會(huì)對(duì)應(yīng)不同的服務(wù)器，因此這些設(shè)置也會(huì)隨之自動(dòng)改變。
這種方法有一些問題。首先在AS端的配置資源是服務(wù)器特定的，這些資源可以被標(biāo)準(zhǔn)化，但是它們的配置肯定沒有被標(biāo)準(zhǔn)化。這對(duì)于初學(xué)者來說，在即將發(fā)布的應(yīng)用程序中進(jìn)行解釋說明比較困難。對(duì)于小型開發(fā)團(tuán)隊(duì)和敏捷開發(fā)團(tuán)隊(duì)而言，也增加了不必要的困難。
對(duì)于配置Java EE應(yīng)用程序，目前有很多可替代的方式，比如在部署描述符內(nèi)使用（基于表達(dá)式語言的）占位符，并使部署描述符（或fragments）可切換。許多規(guī)范已經(jīng)允許指定外部的部署描述符（如web.xml中可以指定外部的faces-config.xml文件，persistence.xml中可以指定外部的orm.xml文件），但是沒有一個(gè)統(tǒng)一的機(jī)制來針對(duì)描述符做這些事情，并且沒有辦法去參數(shù)化這些包含的外部文件。
如果Java EE 8能夠以一種徹底的、統(tǒng)一平臺(tái)的方式來解決這些配置問題，將再好不過了。似乎Java EE 8開發(fā)團(tuán)隊(duì)正在計(jì)劃做這樣的事情。這將會(huì)非常有趣，接下來就看如何發(fā)展了。
結(jié)論
Java EE 8目前尚處于規(guī)劃初期，但愿上面提到的大多數(shù)特性能夠以某種方式加以解決?？赡?#8220;無處不在的CDI”的幾率會(huì)大一些，此方面似乎已經(jīng)得到了很大的支持，且事情已經(jīng)在朝著這個(gè)方向發(fā)展了。
標(biāo)準(zhǔn)化緩存API也非常有可能，它幾乎快被包含在Java EE 7中了，但愿其不會(huì)再次錯(cuò)過規(guī)范審查的最后期限。
此外，“現(xiàn)代化的安全框架”這一特性已經(jīng)被幾個(gè)Java EE開發(fā)成員提到，但是此方面工作尚未啟動(dòng)。這可能需要相當(dāng)大的努力，以及大量其他規(guī)范的支持，這是一個(gè)整體性問題。順便說一句，安全框架也是Antonio Goncalves關(guān)于Java EE 7愿望清單中的第4個(gè)提議，希望Java EE 8可以解決這一問題。
摘要: 一、Flume介紹Flume是一個(gè)分布式、可靠、和高可用的海量日志聚合的系統(tǒng)，支持在系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時(shí)，F(xiàn)lume提供對(duì)數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。設(shè)計(jì)目標(biāo)：(1) 可靠性當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)，日志能夠被傳送到其他節(jié)點(diǎn)上而不會(huì)丟失。Flume提供了三種級(jí)別的可靠性保障，從強(qiáng)到弱依次分別為：end-to-end（收到數(shù)據(jù)agent首先將event寫到...
閱讀全文
OK，又是周末晚上，沒有約會(huì)，只有一大瓶Shasta汽水和全是快節(jié)奏的音樂…那就研究一下程序吧。
一時(shí)興起，我下載了D-link無線路由器(型號(hào)：DIR-100 revA)的固件程序 v1.13。使用工具Binwalk，很快的就從中發(fā)現(xiàn)并提取出一個(gè)只讀SquashFS文件系統(tǒng)，沒用多大功夫我就將這個(gè)固件程序的web server(/bin/webs)加載到了IDA中：
/bin/webs中的字符信息
基于上面的字符信息可以看出，這個(gè)/bin/webs二進(jìn)制程序是一個(gè)修改版的thttpd，提供路由器管理員界面操作功能?？雌饋硎墙?jīng)過了臺(tái)灣明泰科技(D-Link的一個(gè)子公司)的修改。他們甚至很有心計(jì)的將他們很多自定義的函數(shù)名都輔以“alpha”前綴：
明泰科技的自定義函數(shù)
這個(gè)alpha_auth_check函數(shù)看起來很有意思！
這個(gè)函數(shù)被很多地方調(diào)用，最明顯的一個(gè)是來自alpha_httpd_parse_request函數(shù)：
調(diào)用alpha_auth_check函數(shù)
我們可以看到alpha_auth_check函數(shù)接收一個(gè)參數(shù)(是存放在寄存器$s2里)；如果alpha_auth_check返回-1(0xFFFFFFFF)，程序?qū)?huì)跳到alpha_httpd_parse_request的結(jié)尾處，否則，它將繼續(xù)處理請求。
寄存器$s2在被alpha_auth_check函數(shù)使用前的一些操作代碼顯示，它是一個(gè)指向一個(gè)數(shù)據(jù)結(jié)構(gòu)體的指針，里面有一個(gè)char*指針，會(huì)指向從HTTP請求里接收到的各種數(shù)據(jù)；比如HTTP頭信息和請求地址URL：
$s2是一個(gè)指向一個(gè)數(shù)據(jù)結(jié)構(gòu)體的指針
我們現(xiàn)在可以模擬出alpha_auth_check函數(shù)和數(shù)據(jù)結(jié)構(gòu)體的大概樣子：
struct http_request_t { char unknown[0xB8]; char *url; // At offset 0xB8 into the data structure }; int alpha_auth_check(struct http_request_t *request);alpha_auth_check本身是一個(gè)非常簡單的函數(shù)。它會(huì)針對(duì)http_request_t結(jié)構(gòu)體里的一些指針進(jìn)行字符串strcmp比較操作，然后調(diào)用check_login函數(shù)，實(shí)際上就是身份驗(yàn)證檢查。如果一旦有字符串比較成功或check_login成功，它會(huì)返回1；否者，它會(huì)重定向?yàn)g覽器到登錄頁，返回-1;
alpha_auth_check函數(shù)代碼片段
這些字符串比較過程看起來非常有趣。它們提取請求的URL地址(在http_request_t數(shù)據(jù)結(jié)構(gòu)體的偏移量0xB8處)，檢查它們是否含有字符串“graphic/” 或 “public/”。這些都是位于路由器的Web目錄下的公開子目錄，如果請求地址包含這樣的字符串，這些請求就可以不經(jīng)身份認(rèn)證就能執(zhí)行。
然而，這最后一個(gè)strcmp卻是相當(dāng)?shù)奈矍颍?/p>
alpha_auth_check函數(shù)中一個(gè)非常有趣的字符串比較
這個(gè)操作是將http_request_t結(jié)構(gòu)體中偏移量0xD0的字符串指針和字符串“xmlset_roodkcableoj28840ybtide”比較，如果字符匹配，就會(huì)跳過check_login函數(shù)，alpha_auth_check操作返回1(認(rèn)證通過)。
我在谷歌上搜索了一下“xmlset_roodkcableoj28840ybtide”字符串，只發(fā)現(xiàn)在一個(gè)俄羅斯論壇里提到過它，說這是一個(gè)在/bin/webs里一個(gè)“非常有趣”的一行。我非常同意。
那么，這個(gè)神秘的字符串究竟是和什么東西進(jìn)行比較？如果回顧一下調(diào)用路徑，我們會(huì)發(fā)現(xiàn)http_request_t結(jié)構(gòu)體被傳進(jìn)了好幾個(gè)函數(shù)：
事實(shí)證明，http_request_t結(jié)構(gòu)體中處在偏移量 0xD0處的指針是由httpd_parse_request函數(shù)賦值的：
檢查HTTP頭信息中的User-Agent值
將http_request_t + 0xD0指針指向頭信息User-Agent字符串
這代碼實(shí)際上就是：
if(strstr(header, "User-Agent:") != NULL) { http_request_t->0xD0 = header + strlen("User-Agent:") + strspn(header, " \t"); }知道了http_request_t偏移量0xD0處的指針指向User-Agent頭信息，我們可以推測出alpha_auth_check函數(shù)的結(jié)構(gòu)：
#define AUTH_OK 1 #define AUTH_FAIL -1 int alpha_auth_check(struct http_request_t *request) { if(strstr(request->url, "graphic/") || strstr(request->url, "public/") || strcmp(request->user_agent, "xmlset_roodkcableoj28840ybtide") == 0) { return AUTH_OK; } else { // These arguments are probably user/pass or session info if(check_login(request->0xC, request->0xE0) != 0) { return AUTH_OK; } } return AUTH_FAIL; }換句話說，如果瀏覽器的User-Agent值是 “xmlset_roodkcableoj28840ybtide”(不帶引號(hào))，你就可以不經(jīng)任何認(rèn)證而能訪問web控制界面，能夠查看/修改路由器的 設(shè)置(下面是D-Link路由器(DI-524UP)的截圖，我沒有 DIR-100型號(hào)的，但DI-524UP型號(hào)使用的是相同的固件)：
訪問型號(hào)DI-524UP路由器的主界面
基于HTML頁上的源代碼信息和Shodan搜索結(jié)果，差不多可以得出這樣的結(jié)論：下面的這些型號(hào)的D-Link路由器將會(huì)受到影響：
- DIR-100
- DI-524
- DI-524UP
- DI-604S
- DI-604UP
- DI-604+
- TM-G5240
除此之外，幾款Planex路由器顯然也是用的同樣的固件程序：
你很酷呀，D-Link。
腳注：萬 能的網(wǎng)友指出，字符串“xmlset_roodkcableoj28840ybtide”是一個(gè)倒序文，反過來讀就是 “editby04882joelbackdoor_teslmx”——edit by 04882joel backdoor _teslmx，這個(gè)后門的作者真是位天才！
1.vi 模式
a) 一般模式： vi 處理文件時(shí)，一進(jìn)入該文件，就是一般模式了.
b) 編輯模式：在一般模式下可以進(jìn)行刪除，復(fù)制，粘貼等操作，卻無法進(jìn)行編輯操作。等按下‘i,I,o,O,a,A,r,R’等
字母之后才能進(jìn)入編輯模式.通常在linux中，按下上述字母時(shí)，左下方會(huì)出現(xiàn)'INSERT'或者‘REPLACE’字樣,才可以
輸入任何文字到文件中.要回到一般模式，按下[ESC]鍵即可.
c) 命令行模式：在一般模式中，輸入“: 或者/或者?”,即可將光標(biāo)移動(dòng)到最下面一行，在該模式下，您可以搜索數(shù)據(jù)，而且讀取，
存盤，大量刪除字符，離開vi，顯示行號(hào)等操作.
2.vi 常用命令匯總:
2.1 一般模式
a) 移動(dòng)光標(biāo)：
--> 上下左右方向鍵 ↑↓← →
--> 翻頁 pagedown / pageup 按鍵
--> 數(shù)字 0 : 將光標(biāo)移動(dòng)到當(dāng)前行首
--> $ : 將光標(biāo)移動(dòng)到當(dāng)前行尾
--> G : 移動(dòng)到這個(gè)文件的最后一行 nG : n 為數(shù)字，移動(dòng)到這個(gè)文件的第n行.
--> gg: 移動(dòng)到這個(gè)文件的第一行 相當(dāng)于 1G
b) 搜索與替換
--> /word : 從光標(biāo)開始，向下查詢一個(gè)名為word的字符串。
--> :n1、n2s/word1/word2/g : n1 與n2 為數(shù)字.在第n1與n2行之間尋找word1這個(gè)字符串,
并將該字符串替換為word2。
--> :1、$s/word1/word2/g : 從第一行到最后一行尋找word1字符串，并將該字符串替換為word2
--> :1、$s/word1/word2/gc: 從第一行到最后一行尋找word1字符串，并將該字符串替換為word2。
并且在替換之前顯示提示符給用戶確認(rèn)（conform）是否需要替換。
c) 刪除，復(fù)制，粘貼
--> x,X : 在一行中，x為向后刪除一個(gè)字符（相當(dāng)于del鍵），X為向前刪除一個(gè)字符（相當(dāng)于backspace鍵）。
--> dd : 刪除光標(biāo)所在的那一整行。
--> ndd : n 為數(shù)字。從光標(biāo)開始，刪除向下n列。
--> yy : 復(fù)制光標(biāo)所在的那一行。
--> nyy : n為數(shù)字。復(fù)制光標(biāo)所在的向下n行。
--> p,P : p 為將已復(fù)制的數(shù)據(jù)粘貼到光標(biāo)的下一行，P則為貼在光標(biāo)的上一行。
--> u : 復(fù)原前一個(gè)操作
--> CTRL + r : 重做上一個(gè)操作。
--> 小數(shù)點(diǎn)'.': 重復(fù)前一個(gè)動(dòng)作。
2.2 編輯模式：
a) i, I : 在光標(biāo)所在處插入輸入文字，已存在的文字向后退。i 為‘從當(dāng)前光標(biāo)所在處插入’，I 為‘在當(dāng)前所在行的一個(gè)非空格符處開始插入’。
b) a, A : a 為‘從當(dāng)前光標(biāo)所在處的下一個(gè)字符開始插入’。A 為‘從光標(biāo)所在行的最后一個(gè)字符處開始插入’。
c) o,O : 這是英文o的大小寫。o為‘在當(dāng)前光標(biāo)所在行的下一行處插入新的一行’。O表示‘在當(dāng)前光標(biāo)所在行的上一行插入新的一行’。
d) r,R : 替換：r 會(huì)替換光標(biāo)所在的那一個(gè)字符。 R ： 會(huì)一直替換光標(biāo)所在的字符，直到按下esc 鍵為止。
e) ESC : 進(jìn)入一般模式。
2.3 命令模式：
a) :w : 將編輯的數(shù)據(jù)寫入硬盤
b) :q : 離開vi
c) :q! : 強(qiáng)制離開，不存儲(chǔ)
d) :wq : 存儲(chǔ)后離開
e) :wq! : 強(qiáng)制存儲(chǔ)后離開
3. vim 附加命令行
3.1 塊選擇（visual block)
v 字符選擇，將光標(biāo)經(jīng)過的地方反白顯示
V 行選擇，會(huì)將光標(biāo)經(jīng)過的行反白選擇
ctrl + v 塊選擇，可以用長方形的方式選擇數(shù)據(jù)
y 復(fù)制反白的地方
d 將反白的地方刪除掉
3.2 多文件編輯
:n 編輯下一個(gè)文件
:N 編輯上一個(gè)文件
:files 列出當(dāng)前vim 打開的所有文件
3.3 多窗口功能
:sp 【filename】打開一個(gè)新窗口，如果加filename，表示在新窗口打開一個(gè)新文件
否則表示兩個(gè)窗口為同一個(gè)文件內(nèi)容
ctrl+wj 先按下ctrl ，再按下w后，放開所有按鍵，然后按下j，則光標(biāo)可移動(dòng)到下方的窗口
ctrl+wk 同上，不過光標(biāo)移動(dòng)到上面的窗口
ctrl+wq 其實(shí)就是:q結(jié)束離開。