glassfish-v2 JSP request 中文參數亂碼解法

最近幾天用 Microsoft Visual Web Developer 2008 Express Edition 練習 ASP.NET + ADO.NET，順便把 Java 陣營兩大 IDE Eclipse 及 NetBeans 拿來比較一下開發的易用性…

心得是，以 NetBeans 用 JSF + JPA 開發網站，開發的效率並不下於 ASP.NET + ADO.NET。而 Eclipse 的 JPA 工具(稱為 Dali Java Persistence Tool) 的功能其實也相當完善，例如，它可以讓你由 Java class 產生 db table，也可以讓你由 table 產生 entity class。唯一在使用性上不足之處，是 Eclipse 出廠設定較 NetBeans 薄弱。例如，為了使用 JPA，你必須自行下載一個 JPA 的一個實作，而為了使用 JSF，你也必須自行下載一個 JSF 的一個實作。下載後還要自行設定… 需要看一點功夫才設定的起來。而 NetBeans 如果下載的是 Web & Java EE 版，預設就能直接開發 JSF + JPA 程式，甚至連範例專案都含在裡面，deploy 一下，直接就能 run 了。

以上都是雜話，以下是正文，但正文不會很多。

在測試 NetBeans 開發 Web 網站時，遇到一件有趣的事。就是以 NetBeans JSP web application 的預設組態，deploy 到 glassfish-v2 上，輸入中文時，取得的資料會是亂碼。但若是以 JSF 來開發 web application 便不會有中文亂碼的問題。

glassfish 中文亂碼的問題，可參考 FaqHttpRequestParameterEncoding 或 Servlet Character Encoding，在 sun-web.xml 中加入 default-charset="UTF-8" 得到解決，如下所示：

   <sun-web-app>
     <locale-charset-info default-locale="">
       <locale-charset-map locale="" charset=""/>
       <parameter-encoding default-charset="UTF-8"/>
     </locale-charset-info>
   </sun-web-app>

(注意，在 NetBeans 裡面，預設將 JSP 及 Java 檔都以 UTF-8 存檔，且 JSP 皆加入 <%@page pageEncoding="UTF-8"%> 指示)。

但 JSF 沒有中文亂碼問題，雖然這是好事，但反道讓我有些不解。用 Google 查詢一下，原來在 JSF 規範裡面有特別提到要如何解析當前 request 參數的編碼，Tips for JSF character encoding 有精要的描述。有了這些資訊，便不需再透過撰寫 filter 來解決編碼問題了。

Technorati : glassfish, java, jsf, jsp, programming

使用 Google Trends, 你有進行基值/基期校正嗎?

因為在 iThome 看到一位與我有一面之緣、熱衷 Flex 的高手，透過分析 Google Trends 資料，寫了一篇名為「RIA四雄群起：以Google Trends評析現有RIA四大技術(Flex、Silverlight、JavaFX、Curl)」的 blog。由於其中各種技術熱門程度的差異實在太大，激起了我進一步自行探索的動力。

第一件使我產生懷疑的是，文中指出 Flex 技術是 2004 年發行 1.0 版，我到 Wikipedia 查了一下資料，是 2004 年 3 月。那時候 Flex 還是 Macromedia 所提出的一個 Server 端方案，需配合貴死人的 Server 端執行。而由圖一可以明顯看出，Flex 的趨勢線在 2004 年初就一直處於高檔，直覺跟…好吧--年紀--告訴我這不合理。

圖一：未經校正的 Google Trends 查詢：Flex, Silverlight, JavaFX, Curl

而第二件讓我覺得更不合理的是，如果你直接透過 Google 查詢 Curl，可以發現十之八九都與 RIA 無關。這樣的查詢流量怎能將它全部歸到 Curl for RIA 這一塊呢。

我相信 Flex 這將近 0.9 的 Search Volumn Index，並非指 Macromedia/Adobe 的 Flex 技術；同樣的，Curl 大多的查詢流量也與 RIA 無關。為了進行檢驗，我將查詢語句作了一些修正，以期找出較具代表性的指標。新的查詢為：Macromedia Flex, Microsoft Silverlight, Sun JavaFX, Adobe Flex。

圖二：經過校正的 Google Trends 查詢：Macromedia Flex, Microsoft Silverlight, Sun JavaFX, Adobe Flex

這個查詢中，Flex 的熱門程度可用 Macromedia Flex + Adobe Flex 來代表。基本上可看出，在 2004 年 3 月以前，少有人關注 Flex。而 Microsoft Silverlight 的聲勢，"有段時間" 其實並不小於 Macromedia/Adobe Flex，那 Sun 的 JavaFX，就趴在地上了。

