先說一說問題，不知道大家有沒有這樣的經驗，反正我是經常碰到。
舉例1，某些**每隔幾天就發郵件給我，每次發的郵件內容都是一些我根本不感興趣的東西，我不甚其擾，對其深惡痛絕。
舉例2，新增具有某功能的乙個msn機械人，每天都有幾次突然蹦出乙個視窗，推薦一堆我根本不想知道的內容，煩不煩啊， 我只好將你阻止掉。
每乙個觀眾只想看他感興趣的東西，而不是一下與之無關的事物，那麼如何才能知道觀眾的興趣所在呢，還是資料探勘，經過一番思考，終於有點思路，即根據使用者以往的瀏覽歷史來**使用者將來的行為，也就是基於內容的推薦。
基於內容的推薦（content-based recommendation）是資訊過濾技術的延續與發展，它是建立在專案的內容資訊上作出推薦的，而不需要依據使用者對專案的評價意見，更多地需要用機器學習的方法從關於內容的特徵描述的事例中得到使用者的興趣資料。在基於內容的推薦系統中，專案或物件是通過相關的特徵的屬性來定義，系統基於使用者評價物件的特徵，學習使用者的興趣，考察使用者資料與待**專案的相匹配程度。使用者的資料模型取決於所用學習方法，常用的有決策樹、神經網路和基於向量的表示方法等。基於內容的使用者資料是需要有使用者的歷史資料，使用者資料模型可能隨著使用者的偏好改變而發生變化。
基於1）不需要其它使用者的資料，沒有冷開始問題和稀疏問題。
2）能為具有特殊興趣愛好的使用者進行推薦。
3）能推薦新的或不是很流行的專案，沒有新專案問題。
4）通過列出推薦專案的內容特徵，可以解釋為什麼推薦那些專案。
5）已有比較好的技術，如關於分類學習方面的技術已相當成熟。
缺點是要求內容能容易抽取成有意義的特徵，要求特徵內容有良好的結構性，並且使用者的口味必須能夠用內容特徵形式來表達，不能顯式地得到其它使用者的判斷情況。
1 蒐集資料，即蒐集使用者的行為資料，其中也包括很多方法，根據我找到的資料與以往的經驗來看，web日誌可以作為我們的切入點，即我們的資料**。
2 過濾資料，web日誌中有很多無用的資訊，我們要把這些無用的資訊排除掉，而且要區分出使用者和日誌資料之間的聯絡。
3 分析資料，利用分類聚類技術分析出這些日誌資料之間的關聯性，以及這些日誌資料和使用者之間的關聯性，這也是最重要的一步。
4 輸出結果。
有了這個思路之後，我們可以著手做第一步，即日誌資料的收集
我們知道，大多數的web伺服器都是有自己的日誌記錄的，比如說apache安裝之後有乙個logs目錄，其中就有它的日誌檔案，一般說來它有自己的乙個格式，比如說：
1瀏覽器所在主機的 ip 位址(ip)； 2訪問日期和時間(date-time)；3客戶機與伺服器通訊所用的方法(methed，get or post)； 4客戶機請求訪問頁面的 url； 5伺服器返回的狀態(status)； 6客戶端瀏覽器的型別；
但是這個日誌檔案有一些不能克服的問題，或者我不知道如何克服，那麼我先說說我的疑問，首先，這個日誌檔案中記錄的是ip位址，據了解，網路中有很多計算機的ip位址是相同的，因為他們在乙個統一的路由後面，這個比例可能達到25%。那麼我們就無法根據ip位址來唯一確定乙個使用者。其次，一般的web伺服器中都會用多個應用，那麼其他應用的訪問資訊對我們來說有可能是多餘的。再者，web伺服器的日誌形式比較單一，靈活性不大，可定製的餘地很小，在日誌資料中有效資料所佔的比例較小。還有，一些靜態檔案的請求也會被web伺服器記錄下來，比如說js檔案，css檔案，還有檔案，等等這些東西對內容推薦來說都是無用的資源。
基於上面3點原因，我認為可以自定義日誌資料。為了解決使用者唯一性，我們讓應用為每乙個瀏覽器生成乙個clientid儲存在對應的瀏覽器上，這樣該瀏覽器只要訪問**，我們就可以確定這個瀏覽器的唯一性，當然我們仍然不能確定瀏覽器使用者的唯一性，但是我們可以更進一步，如果瀏覽器的使用者登陸**的話，我們就可以使用使用者id來確定使用者的唯一性，不過大多數**使用者可能在使用**的時候並不會登陸，我也是這樣，沒有關係，即使使用clientid問題也不會太大，隨著社會的發展，計算機的擁有量逐漸增加，一般來說乙個人只會使用一台固定的電腦，在公司裡尤其是這樣。所以我認為clientid的方案是可行的，也許有人要問，別人的瀏覽器禁止了cookie怎麼辦，那麼我只能說沒有辦法，不過還好事實是絕大多數人都沒有這樣做。
接下來我們可以定義一下我們所需要的日誌資料的格式，比如這樣，
ip，clientid，userid，url，datetime，get or post等等。
這樣資料有效性會大大提高。
在得到較為有效的資料之後，我們還需要對這些資料進行再次過濾：
1 去掉一些非內容的url，這些資料也是無效資料，這些非內容的url需要我們自己手工的統計出來，然後和日誌資料中的資料進行比對，將這些非內容資料從日誌資料中清除出去。
2 同時我們也需要把post請求從日誌資料中清除出去，或者我們在記錄日誌的時候根本不應該把post請求記錄下來。
經過以上步驟之後我們就可以開始第3個階段了，統計每個使用者的訪問的url，對這些url進行訪問，得到對應的html中所包含的資料，這些資料都是文字，將有用的文字提取出來，然後對這些有用的文字進行聚類。這樣就可以得到每個使用者喜歡的幾個類別。
問題：以上的流程只適用於沒有使用快取的系統，但是一般大型的**都會使用varnish，squid等等，使用它們之後我們就無法得到使用者訪問的日誌資料了，所以如果使用了varnish或者squid，我們不得不再次面對web伺服器的日誌資料。
在不考慮varnish或者squid的情況下，使用lucene+jamon+htmlparse基本就可以實現以上推薦系統。
通過鍊錶來實現對學生資訊的管理
動態從鍵盤讀入學生的姓名和成績，為每個學生建立乙個節點，並將所有學生的資訊構成乙個鍊錶 當使用者輸入0時，表示資訊輸入結束。然後程式輸出鍊錶中存放的學生資訊，並在程式結束以前釋放所有動態申請的空間 include include using namespace std struct studentn...
通過例項來實現split的理解
首先將這個url的各個部分區分開來，用split url,以下是具體的 parts split url,此時parts就有三部分，parts 0 ftp，parts 1 username，parts 2 password server 接下來剔除沒有用到的資訊 由於只取username，所以其中pa...
如何通過WEB方式，來控制iis的禁用IP名單
如何通過web方式，來控制iis的禁用ip名單。這個問題可以進一步劃分為兩個問題 1 如何控制iis的ipdeny 2 由於是web方式，預設的web帳戶許可權很低，不會有上面操作的許可權，如何處理。第乙個問題 微軟的msdn中給出了三種方法 這裡給出了兩種。其實都是使用 system.direct...