三、選擇適宜的編碼格局。

 

　　一般狀況下，IIS日志文件的編碼格局有兩種，分別為UTF-8與ANSI兩種格局。在所有的字符集中，盡管ANSI比較有名。可是這個編碼格局可以說是專門為英文所設(shè)計的。用來存儲其他的言語時會呈現(xiàn)亂碼的狀況。如關(guān)于漢語就支撐的不是很好。為了解決這個問題，特意提出了一種新的編碼格局，即UTF-8。這是一種UNICODEd 一種變長字符編碼。假如UNICODE字符由2個字節(jié)標(biāo)明，則編碼成UTF-8很或許需要3個字節(jié)，而假如UNICODE字符由4個字節(jié)標(biāo)明，則編碼成UTF-8或許需要6個字節(jié)。UTF-8編碼可以經(jīng)過屏蔽位和移位操作快速讀寫。字符串比較時strcmp()和wcscmp()的返回結(jié)果相同，因此使排序變得愈加容易。字節(jié)FF和FE在UTF-8編碼中永遠不會呈現(xiàn)，因此他們可以用來標(biāo)明UTF-16或UTF-32文本。 UTF-8 是字節(jié)順序無關(guān)的。它的字節(jié)順序在所有體系中都是一樣的。

 

　　這些字符集的格局關(guān)于某些體系管理員來說或許有點艱深。其實體系管理員也不需要了解的這么清楚。只需要明白一個準(zhǔn)則。即假如日志中顯現(xiàn)的假如都是英文的話，那么選用ANSI編碼格局也不會有問題。可是假如日志中還會存在其他言語的話，則或許會呈現(xiàn)亂碼。為此筆者主張，仍是選用UTF-8的編碼格局為好。畢竟，其關(guān)于英文的支撐力度也是很好的。為此還不如一了百了的將其設(shè)置為UTF-8格局為好。以免以后再日志閱覽中遇到亂碼的煩惱。

 

　　四、選擇適宜的日志文件翻滾更新機制。

 

　　假如將IIS的日志記載都保存在一個文件中，明顯文件會很長。到時分，查看記載的時分，會很費事。為此最好可以將日志文件進行切割，切割成一個個小文件。這便利與后續(xù)的查詢與閱覽。在Windows7操作體系的IIS日志中，供給了很多的日志文件翻滾更新的方法。如可以依據(jù)時刻來創(chuàng)立新的日志文件。如可以按天、按周或許按月來完成日志文件的翻滾更新。一般狀況下，按月來更新即可。假如IIS服務(wù)器拜訪比較頻頻，也可以恰當(dāng)縮短這個日志文件翻滾更新的時刻距離。如可以將時刻距離調(diào)整為一周或許一天等等。這個時刻距離究竟多少為好，主要是看其記載的數(shù)量。假如日志記載數(shù)量多的話，那么可以恰當(dāng)縮短時刻。相反，假如日志記載數(shù)量不是很多的話，則可以以月為單位樹立新的日志文件。

 

　　除了可以依據(jù)時刻來樹立新的日志文件之外，還可以依據(jù)日志文件的巨細(xì)來創(chuàng)立新的日志文件。在IIS日志管理器中可以選擇“最大文件巨細(xì)”。然后輸入一個適宜的尺寸。如此的話，當(dāng)這個日志文件達到指定的巨細(xì)之后，體系就會主動對其進行日志切換。不過筆者并不附和選用這種方法。盡管其可以將重做日志文件控制在一個合理的巨細(xì)內(nèi)，可是其會打破其內(nèi)涵的時刻聯(lián)絡(luò)。到時分，在遇到問題時查詢起來會非常的不便利。故筆者仍是樹立按時刻來對重做日志文件進行切割。

 

別的管理器還供給另一個有用的選項，即是否要將本地時刻用戶文件命名與翻滾。這是一個很有用途的選項。選中這個選項后，在體系主動樹立的日志文件中就會反映這個時刻信息。這關(guān)于體系管理員來查找日志文件，可以供給很大的幫助。特別是假如按文件巨細(xì)來切割重做日志文件的話，一定要選中這個選項，以便利后續(xù)的查找。希望這些內(nèi)容能對你進一步配置和管理 Windows 7 上的 IIS 日志記錄有所幫助。