不過，究竟一般網民在查詢時，並不會特別以 Adobe Flex、Microsoft Silverlight 這樣的組字方式去下。以上，我所要說明的是，在以 Google Trends 進行分析時，得對基期或基值進行校正。透過第二個查詢我們已經證明 2004 年 3 月前的 Flex 流量，不能算是 Flex for RIA 這一塊的流量。如果將圖一 Flex 的流量值向下平移 0.9 單位，可以看出 Flex 對 Silverlight 的比值將接近圖二所示。

行文至此，是不是可以建議 Google Trends 提供類似基期/基值校正的功能。不然，就趕快把 Google Treands 的 API 給 release 出來吧!

相關連結：

• Google Trends: http://www.google.com/trends
• Flex: http://www.adobe.com/devnet/flex/
• Silverlight: http://www.microsoft.com/silverlight/
• JavaFX: http://www.sun.com/software/javafx/
• Curl: http://www.curl.com/
• Google Trends API coming soon: http://news.cnet.com/8301-10784_3-9828916-7.html
• iThome 原作者文章: RIA四雄群起：以Google Trends評析現有RIA四大技術(Flex、Silverlight、JavaFX、Curl)

Technorati : analysis, google, google trends, statistics, web

PMOG 簡易練功外掛

(2009/04/02)警告--本文一開始只是作為概念性驗證， 現在 PMOG 已針對這裡所提供的方法作出防範，勿再使用本文所提供之方法，以免告成帳號被刪 :(

前一陣子收到了 PMOG 的啟用信，便依照「電腦玩物」的說明，趁著工作空檔試玩了一下。突然想到，在一般的 game 系統，都有一些超級玩家或高手，懂得利用外掛程式來練功，那這個 client 端基於 Firefox 的遊戲平台，要寫一個練功的外掛應該也不是難事吧!

PMOG 平台裡面，透過 Datapoint 來代表玩家的經驗值。增加 Datapoint 最簡單的方式，就是瀏覽不同網域的網頁。如果我們要透過這樣的規則來練功，代表我們每天要想辦法去到不同的網域。而哪來那麼多不同的網域呢來瀏覽呢？

透過 Google 查詢，我找到一個 "Random Link" 連結，每當你瀏覽這個連結時，它會將你導到不同的網址。因此，你可以把這個連結放到 Firefox 的書籤工具列，每次按一下，就會連到不同的網頁。

接下來，就是想辦法讓上面的程序自動化。有時間、有時間精神的高手可以寫個 Firefox Extension。比較偷懶一點，就可以透過 Greasemonkey script 來達到這個功能。以下是我所使用的 user script：

// ==UserScript==
// @name           automatic random link
// @namespace      http://isong.blogspot.com/
// @description    visit random web pages automatically
// @include        *
// ==/UserScript==

setTimeout(function() {
  location.href = "http://random.yahoo.com/bin/ryl?"  + new Date().getTime();
}, 5000);                                

只要在 Greasemonkey 中增加此用戶腳本，然後在想練功時啟用此腳本，就可以看到你的 Datapoint 值不斷增加囉!

相關連結：

• PMOG: Passively Multiplayer Online Game 官方首頁
• 電腦玩物: 現實網路尋寶冒險，Firefox上的被動式多人線上遊戲：PMOG -- 完善的 PMOG 遊戲說明
• Greasemonkey: 可自訂你的網頁瀏覽體驗
• Greasemonkey Firefox 附加元件
• Userscripts.org: 可在這裡找到許多給 Greasemonkey 使用的用戶腳本
• Random Link: Yahoo! 所提供的隨機網頁連結

Technorati : firefox, funny, game, greasemonkey, pmog

用 JavaScript 來修飾你的超連結

網頁之間的互相引用、評論，是當代網誌的形式之一，而造就的結果就是正文之中充斥著超連結。

這樣的書寫風格本身並沒有所謂的好或不好。在我的日誌中，也存在不少此類用法。問題是，如果同一篇日誌中，重複提及一個特定的網頁，而該網頁又值得透過超連結參引，那麼重複編製超連結的動作，也會令人覺得繁瑣。

為此，我想到設定一種 "形式"，再加上 JavaScript，來為正文中的特定字眼加上連結。

構想是，在每篇網誌的最後，加上一段 "相關連結" 或 "參考資料"，段落名稱是什麼不重要，重點是：

1. 將連結以無序清單的形式標明，每一清單項目以連結開頭
2. 以冒號+空白 (": ") 來區分連結及解說文字，例如：
   • 愛頌過生活: 就是過日子，人生不需太多大道理!
   • DOM: Document Object Model (DOM); W3C 的官方說明

上例中的 "愛頌過生活" 及 "DOM" 字串，會被當作匹配條件，在正文的段落 (<p>...</p> 包起來的部分) 中，比對相符的字眼。若出現相符的字串，將被 JavaScript 套上超連結。

用來轉換文字成超連結的 JavaScript 程式碼如下：

<script type="text/javascript">
var init = {
  cmds: [],
  run: function(){
    for(i = 0; i < this.cmds.length; i++)
      this.cmds[i]();
  }
}

function getText(anchor){
   return anchor.text ? anchor.text : anchor.innerText;
}

function fixPostElements(){
   var uls = document.getElementsByTagName("ul");
   for(var i = 0; i < uls.length; i++)
      insertResourceLink(uls[i].parentNode)
}
function insertResourceLink(element) {
  var links= {};
  var lis = element.getElementsByTagName("li");
  for (var i = 0; i < lis.length; i++){
    if(lis[i].innerHTML.indexOf(": ") != 0){
      as = lis[i].getElementsByTagName("a");
      for(j = 0; j < as.length; j++)
        links[getText(as[j])] = as[j].href;
    }
  }
  var ps = element.getElementsByTagName("p");
  for(key in links) {
    var regKey = new RegExp(key, "g");
    for(var i = 0; i < ps.length; i++) {
      ps[i].innerHTML = ps[i].innerHTML.replace(regKey,
         "<a href="+ links[key] +">" + key +"</a>");
    }
  }
}
init.cmds.push(fixPostElements);
</script>

將上面的程式碼置於 HTML 的 head 區塊，在 body tag 中加上 onload="init.run()"，於撰寫網誌時採用本文規範的形式，即可達所述的效果。

一篇符合本文形式規範的網誌文章，可參考 "PRISM for Firefox 3 beta 5 url link opening issue"。事實上，筆者正是在撰寫該文時，因對重複的超連結編製深感不耐，才產生此構想的。

附帶一提，如果讀者採用 Google Reader 或其他 RSS 閱讀軟體，那麼你將無法看到此 JavaScript 的效果，因為 RSS feed 中並不含 JavaScript 轉譯碼… 這樣的設計，或許可以解釋為：「為親自造訪本站的讀者，所提供的一點加值服務 ^__^」。

Prism for Firefox 3 beta 5 url link opening issue

今天將自用的電腦換成還在 beta 中的 Firefox 3，順手就裝了可以「將網頁變成桌面程式」的擴充套件 Prism。它的功能一如產品網頁描述，可以在桌面產生一個 URL 連結，也可以顯示 tray icon。

我首先轉換的應用網站便是 Gmail，轉換成完後，點選桌面 Gmail 捷徑，帶出一個沒有任何修飾 (不會讓你分心) 的 Gmail 應用程式視窗。怪的是，在我的環境 Windows XP + 這樣的組合下，在 Prism 的 Gmail 網頁中開啟 URL 連結時，它開啟的外部瀏覽器竟是 IE，而不是我所期望的 Firefox。在 Firefox 「工具/選項/進階」中將 firefox 設定成系統預設瀏覽器也沒有用。

本想試試 Linky 這個專門用來改進連結開啟方式的擴充套件，但在 Prism 中卻無法安裝。我沒去細究那是 Prism 本身，還是 Linky 或 Firefox bata 3 的版本關係，總之就是不能用。

查了一下 firefox command line arguments, 看到了 -setDefaultBrowser 這個選項，可以將 firefox 設定成系統預設瀏覽器。於是我試著在 DOS 指令視窗中輸入以下指令：

C:\>cd "\Program Files\Mozilla Firefox 3 Beta 5"
C:\Program Files\Mozilla Firefox 3 Beta 5>firefox -setDefaultBrowser

沒想到這麼一來，當我再次於 Prism 的 Gmail 網頁中開啟連結時，竟然就能將連結開啟於 Firefox 中了。

相關連結：

• Prism: 將網頁變成桌面程式
• Gmail: Google 所推出的 webmail 服務
• firefox command line arguments: 說明 firefox 啟動參數
• Linky: firefox 延伸套件

Technorati : bug fix, firefox, firefox 3, prism, tweak

Miro 1.2.* 無法啟動的 Bug 及 Quick Dirty Fix

Miro 這套以 XUL Runtime 為基礎的網路影片撥放軟體，有著優良的使用介面及易用豐富的影片搜尋功能，在網路上已經有不少 blogger 介紹過，我就不再贅言。

如果你也是 Miro 的愛好者，或是看過介紹後躍躍欲試，卻同我一樣遭遇以下畫面：

除了程式視窗外框、骨架外，所有內容都沒有顯示出來。那麼底下提供一個 quick dirty fix，或許可以解你想看影片的燃眉之急。

首先，找到 C:\Program Files\Participatory Culture Foundation\Miro\components\pybridge.py 這個檔案。找到其中一段程式碼：

   keyElement.setAttribute('keytext', _('Spacebar'))

由於這行程式中的 _(Spacebar) 在執行期會運算成 "空白鍵" 這個中文字串，進一步造成 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 0: ordinal not in range(128) 的錯誤。因為並未深入了解 Miro 完整的 localization 架構，這是一個目前看來我無法完整解決的問題。因此我採用一個 quick dirty fix，將上面那行改成如下：

   keyElement.setAttribute('keytext', 'Spacebar')

注意，由於程式是 python 語言，因此請不要改變以上程式碼的縮排。儲存檔案，重新開啟 Miro，那麼你應該可以重新找尋、欣賞喜好的影片了。

Note: 本方法僅在 Window Miro 1.2, 1.2.2 版上試驗過。

Technorati : bug, bug fix, miro, video, web

該學那些程式語言2008版

這主題向來是討論區上常被提出的問題，一言以蔽之，選擇最好的或最受歡迎的…

選擇最受歡迎的，站在你自己的角度來看，它可以提高你在市場上的身價，讓你找的到工作，可以填飽肚子。而站在別人的角度來講，你開發出來的系統容易讓別人接手，開發系統時可用的支援較多，市場的接受度較高，不用重新教育使用者。

選 擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 XML 剛出來時，大力推廣 XML 的勞虎，在網路上廣泛傳送其免費電子書《無廢話 XML》，而今多少學習 XML 的網民，還是感念其恩德啊!

那麼，以下便是我的選擇。我會說明其主要應用，及個人對它的觀感。

最受歡迎：

C/C ++：這應該是正統資訊工程科系都必修的語言吧，它的應用不但能讓你直指核心(C)，也能讓你站在物件的具像高度(C++)，思考系統的構成。像是系統程 式、原生應用程式、軔體、Driver 等，皆是 C/C++ 應用所及之處。尤其台灣電子產業相對發達，在各種掌上型、智慧型裝置不斷推陳出新的今天，對C/C++的人力資源有高度需求。不過這個語言(尤其 C++)因為承載太多歷史包袱，各種實作變體太大，開發時常需用很多 tricks，在應用時需要付出較多心力，在程式語言本身及各種環境歧異的細節上!

Java：如果你唸資工 系，但學校 C/C++ 課程非必修，那麼至少 Java 是必修課程吧! Java 除了較少用在系統程式外，其他領域幾乎都占有一席之地。由於 Java 具有良好的物件導向基礎，當代許多企業應用皆採 Java Solution，尤其是在 SOA/ESB/EAI 等領域。採用 Java Solution 的好處是自由度高，但缺點就是很多事情沒有標準作法，或支援標準作法的解決方案太多，往往要花費不少時間在選擇如何架構系統上。

C# & VB.NET：這能讓你賺錢! 可以讓你快速的寫出漂漂亮亮的應用程式! 能讓你與微軟的企業系統做 完美的結合。像是 BI(OLAP、Reporting、Data Mining)那一塊，是 Java 在應用上比較需要費心的。而 .NET 相對於 Java 較緊緻的技術堆疊，能讓開發者較專注於應用程式的開發上。缺點是，離開了微軟平台的世界，就幾無用武之地。

PHP/Ruby：如果你想 run 自己的 business，或想建立一個像黑米、放P、挖女孩那樣的網站，相信我，這是一個很好的選擇。不過由於目前這兩個語言主要用途只在 Web 開發上，因此特別要注意典範的轉移，或是其原來專精的部分不再具有優勢。

就典範轉移：我的意思是，PHP/Ruby 除了在 Web 開發上已有成功的 killer apps 之外，其實它們能做的事，其他語言或平台也都能做，除非它們能在別的應用領域一樣成功，否則對其未來發展仍是一項危機。而就 "其原來專精的部分不再具有優勢"，這並非不可能發生，請見以下的 ECMAScript 說明。但好消息是，至少在 2007 年，這兩個語言的排名在 TIOBE 上的排名都是往上升的。

最好的：

Python： 真正的跨平台，除了跨 Windows, Linux 這類原生作業平台外，它也有 Java 及 .NET 虛擬機器的移植版本。在 Java 與 .NET 競相誇炫平台能力之際，Python 仍能堅守語言本身的原味之美，是令人讚賞的。也因如此，Python 的應用領域眾多，從 Web、文字及檔案處理、科學到研究等，幾乎無所不包。事實上，很多研究平台內定的 scripting language 就是 python，像是用於統計的 SPSS、用於資料探勘的 Clementine 等。

D：被視為是 "C++ done right!" 的一個程式語言，支援了許多 C++/Java/C# 共有的特徵(OOP)，但卻也有些特徵是其他語言所欠缺(或尚在研議中)像 Out function parameters,Nested functions,Function literals,Closures,Resizeable arrays...。在現今 VM 當道的年代，D 仍編譯為 native executable，可見其定位，是比較接近 C/C++ 的。也就是適合拿來撰寫系統程式、原生應用程式、伺服器程式，以及網路應用程式等。不過，對於 D 被廣泛接受仍有重大疑慮，因直至目前為止還不知有任何較大型的專案採用 D 語言開發。相較於 Ruby 也沒有像 RoR 那樣的殺手級應用出現。

最受歡迎+最好的：

ECMAScript/JavaScript/ActionScript：JavaScript 與 ActionScript 都朝 ECMAScript 標準靠攏。本來 JavaScript 是被某些人唾棄的一無是處，以為它只會在瀏覽器上作作表面功夫的語言，但一朝 Ajax 的應用得到普遍的喜愛，JavaScript 的行情也就跟著水漲船高。但如果只是這樣，對於 ECMAScipt 最新標準的推廣倒不見得有多大助益。特別是後來 ActionScript 也遵循 ECMAScript 標準，而且號稱 ActionScript 3.0 是非常遵循，這就好玩了。因為 ActionScript 是應用在 Flex/Flash player 中，而瀏覽器中主要執行的指令語言是 JavaScript， 而這兩者都是當代 Thin Client/RIA 的主流，因此我們可以說 ECMAScript Family 幾乎已成為 Universal Client Lauguage。

再者，認為 JavaScript 只會在瀏覽器上作作表面功夫其實並非事實。早期 Netscape Enterprise Server 及 BroadVision One-to-One Server，在 JSP 尚未出現前，伺服器上執行的指令語言就是 JavaScript。而前文提到現在是 VM 當道的年代，現在 ActionScript 的 engine 也已成為一個 VM，叫 AVM，且已貢獻給 Mozilla，成立 Tamarin 專案，將來若用於 Firefox 中，網頁內的 JavaScript 跑起來說不定會跟飛的一樣。

若是真有人拿 AVM 來寫伺服器，說不定會光復 JavaScript 在 Server 端的失土哦 (好吧! 天方夜譚)! 說真的，AVM Server 版若成(例如成為 Apache 的一個 module)，要威脅 Java 或 .NET 既有地位是比較困難，因為這兩個平台既有應用多、進化動力也強；但對其他 Server 端的 Scripting Language 絕對是個威脅。想想看，若你能在 Server 端及 Client 端同時使用 ECMAScript，那使用 Ruby 或 PHP 的誘因是否會漸漸變弱呢！而 Ruby 會紅，並不是語言本身之美所致，而是出了一個 Ruby on Rails Framework，而 framework 裡面的 concepts 是很容易 porting 到別的語言或平台中的。

其他：

看了以上個人挑選出來的清單，看啊看的，現在還是程序導向和物件導向語言的天下。難道沒有其他不一樣思考面向的東西嗎? 有的，而且我們也還滿常用，像是 SQL，或是各式 Markup Language 了(雖然不是程式語言)。還有那些用在工程、模擬、統計分析、人工智慧上的，你沒有那個環境或從事相關職業，是幾乎無從著手的語言，而這些當然就不算在推薦之內。

結語：

一項語言要被廣為接受，在過去，我一直以為大廠的支援是個必要因素，但 PHP(XOOPs, Nuke...) 及 Ruby(RoR) 這種透過 Community 及 Killer Application 來帶動風潮的成功案例，似乎也印證了 "世界是平的" 的論點，在這個網路世代，不只大企業，小企業及個人一樣有機會。Killer Apps 與 Success Stories，可能比大廠背書更有價值。

而對於你的選擇，我想，如果要做個尋常的程式開發人員，我會建議你 ECMAScript Family 一定要學，那 Java 或 .NET 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。