C # 裡面 ?? (雙問號)運算子的妙用

?? 運算子是在 2.0 版後新增的，至今我在別人的程式中還很少看到有在使用。
它的使用方式如下：

a = b ?? c;

上式的意思是，如果 b != null，那就把 b 的值指定給 a，否則就把 c 的值指定給 a。
照理講，?? 的功能完全可以由 ?: 運算子替代，如上式可以改寫如下：

a = b != null ? b : c;

不過，?? 對於簡化程式碼很有幫助，我相信許多 one liner 會很喜歡它，例如：

if (Session["WEB_TYPE"] == null)
{
Session.Add("WEB_TYPE", "");
}

可以改寫為：

Session["WEB_TYPE"] = Session["WEB_TYPE"] as string ?? "";

?? 的另一個特點是使用上可以串連，例如：

string a = null;
string b = null;
string c = "c";
string d = a ?? b ?? c;

這樣的意思，也就是由左到右，找到第一個非 null 值的變數，指定給 d。

於是，如果有一段程式如下 (抓取系統中的舊程式碼舉個例子)：

if (Session["WEB_TYPE"] == null)
{
Session.Add("WEB_TYPE", "");
}

//接收 Web_type
if (!IsPostBack)
{
if (Request.QueryString["WEB_TYPE"] != null)
{
webtype = Request.QueryString["WEB_TYPE"].ToString();
Session["WEB_TYPE"] = webtype;
}
}

可以用 ?? 運算子改寫成以下版本：

Session["WEB_TYPE"] = Session["WEB_TYPE"] as string ?? Request.QueryString["WEB_TYPE"] ?? "";

這樣程式就精簡許多，也更好理解與維護了。

搜尋引擎設定也能帶著走

Foxmarks/Xmarks 這類線上書籤同步工具的出現，讓我們在不同的電腦與瀏覽器之間同步書籤。我習慣叫這種應用叫 "書籤帶著走"。但是，不曉得有沒有人和我一樣，想把瀏覽器上的其他設定也帶著走呢？

對我來講，除了書籤之外，"搜尋引擎設定" 也是我想帶著走的。這裡的搜尋引擎，提的是「搜尋工具列」或是「Smart Search」裡面的搜尋引擎。

「搜尋工具列」大家比較清楚，就是網址列旁的搜尋框。而 Smart Search 知道的人或愛用的人可能比較少，有人叫它「智能搜尋」，或叫 Quick Searches，這裡有篇文章介紹；基本上是讓你把書籤當成搜尋引擎使用的一種方式。

過去我一直覺得奇怪，Firefox 為何要有兩套不同的搜尋機制，也不了解這兩者間如何選擇。後來因為有了 ConQuery 及 Context Search 這類套件，讓我可以在右鍵選單上直接使用搜尋功能，這種方便性讓我一直以「搜尋工具列」裡的搜尋引擎作為我的主要搜尋工具。

但是，搜尋工具列裡的搜尋引擎在使用上卻有一個缺點，那就是，他們無法像書籤一樣，可以帶者走… 因此，在 Firefox 2.x 版的年代，我便透過一套叫 FireUploader 的工具，手動將搜尋引擎設定上傳到某個網站，然後再於別台電腦將它們下載回來，但這終究不是長久之計啊!

後來找到一個就叫做 SmartSearch 的套件，這個套件做的事與 ConQuery 或 Context Search 類似，就是讓你可以在右鍵選單上，選擇你要使用的搜尋引擎進行查詢，但不同的地方在於，它的搜尋引擎選單是來自「智能搜尋」的 Quick Searches Bookmarks，這代表著，你的搜尋引擎清單就是書籤連結，是可以「帶著走」的--只要你同時安裝 SmartSearch 及 Foxmarks/Xmarks 即可。

相關連結：

• SmartSearch: Firefox 右鍵選單搜尋套件
• ConQuery: Firefox 右鍵選單搜尋
• Context Search: Firefox 右鍵選單搜尋
• Foxmarks: Foxmarks 書籤同步套件
• Xmarks: Firefox 的後繼者

Technorati : search, smart

如何取得 Web 應用程式的根目錄 Context URL

我們常常在開發 Web 應用程式時，會有需要取得 Context URL。例如，為了透過這個 URL 取得某些資源。Context URL，也就是 Web 應用程式根目錄的 URL。例如，給定一個 URL 如下：

    http://test.com:8080/AppContext/path/to/your/page

