其他

深入equals方法equals方法的重要性毋須多言,只要你想比較的兩個對象不願是同一對象,你就應該實現equals方法,讓對象用你認為相等的條件來進行比較.下面的內容只是API的規範,沒有什麼太高深的意義,但我之所以最先把它列在這兒,是因為這些規範在事實中並不是真正能保證得到實現.1.對於任何參考型別, o.equals(o) == true成立.2.如果 o.equals(o1) == true 成立,那麼o1.equals(o)==true也一定要成立.3.如果 o.equals(o1)

1.好象是01年剛工作的時候,安裝什麼程式忘記了,提示gclib版本不相容,當時沒有經驗,其實做個link過去就行了.但是當時是下了一個其它版本,然後在系統中rm -rf

把要編碼的內容，傳給資料庫的預存程序，在預存程序裡用convert將未經處理資料格式轉換成xml的BINARY BASE64格式輸出。於是我在文章下面講了一個故事:有一個部落的族長非常聰明,就象樓主這類人.部落裡無論有大小事都來問他,他都能找出解決辦法,所以引得一般跟帖的族人的無限崇拜.有一天,一個族人家的牛頭套進罈子裡出不來了,於是族人來找族長.族長說把牛按住,把罈子取下來不就行了.族人說按不住,牛勁很大.族長說找幾個勇士來把牛射死,然後叫人按住,去取罈子.族人照著做了還是沒有取下罈子.族長說

從實模式到保護模式跳轉的詳解三年前拿到《自己動手寫作業系統》第一版的時候，雖然很有興趣，但是沒有時間詳細地看進去，直到前段時間又看到它的第二版出來，興趣又提上來了。正好此時的工作之餘可以深入地研究一下。 第一遍看這段代碼，沒懂（我承認是個很不聰明的人），只看懂了下面中文描述，說是從實模式跳到保護模式的。 第二遍看這段代碼，似乎懂了一些，大約20%吧。 第三遍，第四遍，第五遍...................第n遍，我懂了,我承認古代的大哥們是不騙人的，他們都說書讀百遍，其義自見。 第n+1遍

; ==========================================; pmtest3.asm; 編譯方法：nasm pmtest3.asm -o pmtest3.com; ==========================================%include    "pm.inc"    ; 常量, 宏, 以及一些說明org    0100h    jmp    LABEL_BEGIN[SECTION .gdt]; GDT;                  

特權級轉移比較複雜,但可以歸納為兩大類.1.對於程式碼片段,只能從低到高訪問.2.對於資料區段,只能從高到低訪問.然後再分解:程式碼片段從低向高(一致,目標特權級轉換為訪問者特權級)或相同(非一致).資料區段總是非一致.描述符本身是資料區段.比如調用門,TTS本身都是資料區段,所以必須從高特權級向低特權級訪問,即訪問者特權級<=門,TTS的DPL.(值小於等於表示特權級高).而通過門來存取碼段,無論是一致還是非一致程式碼片段,原則上是從低向高訪問.在非一致程式碼片段上,只有jmp指令要求訪

連一個十一流水平的WEB開發人員都知道的“不要根據GET請求的內容修改資料”都沒有遵守。如果所有更新操作的資料都檢查一下是否是POST請求，會出現被人利用URL這種弱智的方法攻擊嗎? 攻擊者甚至沒有利用CSRF/XSS這些稍微智能一點的方法。幾個月前測試過雖然首頁顯示的內容進行了XSS過慮，但查看詳細頁面竟然能成功彈出XSS(Android手機用戶端)，這說明對使用者輸入的內容並不是所有出口都進行了過慮。 不知道新浪是否有安資訊全官這一角色，反正安全問題還處於入門級水平。

因為不同瀏覽器對head處理的行為不同,所以下載對話方塊中的中文檔案名稱比較麻煩.沒有統一方法,不要以為你看到的是正確的中文,換個瀏覽器或換個版本就不一定正確了. 大多數情況下,預設轉出UTF-8的字串是可以的: String str = "這是一個UTF-8格式編碼的中文字串.dat";如果不是UTF-8,那麼轉換到 UTF-8的字串,大多數時候是有效.但是同樣是UTF-8字串,IE的不同版本看到的竟然是不同效果.雖然在contentTyep中已經指明

Content-location:refnameContent-Transfer-Encoding:base64PHNjcmlwdD5hbGVydCgncnVubmluZyEnKTwvc2NyaXB0Pg==這樣的純文字內容存為a.txt,放在任何web伺服器上。先直接存取:http://hostname/path/a.txt,看到的當然是上面的內容，因為它是body

