關注技術，關注生活

     摘要: 因為工作需要，在做過電子地圖和WEB游戲的JS應用程序后，將其中一些經驗跟大家分享一下。就像文章的名稱一樣，這篇里的優化方式并不是教你如果減少JS的時間，而是增加它的時間來達到高速度。不要懷疑你的眼睛，也不要懷疑我是標題黨，看下去自有分曉。  閱讀全文

     摘要: 這段時間開始使用SPRING2.5+Hibernate，發現里面對hibernate配置的Annotation無法支持對包路徑下的類進行掃描（annotatedPackages并不是這個作用），只能一個個添加，對比起xml配置的路徑掃描就弱了許多，也麻煩了許多。在網上搜了一下，發現在Spring Annotation這個項目中有實現這個方法，但在國內的網站上都沒提到過，所以就把內容給轉過來，方便大家參考下。  閱讀全文

我在之前的一篇文章《struts,ajax亂碼解決方案》中講到ajax提交亂碼的解決方案。這個方案在utf-8的編碼下，不管提交或獲取都沒有變成亂碼，但當你的客戶端是GBK編碼時提交就會出現亂碼（獲取時不會）。BeanSoft 說用encodeURIComponent保險，呵呵，這個不是我沒試過，從一開始我就試過了encodeURIComponent ,escape,encodeURI，但最后出來的結果都沒我說的那種好。它們使用的結果如下：
escape? 后提交，getParameter出來的是null，
encodeURI　后提交，和沒使用用的時候是一個樣，
encodeURIComponent? 后提交，包含特殊字符的請求都無法取得正確的值。

使用GBK編碼提交后的數據在使用服務器端用new String( value.getBytes("gbk"), "utf-8")后部分可以恢復正確的中文，但有一部分無法恢復，這個原因估計是AJAX提交時設置了編碼為UTF-8，但我字符的實際編碼是GBK，所以在提交用用request.getParameter()獲得的數據是用UTF-8的編碼在GBK的字符集中找字符，像我在《struts,ajax亂碼解決方案》中說的那樣，UTF-8的編碼可能有1位2位或3位16進制，如果它這個編碼剛好是2位的話，那在GBK可以找到正確的字符（但并不是正確的），但如果是三位呢？那就慘了，它后面的字符全部就會變成亂碼，比如%6D%51%C5　%E5%23%1C分別表示一個UTF-8編碼的中文字符，那如果在GBK中，就會把它當成三個字符去查找，當然肯定是找不到的，有些找到的也是你讀都讀不出來的。用new String( value.getBytes("gbk"), "utf-8")后就是用GBK的編碼在UTF-8的字符集中查找字符，如果剛好你的字符在UTF-8編碼中全部是2位的話，那就能正確恢復，如果不是的話。。。。。。

現在還沒找到在GBK編碼下比較好的解決方案，但今天看到BeanSoft 的一篇文章《JSP 中 AJAX 的表單提交中文問題的簡單解決方案》說到使用BASE64的方法，這個倒是沒有試過，過兩天放假的時候就試一下，如果成功了就跟大家共享一下。

PS：因為項目用也用到了FILTER，在提交后第一時間會被改變字符編碼，不知道是不是這個增加的亂碼解決的復雜性，當然我也試過在getParameter之前改變它的編碼回utf-8，但結果是一樣的。

     摘要: 亂碼問題好像跟我們中國程序員特別有緣，一直困擾著我們，從開始的JSP亂碼問題，STRUTS亂碼問題，到現在的AJAX亂碼問題，無一不是搞得許多程序員焦頭爛額的，整天罵XXX產品對中文支持不了，UTF-8無法使用中文啊什么的，其實這里面被罵的產品中其實99％以上是對中文支持非常好的，而出現亂碼的原因只是因為自身對國際化支持以及文件編碼等信息的認識不知造成的。要知道一個產品那么流行，怎么可能對中文支持不了呢，下面就開始一一幫大家解決這些問題。  閱讀全文

     摘要: 最近在做一個關于層拖動的相關代碼時，發現了一個關于prototype的bug，與此bug相關的類就是Position 。其結果就是導致標簽使用了某些方法后在頁面的某些情況下會定位錯誤。下面跟我一起看看這個煩人的問題。  閱讀全文