則 Context URL 指的是：

    http://test.com:8080/AppContext   

如果我們都是以相對路徑 (相對於根目錄或或目前路徑) 的方式來存取資源，那直接使用 Context URL 的必要性就比較低了。不過有時候並無法使用相對路徑，例如：

• 因為配合 API 的呼叫，你不曉得這個 API 會在虛擬路徑的第幾層呼叫，因此就無法提供相對路徑。
• 因為配合某種 code gen 機制，你要傳入一個 URL。
• 因為採用了某種 URL dispatch 的機制，導致你網頁相對路徑發生偏差。

當然還有其他原因。而面對這個問題的解法，傳統上是在 web.config 或 web.xml 裡面去定義一個類似 HOST_URL 的參數來解決。但缺點是，每次 deploy 時，就得變更 HOST_URL 的設定，除了顯得不便之外，因會增加 API 與環境變數的相依性，實在不能算是很好的做法。因此透過程式自動抓取 ContextURL 的作法，便有其必要。

現在，我們假設我們的 ContextURL 就是以上的形式，而不是 WebServer 的根目錄 (例如 http://test.com:8080/)，那麼取得 Context URL 的作法，在一般情況下並不難。首先看看 ASP.NET/C# 版本：

   int idx = Request.Url.AbsoluteUri.IndexOf(Request.ApplicationPath);
   string serviceUri = Request.Url.AbsoluteUri.Substring(0, idx); // 伺服器 URL
   string applicationUri = serviceUri + Request.ApplicationPath; // 應用程式 Context URL

JSP/Java 版本如下：

   int idx = request.getRequestURL().toString().indexOf(request.getContextPath());
   String serviceUri = request.getRequestURL().substring(0, idx); // 伺服器 URL
   String applicationUri = serviceUri + request.getContextPath(); // 應用程式 Context URL

不過有些情況比較特殊，例果透過某種 URL dispatch 的機制來存取網頁，你會發現用以上方式取得的 URL，與 Client 端發送的 URL 並不相同。我們以 IBM Tivoli Access Manager 為例，它的 URL 組成格式如下：

      http://sso.com/JUNCTION/AppContext/path/to/your/page

• sso.com: 是一個用來作 singal sign-on 的網站
• JUNCTION: 用來試別要將 client 端 request dispatch 到後端哪個實發處理的網站
• /AppContext/path/to/your/page: 後端處理要求的網頁或程式，實際位址可能是 http://192.168.1.111:8080 /AppContext/path/to/your/page 之類的。

也就是說，當 Client 端發送 http://sso.com/JUNCTION/AppContext/path/to/your/page 這個請求時，經過 Tivoli Access Manager 轉送後，Server 端實際取得的服務位址是 http://192.168.1.111:8080/AppContext/path/to/your/page。

為了解決這個問題，我們需要動用到 HTTP Header 裡面的一個參數 -- referer。referer 是指目前存取這個網頁，是透過哪個網頁連結過來的。有了這層認識，我們可以將上面的程式碼改成如下。 ASP.NET/C# 版本：

   if(IsPostBack) {
      idx = Request.UrlReferrer.AbsoluteUri.IndexOf(Request.ApplicationPath);
      serviceUri = Request.UrlReferrer.AbsoluteUri.Substring(0, idx); // 伺服器 URL
      applicationUri = serviceUri + Request.ApplicationPath; // 應用程式 Context URL
   }

JSP/Java 版本如下：

   if(request.getParameter("IsPostBack").equals("true")){
      idx = request.getHeader("referer").indexOf(request.getContextPath());
      serviceUri = request.getHeader("referer").substring(0, idx); // 伺服器 URL
      applicationUri = serviceUri + request.getContextPath(); // 應用程式 Context URL
   }

如果你是直接在瀏覽器的網址列輸入 URL，或是點選書籤/我的最愛直接連結，那 referer 的值會是 null。因此，我們可以透過檢查這個網頁是否是 post back 網頁，來確保 referer 有值。注意一下，JSP 裡面並沒有預設的 IsPostBack 檢查機制，你要自己做。

另外，有些防火牆或防毒軟體也可能會改寫 Client 端發出的 referer，使得 Server 上取得的值為 null。若是這種情況，可以試著透過 client 端的 Javascript，取得 document.location.href 的值，將它指定給某個隱藏表單欄位，在 post 時傳給 Server 端來加以解決。

使用 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 轉譯碼… 這樣的設計，或許可以解釋為：「為親自造訪本站的讀者，所提供的一點加值服務 ^__^」。

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

iGoogle 與 Google Reader 裡的 RSS 訂閱

之前看到有人在「訐譙(ㄐ｜ㄝˊ ㄑ｜ㄠˊ)」Google 把預設的 RSS 訂閱導到 iGoogle 去，有人說是版本有差，有人說是已改了回來。我的 firefox 則是到現在還是這個樣：只會導到 iGoogle 去。

雖然我也是 iGoogle 的愛用者，但是想放到 Google Reader 裡去細細品嚐的資訊，真的跟想放在 iGoogle 上的資訊不太一樣。強迫用戶只能接受 Google 的指定，未必合理。不過若是做個瀨尿牛丸，真正的把 iGoogle 跟 Google Reader 訂閱做進一步整合，也是可能的解法。

我的想法是，既然放在 iGoogle 上的 google bookmark 會在 google bookmark manager 內被自動置入 homepage folder，那何不如法泡製，將加入 iGoogle 個人化首頁的 feed，也自動放在 Google Reader 內的 homepage folder 中。如果用戶已在 iGoogle 內加入分頁標籤，那更可用頁籤名稱作為 Google Reader 內的 folder 名稱。

另外，在 iGoogle 內閱讀 RSS 文章時，如果也可以選擇將文章開啟在 Google Reader 中，那種感覺也是挺不賴的!

我的一點 Thunderbird 使用訣竅

自從進入目前公司後，我便一直以 Thunderbird 作為我的 email client，算算時間也三年半以上。這一路走來，我發展了許多 Tunderbird 的應用密技，我想有許多可能是別人沒想過要這樣用的，特別發表出來，與各位分享。

(一) 利用 Message Filter, 將所有不在 Personal Address Book 中的來信，全部移到 Junk 信件夾

因為垃圾信實在太多，只好使出這招釜底抽薪的方式。如果是業務、專案上的初次來信，通常事先會透過電話連絡。此時只要手動自 Junk 中移回 Inbox，再將寄件人加入 Address Book，下次即不會再跑到 Junk box 中。

(二) 快速安裝 extension 的方式

在 https://addons.mozilla.org/thunderbird/ 裡面找到所要安裝的 extensions 後, 在網頁的 Install Now 按鈕上選右鍵，選 "複製連結網址"。然後打開 Thunderbird  的 Add-ons 管理員，按 Install，在 Select an extension to install 檔案對話窗中，在檔名文字欄位按 Ctrl+V 貼上 extension URL，再按下開啟，就會進行安裝程序。

(三) 用 7-zip 來修改 extension 的安裝資訊

如果你也是嚐鮮一族，已在使用 Thunderbird 2.0，那麼你將遭遇最大的問題極可能是 extension 版本的不支援。如果你願意碰碰運氣，可採用下面這種作法：

1. 以 7-zip 開啟 extension 的 xpi 或 jar 檔案
2. 在壓縮檔案的 install.rdf 按右鍵選編輯
3. 7-zip 會以你設定的編輯器開啟 install.rdf，找到類似以下這一段，將其中的 em:maxVersion 元素值調整到你的 Thunderbird 版本以上，例如 2.*，然後存檔，關閉編輯器

       
           
                {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
                1.0
                1.5.*
           
       

4. 7-zip 將提示你檔案已被修改過，是否要更新壓縮檔之訊息，請選擇確定，然後重新安裝 extension 即可。

(四) 用 Plaxo 同步通訊錄

不曉得你有沒有因為重灌電腦而遺失通訊錄的經驗呢？重灌電腦時，我通常會記得備份信件，但是聯絡人卻老是因忘了備份通訊錄而流失。

Plaxo 是一個線上服務，提供通訊錄、行程、作業及記事管理等諸多功能。對於 Thunderbird 而言，最實用的地方在於它提供通訊錄同步的 extension。我把 Plaxo 當成是我的通訊錄管理員，因為它支援了匯整、備份、同步聯絡人的功能：

• 匯整：我把 MSN、Yahoo!、GMail 上所有的連絡人全數匯入 Plaxo 中
• 備份：經上述匯整後，Plaxo 成為我唯一一個需要維護通訊錄的地方。因為在資料存在 Server 上，只在 Plaxo 還在，我永遠不怕通訊錄再次流失
• 同步：因為使用多台電腦，而且我在不同的地方都裝有 Thunderbird，我可以透過 Plaxo 同步不同機器上的連絡人

在 Thunderbird 2.0 上安裝 Plaxo，由於 Plaxo Thunderbird Extension 目前只支援到 Thunderbird 1.5，所以請用前述的方法以 7-zip 來修改 extension 的安裝資訊。另外，個人覺得 Plaxo Toolbar 的設計極醜。若要隱藏 Plaxo Toolbar，可在選單列上選擇 PlaxoPreferences，將 Plaxo Preferences 對話窗中的 Show Toolbar check box 取消即可。

(五) 使用 Duplicate Contacts Manager 移除重複連絡人

當我使用 Plaxo 合併 MSN、Yahoo!、GMail 上的連絡人時，常會造成連絡人重複。透過 Duplicate Contacts Manager 這個 extension，可以快速找出重複聯絡人，並選擇保留與移除的項目。在移除重複連絡人後，從選單列執行 PlaxoSync，你會發現 Plaxo 通訊錄裡面重複的連絡人也被移除了。

(六) 將寄件備份與收件資料夾合併

我將寄件備份放在 Sent 信件夾中，Inbox 用來保留最新的信件。每隔一段時間，我會將 Inbox 裡的信件移到 Sent 信件夾。如此，在 Sent 資料夾中採用 Thread 模式檢視時，我獲得一個類似 GMail 的 Message Thread 介面，可以很方便的看到發信與回信的脈胳。

(七) 將老舊的信件移存到不同的信件夾中

將較老舊的信件，以年為單位封存到不同的信件夾之中，可以避免掉 Thunderbird 同一信件夾不得大於 4G 的限制。

(八) 使用 Remove Duplicate Messages 移除重複信件

有時在不同的信件夾間複製或移動信件後，會造成同一資料夾內信件重複的狀況。使用 Remove Duplicate Messages 這個 extension，可以快速的刪除重複的信件。在信件刪除完畢後，別忘了在該資料夾上執行 Compact，如此才能真正的減少信件檔案的儲存空間。

(九) 善用 To(收件人) 或 Subject 信件表頭欄位分類信件
我知道 Thunderbird 2.0 已正式加入對 Tag 的支援。但是我所採用的方式，不但適用於 Thunderbird 1.x，而且比之 Tag 的操作更為簡易。作法很簡單：在編輯新信時，我會把 To 欄位拿來輸入分類關鍵字，我稱為 To tags。例如，這篇 blog 就是在 Thunderbird 中編寫的。我將此信件的 To 欄位分別加上 blog, note, thunderbird 三行。如果是內收信件，就需要 TB Header Tools Extension 這樣的 extension 才能更改信件表頭。對於內收信件，我通常會透過修改 Subject 的方式，來分類信件，如 [Project:Company].... 這樣的格式。

(十) 善用 Search  Folder  建立分類檢視

Draft 信件夾原本放置外寄信件的草稿，在我為信件加上 To tags 後，它變成個人記事資料夾。我進一步為 Draft 信件夾建立各種查詢條件的 Search  Folder 來設定分類檢視。例如我有個 Search  Folder 名為 "部落記事"，其查詢條件為 "to Contains blog"；另有個 "生活記事" 則對應為 "to Contains diary"。當然，透過 Search Folder 可建立更複雜的查詢條件。

同樣的，專案的分類檢視也可透過建立 Search Folder 為之，只是查詢條件會變成 "subject Contains Project:Company" 這樣的型式。

(11) 拿 Drafts 信件夾當記事薄

之所以拿 Drafts 信件夾當記事薄，而非別的信件夾的原因是：預設 Thunderbird 所有新信存檔時都會存放在 Drafts 信件夾中。你可以在 Drafts 信件夾重複編輯信件，而不用擔心它會跑到別處。要 Tag 分類的功能，可用上述的 To tags；要樹狀分類的功能，則可用 Subfolder 結合 Search Folder。

當初會想用 Thunderbird 來做記事管理，另一個原因是它的 Rich Editor 功能實在做的太好。而信件又可夾帶附檔，加入圖片。再說，除非你只用 Web Mail，否則電腦裡極可能需要一套 email client，既是如此，那何不就把它的應用效益最大化，這樣又少了需要另外安裝記事軟體的需求。