從理論上說，AJP模式應該效能更高一些，它使用了壓縮指令。但是由於實現上不成熟，和apache的proxy方式比起來，不僅穩定性差，效能上也差不少。在一台apache

之前一個apache模組工作了好多年，它需要在apache啟動時同時啟動一個子進程和該模組通訊，模組攔截請求中一些資訊由該進程子進程收集然後做處理。在http.conf中使用 CustomLog "|  subprocesspath -k start -f xxx.conf

一個應用上出現400響應碼的請求增多，基本達到了千分之一，應用方請求我們分析原因。首先看日誌，檢查400請求的ip的其它請求是否正常，排除偽造請求的攻擊行為。發現使用者的User-Agent分布正常，ip分布正常。所有400請求的響應內容都是226位元組，說明伺服器返回給使用者的內容是固定的。400錯誤是使用者請求錯誤，使用者請求格式錯誤的原因基本可以分為兩種，一種是因為網路通訊造成資料殘缺，一種是違反了約定和資料格式或長度。如果是自訂用戶端，對協議的各種情況覆蓋不完整，違反資料格式或長度的情況

對於下載，用ContentType:application/octet-stream和Content-Disposition:attachment;filename=file.ext可以控制檔案完全以下載方式儲存，所以不需要開啟新視窗。 但是如果是線上開啟，比如開啟一個圖片，為了不影響當前視窗的瀏覽，就應該開啟一個新視窗來顯示圖片：<a href="openfile?file=file.ext"

現在能搜尋到的99年最早的在國內介紹Server Push的文章就是自己那篇"Server Push具體實現",今天調試竟然花了很長時間才正常工作。放在這裡做記錄吧： package test;import java.io.File;import java.io.FileInputStream;import java.io.IOException;import javax.servlet.ServletOutputStream;import

想換手機了。一直是nokia的忠粉，因為之前做過symbian開發，並且有4年的無線應用工作經驗，經手過幾千個手機，用來用去，單從“電話”這個功能來說的，NOKIA當然是老大。我說這話很多果粉X粉的肯定會噴，但是這話是有內容相關的。單從“電話”這個功能來說，沒有產品能和NOKIA比的，但是目前很多人對手機的需求已經不是純“電話”的功能，以上網閱讀，娛樂為主，那麼“應用”多少就成了新的選擇。其實對於一個純技術人員，我的電話用得也少，收郵件，看新聞等時間遠大於電話時間。所以我打算換一款非NOKIA的

Go deep into

自動歸還的對象池--一個並不美麗的傳說有一個美麗的傳說,精美的石頭它會唱歌........多麼令人神往的事啊(不用買MP3了),既然連石頭都會唱歌,於是太多的傳說誕生了.程式員雜誌第十一期上,發表了一篇題為<<自動歸還的對象池>>,作者為我們描述了一個美妙的可以自動歸還的對象池,讓每一個痛苦於記憶體回收的程式員帶來了心動的嚮往.但傳說真的會成為現實嗎?通讀全篇,沒有發現一行示意性的實現代碼,所有代碼片斷只是示意了擷取可回收對象的原理性機制,比如我要向大家介紹一種高效能的h

在方法出現異常時需要把傳入參數值和本地變數值異匯出來供分析。之前因為測試的對象都是普通的值，寫的loadLocalVarArray能正常工作。這幾天要在方法進入時inject一個long startTime供在方法退出時計算方法方法執行時間，發現如果本地變數是long和double本地變數棧中實際佔用兩個位置，而nextLocal和firstLocal是本地變數棧的地址位置，根本無法知道實際的本地變數個數和具體的索引。 當然用for(int i=0;i<

以前介紹大規模互連網應用時，session曾經作為單獨的一條特別特別地提出來。為什麼，因為它和資料庫連接消耗資源，而且，基本上入門+1級的程式員都知道要關閉資料庫連接，而session管理卻是極少有人關注。"企業級"應用再怎麼大也不會大過10萬級使用者，而互連網應用這種動輒上億規模的使用者，session管理一定不能讓容器自己來管理。 有些使用者僅僅來訪問一次，你卻要為他儲存幾十分鐘或幾個小時的資料。你什麼樣機器能經得住這樣的記憶體擴充？所以自己管理session才是大規模互連網應用的必須的策略

好久沒有開發Symbian了，入手一個C7，IME不是在位編輯的，很難受。其它所有手機IME目前在Symbian^3系統上都不能“正常運行”，於是想自己DIY一個IME，只是自己用。 裝Symbian^3環境完全是一個RP問題。莫名其的問題，沒有任何理由。1.jre 目前最新的2.perl