@ZOE
可以，歡迎轉(zhuǎn)載。只要保留原始出處就可以了
@cherry
二次統(tǒng)計(jì)，即把某個(gè)人的某些數(shù)值統(tǒng)計(jì)總和后，再加上另外一個(gè)人的數(shù)值總和
@xiaofen
(30/24/60)= (1/24/60 *30) ，也就是一天有24個(gè)小時(shí)，小時(shí)有60分鐘。那么1分鐘等于多少天呢？就是 1/24/60啊。如果是30分鐘就是乘以 30
不錯(cuò)的產(chǎn)品，很感興趣。轉(zhuǎn)載到我的博客啦，謝謝博主的分享
很好，第一次看到這樣的用法。俺以前一直是使用腳本刪除的
@5452
這不就是我文章中想闡明的觀點(diǎn)嗎？
同步的情況下可以存在阻塞、非阻塞。異步的情況下也可以存在阻塞、非阻塞的讀寫。
要不也不會(huì)出現(xiàn)上面列出的4種情況啦
@沒頭腦和不高興
@bat
UTF-8字匯和GB18030是兼容的，GB18030基本上是GBK的超集，僅規(guī)范了個(gè)別碼位。所以belabela
====================================================
我的印象中，UTF-8是使用3個(gè)字節(jié)來表示中文的，GB18030是使用2個(gè)字節(jié)，他們對(duì)同一個(gè)漢字的編碼各自不同，你說的兼容是指那方面的呢？
GB18030 》GB2312 》GBK 這個(gè)我就記得是兼容的
@沒頭腦和不高興
GBK和UTF-8都是交換碼，只是字節(jié)，所謂的GBK字符是指誤將GBK當(dāng)做ISO-8859-1轉(zhuǎn)換成的字符吧?
==================================================
準(zhǔn)確說不是誤傳，而是HTTP協(xié)議只支持使用ISO-8859-1的協(xié)議傳遞，客戶端的瀏覽器是按照GBK的編碼轉(zhuǎn)換成4個(gè)字節(jié)發(fā)出的。字節(jié)的內(nèi)容和順序還是正確的。
其次你說的交換碼是什么意思？請(qǐng)指教
那么還是new String(tmp.getBytes("ISO-8859-1"), "GBK").getBytes("UTF-8")
==================================================
你這個(gè)做法沒錯(cuò)，最終得到的就是從Unicode--->UTF-8編碼，再用這個(gè)就可以構(gòu)造出UTF-8的字符串了。
但是我個(gè)人比較懶(^_^)，其次我想節(jié)省內(nèi)存空間(不生成臨時(shí)的GBK字符)，所以就直接從字節(jié)開始轉(zhuǎn)了
@沒有腦和不高興
你所說的tmp.getBytes("UTF-8");是直接從內(nèi)存中取出Unicode，然后轉(zhuǎn)換成UTF-8編碼的字符，再得到該字符的字節(jié)數(shù)組。這個(gè)時(shí)候的編碼轉(zhuǎn)換流程是：
Unicode字符 ---> encode字符 ---> encode byte[]
而我文章中的內(nèi)容是針對(duì)“原始數(shù)據(jù)以GBK格式傳輸，在目的端要轉(zhuǎn)換成UTF-8的格式保存”，從時(shí)機(jī)上說比你這個(gè)要早了一步，這個(gè)時(shí)候的編碼轉(zhuǎn)換流程是：
GBK字符 ---> GBK字節(jié)---> 以ISO-8859-1 單字節(jié)傳輸 ---> 【轉(zhuǎn)換為UTF-8字節(jié)】---> UTF-8字符 ---> Unicode字符
帶方括號(hào)的就是我文章中講的內(nèi)容，請(qǐng)注意中間并沒有生成GBK字符。而是直接在字節(jié)級(jí)就進(jìn)行轉(zhuǎn)換了。如果先解碼成GBK字符，再用UTF-8編碼，那就是你說的這種情況了。但是這樣就太繁瑣而且浪費(fèi)內(nèi)存空間了
@胡話胡說
你好，已經(jīng)發(fā)到你郵箱了。
@fwy Adrop
謝謝關(guān)注，我會(huì)在近期制作這個(gè)系列的CHM版本和PDF版本的。
re: 【原】有些人，有些事總是讓我們無奈[未登錄] Paul Lin 2009-10-27 21:36
@joegao
是善感，但不多愁。呵呵~~
最近看的幾部電影都是格調(diào)比較憂傷的，所以有感而發(fā)。
接受無奈也是豁達(dá)人生的一種表現(xiàn)
re: 【強(qiáng)烈推薦】《入殮師》主題音樂 Paul Lin 2009-05-06 00:55
@jeasonzhao
本來有一首4分鐘多的，只是BlogJava對(duì)文件上傳有大小限制。需要的話可以給我發(fā)郵件。呵呵
樓主的文章是很久以前的吧，居然還有介紹Oracle 7和8的認(rèn)證
@與你同飛
歌曲是當(dāng)時(shí)在網(wǎng)上一個(gè)不知名的網(wǎng)站：
http://www.5d5y.com/下載的，現(xiàn)在已經(jīng)找不到了。需要的話留個(gè)聯(lián)系方式。(文件都比較大)
不過還有一個(gè)不錯(cuò)的推薦《辛德勒的名單》原聲大碟：
http://www.5d5y.com/ListSpecialMusic.mspx?SpecialID=726
@zhouzhao21@gmail.com
謝謝鼓勵(lì)！
re: 新年新氣象，09年第一博[未登錄] Paul Lin 2009-01-04 11:55
@wan
共勉之。年輕沒有失敗，只因我們都曾努力過。我們永遠(yuǎn)都是在路上！
re: 單純的感動(dòng)[未登錄] Paul Lin 2009-01-04 10:02
@wan
謝謝鼓勵(lì)！^_^
re: 【版本控制之路】版本庫的備份[未登錄] Paul Lin 2009-01-01 11:01
@夢(mèng)想在這里起飛
支持國產(chǎn)軟件，很不錯(cuò)！
樓主這么快就轉(zhuǎn)型，確實(shí)不容易
re: 【版本控制之路】扛起SVN的大旗[未登錄] Paul Lin 2008-12-25 20:41
@robertlyc
學(xué)習(xí)了，呵呵。不過從使用程度來看。SVN還是保險(xiǎn)一點(diǎn)
@kmh
InputStream的read方法是阻塞的，所以在實(shí)際的應(yīng)用環(huán)境中我的做法是將其放在一個(gè)Thread或Runnable implement的類中，由run()方法調(diào)用，這樣其中一個(gè)線程在執(zhí)行到read方法而導(dǎo)致阻塞時(shí)，不會(huì)影響其他線程。
不知你有沒有更好的方法，歡迎探討
樓上的各位，除了注冊(cè)表重寫，添加驅(qū)動(dòng)文件之外，還要將原來聲卡的驅(qū)動(dòng)程序重新安裝一遍，然后確保設(shè)備管理器里面的聲卡啟用才行。
實(shí)在不行就只能上360的官網(wǎng)去咨詢了
@琪琪
你的操作系統(tǒng)是什么的，這個(gè)文件是有版本區(qū)分的。另外需要重啟后才能生效
@小林
把a(bǔ)udiosrv.dll放在system32目錄下即可，注意這個(gè)文件是有版本區(qū)別的。
360一直是我覺得非常好的軟件，這次出現(xiàn)這么嚴(yán)重的漏洞，確實(shí)不該。
@yxl
謝謝。最近一段時(shí)間比較忙，目前在GZ工作。你呢？
re: 一個(gè)平庸程序員的想法。 Paul Lin 2008-11-01 01:26
貌似這篇文章幾年前在CSDN的論壇上看過了，不過現(xiàn)在看來還是很有道理。
確實(shí)中國的程序員普遍存在一種“焦慮”的心里。為什么？因?yàn)樗麄儠?huì)的東西明天可能就不值錢了，他們會(huì)的東西可能別人培訓(xùn)個(gè)2~3個(gè)月也能跨進(jìn)這個(gè)門檻。
沒有殺手锏，沒有深挖。只有繡花拳，只有浮于表面。疲于追趕的背后的是對(duì)未來的恐懼和未知的迷茫。
原已此文和各位同行共勉
@li
如果不用分析函數(shù)的話，就比較麻煩了。你只能分別查詢出Customer, Region，和Customer的訂單額，地區(qū)的訂單總額。然后采用連接的方式：就是把兩個(gè)結(jié)果集拼在一起。條件就是customer 的id和region id必須分別等于另外2個(gè)查詢中的相應(yīng)字段值
re: 等我白頭發(fā)了~~[未登錄] Paul Lin 2008-09-25 22:38
傳說中的梨花體？呵呵
樓主的分析不錯(cuò)，特別是：3.blogjava需要一些可以聚焦人氣的活動(dòng)或氛圍。個(gè)人感覺blogJava的技術(shù)氣氛很好，相對(duì)CSDN，JavaEye這樣的網(wǎng)站，技術(shù)的氣息很濃厚。
但沒中不足的就是缺乏一些同道中人的交流活動(dòng)。希望負(fù)責(zé)人可以考慮增加一些博友的交流活動(dòng)。
elmentkaka
沒人不允許你發(fā)，也沒有說要經(jīng)過我同意。只是你在"喜歡"之前，要考慮一下別人的感受。畢竟這里不是你家的后花園，我們都希望在首頁看到的是有技術(shù)含量，有指導(dǎo)意義的文章。
建議你再看看blogjava的說明。
恕我啰嗦了，祝樓上學(xué)業(yè)進(jìn)步！
多謝樓主，F(xiàn)reeBook我上過，有一些只有購買鏈接，沒有下載連接。其它的還沒有去過。
elmentkaka
你誤解我的意思了。我不是說思想，設(shè)計(jì)模式不重要，我是指這種類似于個(gè)人計(jì)劃之類的東西就不要發(fā)表到首頁了。BlogJava的說明里面也提到了盡量發(fā)表一些技術(shù)文章。
你可以去國外的The Server Side或Java Ranch看看，有沒人發(fā)表這些到首頁去的。呵呵
這樣的東西就不要發(fā)表到首頁了，建議發(fā)表一些技術(shù)原創(chuàng)的文章或心得體會(huì)
re: 代碼不是調(diào)出來的[未登錄] Paul Lin 2008-08-04 17:49
發(fā)覺這里發(fā)表評(píng)論的人大多數(shù)把“調(diào)試”和“測(cè)試”搞混了。好的軟件是“測(cè)試”出來的，不是“調(diào)試”出來的。
頻繁地依賴于調(diào)試，說明了一個(gè)問題：寫這段代碼的人邏輯性很差，讓閱讀的人無法充分理解。
如果代碼是先人所為，這個(gè)沒有辦法，調(diào)試是一個(gè)重要的輔助手段。如果是自己寫代碼，那么說明你對(duì)目前要實(shí)現(xiàn)的這個(gè)功能邏輯還不清晰，所以不得不依靠頻繁的調(diào)試來驗(yàn)證邏輯。
我記得以前一個(gè)做QA的同事也說過：不要過于依賴調(diào)試，調(diào)試是一件很費(fèi)時(shí)的事情，他碰到錯(cuò)誤首先都是看代碼，實(shí)在不行再調(diào)試。但他找出來的錯(cuò)誤比誰都多。
我覺得如果你自己寫代碼的時(shí)候頻繁使用調(diào)試，那么你應(yīng)該想想是不是需要花點(diǎn)時(shí)間整理一下你的邏輯先？
非常感謝，請(qǐng)問有相關(guān)的紙質(zhì)版出版嗎？
re: ORACLE第一天[未登錄] Paul Lin 2008-06-12 10:48
不知所云
呵呵，老李的文章不錯(cuò)，適合我這等的菜鳥。
--------------------------------------
一個(gè)不會(huì)JS的菜鳥羞澀的爬過....
樓主，能不能把源代碼發(fā)一份給我，謝謝！
Email: rebornphoenix@126.com
Not bad but no use in China
re: “開源人”收費(fèi)得罪了誰[未登錄] Paul Lin 2008-03-11 09:30
@KF.咖啡
你當(dāng)你是誰？嚇唬人家啊。靠！自己沒本事就算了，還來這種下三濫的手段
re: “開源人”收費(fèi)得罪了誰[未登錄] Paul Lin 2008-03-10 13:15
樓主走自己的路，讓別人說去吧。
無知不是錯(cuò)，無知還要給人家看那是錯(cuò)了。