Jserv's blog: December 2006 彙整

偉哉！Qtopia 4.2

Trolltech 推出 [Greenphone] 時，曾表示將會推出以 GPLv2 授權的 Qtopia 4.2，屆時將 Phone edition 一併公開，如今，Trolltech 做到了，請參閱新聞稿 LinuxDevices - [Trolltech rev's Linux device UI stacks]。以往的 Qtopia GPL version 只有 PDA edition 的功能，而在 Qtopia 2.1 以後，Phone/PDA edition 的差異越來越大，導致許多 ISVs (Independent Software Vendor) 無法在未支付 NRE 相關費用的前提，進行軟體開發，這是相當可惜的事情，不過，現在已經改觀。

Qtopia 4.2 GPL 版本已經附上 Phone server，同時也納入 Wifi / VoIP 的支援，除了 DRM 與 telephony 元件外，其餘都以 GNU GPLv2 釋出，同時引入 RealNetworks Helix DNA 的軟體建設，使得 Qtopia 有強大的多媒體支援，更重要的是，在 devices/ 目錄下，提供許多 reference design，如：

greenphone
omap730
pxa27x
s3c24a0
x86_gcc4
zylonite

以往總是得花上一段時間移植若干低技術性但枯燥的細節，比方說 Keypad 與 Touchpanel，現在 Trolltech 作掉了大部分的工作，應該可讓工程師的壽命長一些。去年年初提到的 [Qt4 初體驗] 種種強大功能如今可在 Embedded devices 上現身，而且更有效率。在 IPC 與 system services 的部份，Qtopia 4 採用 D-Bus，相對於 Qtopia 2.x，提出 Power Management、VPN、data storage、... 的加強。我做了一份 mirror 放在台大的伺服器上：

[qtopia-opensource-src-4.2.0.tar.gz] - Qtopia/GPL 4.2.0 - 87.1 Mb
[qtopia-core-opensource-src-4.2.2.tar.gz] - Qtopia Core GPL 4.2.2 - 56.4 Mb

由 jserv 發表於 01:12 PM | 迴響 (2)

等待新漢碼－漢字的數位化與中華文化的衝擊

[阿江] 前輩日前在中研院 OpenFoundry 電子報發表了一系列名為「等待新漢碼－漢字的數位化與中華文化的衝擊」的文章，採用 Creative Commons「姓名標示 2.5 台灣」方式釋出，鞭辟入裡指出，在這電子數位時代，我們的語文系統潛在的危機與新願景，全文張貼如下：

[名家專欄] 等待新漢碼－漢字的數位化與中華文化的衝擊
陳昌江/文 2006/09 （感謝張正一等人協助校稿）

◎ 前言

一百多年來，中華民族在優勢的外來文明衝擊下，人民普遍喪失民族自信心，不僅使得中國傳統文化成了代罪羔羊，也使其更新的腳步停滯不前，無法受到應有的重視與發展。最無奈的是，許多中華文化的寶貴資產，就在這樣的時代大洪流中無聲無息流失！

今天，兩岸的大漢民族普遍都富足了，然而這種文化上的自卑，仍然存在著。所以當下重要工作就是促成中華文化的更新與再興。漢字是中華文化的根本材料，其影響無所不在，因此漢字的數位化工程，也就成了中華文化進化到數位時代的重要基礎工程。

漢字數位化工程中最基本的就是漢字表達的基礎結構。漢字數位架構的良窳，深深地影響到中文資料儲存成本、交換成本以及檢索效能等，也關係著中華文化的傳承與創新的能力。

◎ 漢字資訊的五大要素

自古漢字就由「形、音、義」三個要素所構成，在資訊時代則必需加上「碼」和「序」二個要素。

「碼」是電腦認定一個漢字的一個相對數字，通稱為「字碼」，所有的電腦的資料處理、資料交換都是針對「字碼」進行認定和處理。

「序」係人類認知的排列方式。由於有查找排序和比對等資料處理的需要，一個自然、共同認定的「字序」是一個文字系統重要而有價值的本質。以查字典為例，查英文字典是簡單方便且準確，但查漢字字典就很不確定，這種問題相信你一定能感受到，這是因為漢字還沒有確定字序的緣故。

◎ 當前的漢字資訊表達的情況

一、形
漢字字形的產生主要有點陣字和向量字兩種：

（一）點陣字形
點陣字對電腦來說其實是一種「字圖」，就是在有筆畫的地方描上細細的點。點陣字的好處就是處理簡單，缺點就是每一種尺寸都需要一套點陣資料，因為一個點陣字就是一張圖片，且資料量與字形的大小成等比級數上升，字形變大，資料量快速變大。這使得記憶體受限的小型數位裝置所能提供的字形就非常有限。

另一方面，要從這點陣資料圖中取得有關這個字形的特徵資訊不多，因此，除了進行高級的影像處理外，點陣資料的進階處理並不容易。

（二）向量字形
向量字則是只記錄各筆畫內容的位置、長度寬度等字形資料，而在最後展現時，才由電腦轉換成點陣圖來呈現。

向量字的發展主要為解決點陣字資料量龐大的問題。但向量字形在呈現成點陣時所需要的轉換非常複雜，目前在機能不夠強大的數位設備上仍不易實現。

二、音
由於漢字是一種形意文字，與音韻並無緊密的連結，加上古今漢語音韻之變遷，形和音的對映是多對多的（多字同音，一字多音），其中字音可以簡單地用建表的方式解決。但如果要處理破音和語境問題，就涉及自然語言處理的範疇，這方面學術單位已有相當多的有關研究。

三、義
形是義的視覺介面，音是義的聽覺介面，有形無音，稱為「符號」，有音無形，叫作「語言」，只有同時具備形、音兩要素，才構成文字。

四、碼
中文在資訊時代的第一個挑戰是「編碼」，也就是為每一個漢字編上一個數字碼。一個漢字被編上一個對應的字碼，就無法進行數位化處理，也等於「不存在」在數位世界中，甚至會造成世界上「沒有這件事」的假象。

碼可分為「內碼」和「輸入碼」兩種，內碼是中文字的數位代碼，是方便電腦處理的代碼，人無法記憶，因此才衍生了各種方便人記憶或辨識的輸入法來產生相應的內碼，輸入碼主要是針對輸入漢字的人機介面，也是人和機器溝通時的中介表達方式。

（一）內碼
內碼的主要考量是軟體的相容性、儲存的效率和程式處理的簡易性，因為在這數位世界中，漢字字碼是無所不在的，因此漢字的處理成本，這也就成了無所不在的成本負擔。

在早期電腦的文字模式 (text mode) 時代，為了遷就 ASCII 碼表，故有 Big5、GB、 JIS 等雙字元（一個字元就是一個 BYTE，一個 BYTE＝ 8位元，雙字元＝ 16 位元）的設計。然而，電腦進入圖形模式的現在，字形在螢幕上的顯示，已不再限定為固定寬度，加上當今電腦的容量與速度，因此對於實際儲存的字元數以及運算的複雜度已經不在，讓是中文內碼的設計上有了很大的自由度。

目前電腦平台上涵蓋面最廣、最成功的內碼 Unicode（統一碼），已經成為當今 Windows、Mac 及 Unix-like 等主流平台的內碼，因此 Unicode 事實上已取代 ASCII 、Big5、GBK 碼，成為各作業系統的預設編碼，並漸漸地成為國際間交換資料時主要的交換碼。

（二）輸入碼
輸入碼可分為「拆形」和「拼音」兩大類。「電腦中文化」的歷程就是利用英文電腦的鍵盤，編上部首和注音的映對鍵位。然而中文部首的數目遠遠超過了鍵盤的鍵數（「康熙字典」的基本部首有 224 個），因此就必須在有限的鍵盤上，用一個鍵對應多個部首的方式來輸入。

由於這些分解動作，都加入了人為指定與巧思，並非來自文字的本質，因此需要很多的學習和記憶，對漢字使用者無疑是建立了一個很大的門檻。現在社會上還有很多人「不會電腦」，其實大部分都是「不會輸入」的意思。這種現象不僅在大人的世界發生，在兒童方面，也因為這個緣故，在電腦的啟蒙時間也被延後了，這使得華文的小孩在電腦應用與普及上與英語世界相較，有輸在起跑點的無奈。

◎ 一字一碼的時代困境

我們必須深刻地覺悟到，承載中文資訊的中文碼，其設計對「數位中華」的影響是既深且遠的，不深入觀察分析，大家也習以為常，難以發現它無所不在的影響以及其嚴肅性。就以康熙字典為例，一萬多字的 BIG5 碼是做不出有四萬多字的康熙字典的。

為了讓你發現這些在我們數位生活中存在的諸多無奈事實，且讓我們來分析觀察英文字 (word) 的結構。

首先我們來看字序的問題。我們都知道，英文碼的基本定義是 0～127 的 ASCII 碼，其中有 "A～Z"、"a～z" 的 52 個「英文字母」 (character)，其餘為字符碼及控制碼。由 ASCII 碼的英文字母所構成有意義語素是 word，我們就以「英文字」稱之。各位請注意到，英文字循著 ABC 的排序，就有了一個自然的、本質的排序。

在此基石之上，舉凡字典的安排、資料庫的製作、物料的列舉、二元搜尋 (binary search) 的方法、鍵盤的設計、作業系統表單的設計、快捷鍵 (HOT KEY) 的安排等，無不存在這 ASCII 編碼的基本設想，可是中文字卻沒有這個序，只要稍微有中文處理經驗的人，便可以知道，資料欄位沒有確定的排序，電話簿中的人名沒有確定的排序！

為了這樣的緣故，中文資料總是要另外自行設代碼或編號欄位等，以方便處理。相對於英文，中文的資料處理，便增加了一層無所不在的額外成本。

一、發現潛藏在當今「一字一碼」架構中的意義

現在，再讓我們來看看當今中文字一字一碼的問題。

為了讓讀者發現這些潛藏在文字架構中影響力，讓我們來考慮下面的文字假設情況：

如果，我們把 ASCII碼拿掉，改用一個英文字也像中文一樣一字一碼，那麼將會是個怎樣的景象？

我們先假設下列英文字都有了內碼：

      PERSONAL   內碼是 $FF3A 
      CENTRAL    內碼是 $BB01 
      PROCESSING 內碼是 $FF3B 
      UNIT       內碼是 $FF3C 
      MACHINE    內碼是 $CC01 
      COMPUTING  內碼是 $DD02

那麼 COMPUTING MACHINE（內碼為 $DD02 $CC01）就沒有機會因為它的重要性日增而改稱 COMPUTER。請注意：因為沒有 "COMPUTER" 這個內碼，如果要，就要經過標準機構公佈新碼才會存在！

好！假設真有那麼一天，「標準機構」「收錄」了 COMPUTER 這個新字：

COMPUTER 擴充新內碼是$AA01

一樣的問題又來了，在有了 "COMPUTER" 這個新字碼之後，PERSONAL COMPUTER（內碼 $FF3A $AA01）仍不能馬上改稱 PC，因為還沒有定下 "PC" 這個字碼！

同樣地，中央處理單元 CENTRAL PROCESSOING UNIT（內碼$BB01 $FF3B $FF3C）更不會簡稱 CPU了，因為如果英文字也是像中文一字一碼的話，也就沒有機會新創 "CPU" 這個字了。

當然這是個假設性的探索，英文文字事實上可以自然地隨著時代的需要「進化」，這可是關乎到一個文化的根本活力。

然而，這卻也正是這些年來，一字一碼的中文所經歷的過程。

諸位一定可以體會到，所謂的一字一碼，就是拿處理「英文字」(word) 的方式來處理中文字，這是一個耗時費力而不切實際的過程！

然而，我們更需要嚴肅看待是這樣的困局所引發的嚴重後果：

漢字停止演化！只因為在一字一碼的架構中，要增加一個新字，是一個令人無法承受的夢魘！

讀者是否可以看出來，當一字定成一碼的時候，由於是人為指定，於是一個新字必須經過標準機構的公佈才有可能流通和使用，然而即便一個新字已經公佈了，無數已經在運行的系統又如何去更新呢？所以，這是成本非常高、過程複雜且時間漫長的過程！其真正的結果就是「停止造新字！」，這就是這幾十年漢字僵化的景況。

於是，當今的一字一碼架構也就成了漢文字生機的死胡同！很無奈地，這卻是當今漢字數位化所存在的事實困局！

二、沈重的一字一碼

雖然現在這種人為的一字一碼並不是完全地不可行，問題就在必須每隔一段時間以人工審議的方式追加新字碼，而在字碼尚未公佈前，中文數位資料的轉換、交換、搜尋比對都是不可能的，更別說是無法輸入和無法印出這樣的基本動作了。以佛教經典來舉例，佛教典籍有龐大數量古字未被編碼，早期佛教界做了許多典籍的輸入，雖然耗費龐大的人力物力來造字，至今卻仍是難以流通，但今天要全面的更新既有的系統又談何容易！

既使在新標準公佈之後，由於許多已存在多年的系統無法隨著更新，要能全面地交換、搜尋和比對，仍然是一條漫漫長路，更別提 UNICODE 到 2006 年已經公佈的七萬多個漢字，表面上好像是解決了缺字的問題，但卻也是一個龐大的系統負擔（2006 年 Windows XP 大部分的字型也只放了兩萬字）。因此，這些漢字只是「存在」但並非常用，這不僅是小型資訊設備無法承受記憶體的消耗（相較於英文文字系統是非常的龐大），就連我們在輸入時，也無法忍受輸入時每次從上百個字中挑選你要的字。

由於 BIG5、GBK、UNICODE 等幾個主要中文碼一樣都是這種一字一碼的架構，所以皆面臨相同的困境。

因此，我要說「人為指定的一字一碼是漢字數位化進程中的歷史錯誤！」。

三、中文在一字一碼的架構下固化了

我們中文漢字在每字指定一碼的架構下，「以筆書寫，自由創造」的漢字本來生命力不見了，因為這漢字在數位世界中「固化」了！

這樣的固化現象是無所不在的，其效應也是無聲無息地不易被察覺的。為了更具體的剖析說明這種失去活力的「固化」過程，這裡再舉幾個例子來加以說明。

百年來，對人類非常重要的日常用具──電燈，按倉頡以來中文形聲造字的法則，最終應是進化為「電登」這個「字」（注意「電」「登」兩個部首併寫成一個漢字，因為「現在電腦還沒這個字碼」，所以這裡無法顯示）（這個新字應是唸做「登」）。

想一想，當電燈剛出現時，中國仍處於油燈的時代，借用火旁油燈的「燈」再加上一個電字來修飾當時的燈字。另外，像網際網路（互聯網）更已經是這數位時代生活密不可分的一部分，按倉頡造字進化的原理，它的新字應該是「互罔」，這便是一個文字活力成長的機制。

近幾十年，我小時候的油燈現在已幾乎看不到了，「電燈」普及了，我們已經不需要再說「開電燈」「關電燈」來與油燈分別，而直接說「開燈」「關燈」，這是語言本身隨著生活時代不斷演進的例子。你只要仔細觀察，這種例子俯拾皆是。

其實，這個新時代新增的字很多，像 MODEM 這個英文字便是從 "MODulation and DEModulation" 複合而成，然而，由於目前中文碼是「一字一碼」，因此這個「調變解調機」（或用「數據機」簡化）就被「困住」了，只因為中文沒有字碼也「不容易」另定字碼！

這都是因為現在使用的是一字一碼的定碼機制，我們所能做的，就只是用現有的字碼來組新詞，無法造新字！儘管時代不斷地演化，重要用品和概念不斷地出現，我們卻無法進一步跟著簡化。

於是，英文字在進化，中文字卻僵在原處！

四、中文在一字一碼的架構下僵住了

在這個案例中，中文僵住了！OK，也許會有人說，「中文僵住了又怎樣？日子還不是一樣在過？」

當然，在 BIG5 時，用電腦、打手機簡訊也都可以啊！沒錯，但是，其結果就是下面的光景在不知不覺中大量普遍地在進行著：

以「中央處理器」和 "CPU" 為例，許多人在生活中、文章中會不知不覺地會直接用 "CPU" 而放棄寫冗長的「中央處理器」，真的，實在太累了，可是一用 CPU，就有許多小孩、老人和那些非資訊背景的人不知道意思了！（像 ADSL、MODEM 這種字也都是一樣的情形）。

而這樣的情況不只是發生在資訊界，也同樣發生在學術、工程、科學、醫療、農業、生物、經濟、管理…等等所有進化中的領域。這樣的情況越久，中文所不能表達（或因不實用而被棄置不用）的字詞就會累積得更多，長久下去，中文就這樣無聲無息漸漸地與時代脫節，也就慢慢失去一個語言的實用性與優越性！

各位要覺悟到，這種漢字的困局，是漢字的使用者必須自己關心解決的問題，外人不會替你解決，UNICODE 不斷地編碼，只是在解決跨國市場全球化的需求而已，至於這架構的好壞，對漢字文化的未來衝擊，外人怎麼可能替我們認真的面對！

五、字碼在無聲無息無所不再地影響我們！

字碼的影響力是無聲無息的，無所不在的，我們在不知不覺中，受到這種基本機制所制約而不自知。

為了讓各位更清楚地看見中文碼對中文活力的影響，讓我們再舉下面的這些例子來觀察思考：

CPU 是電腦的心臟，在這個數位時代是如此的重要，所以常常被使用到。前面提到，大家寧可寫 "CPU" 而不用「中央處理器」，因為寫起來太冗長了。然而，換個角度，也是因為我們無法用「電心」（注意，這是一個漢字，因為 BIG5、GB、UNICODE 裡還沒有「指定」這個字，因為沒有這個字碼，所以也無法用電腦顯示）這是個極簡潔而恰當的新字。同樣的，就像英文可以把 Personal Computer 簡化成 "PC"，但中國人卻得永遠寫成「個人電腦」，難怪會有很多人直接寫 PC。另外像「光碟」這個數位時代的關鍵儲存裝置，因為沒有「光枼」這個字，所以只能用「光碟」，但「光枼」（這是一個字）就明顯比「光碟」兩個字來的有效率。（「電腦」的新「字」你一定馬上可以想得到如何寫了！停下來想一想，其實，字的演化是這麼自然而且簡單。）

再如英文 BIT 在電腦方面我們叫做「位元」或「比特」，BYTE 則譯做「位元組」或「字節」，但其實 BIT 的零一單位就是在易經八卦中的「爻」（音「姚」或唸成英譯的「必」也很好），而 8 個 BIT 叫「爻八」（一樣，要併寫成一個漢字，唸「拜」，再自然不過了），依此原則可以進一步造出 16BIT WORD，32 BIT WORD 的字，這樣的自然演化其實只是還給漢字本有的活力而已。

六、新中文碼的時代需求

我們需要一個能承載數位中文漢字的字碼架構。

前面的分析應該能讓你感受到，數位漢字碼若要能承載中華文化中的活力，就必須具有新字詞的演化架構，因為這個質素代表著數位漢字在中華文化中能繼續具有重組與創新能力，而這些本來就是傳統漢字既有的本質機能，並且也是一個文化要能繼續生存發展所需具備的。

這種獨特的構字能力，進一步來說，主要就是形聲造字法，這是漢字特質，也是漢字的活力和魅力所在。如果無法造新字，其結果就是迫使文辭變得冗長生硬，因而漸漸失去它的簡潔與優雅，減損了文字效率與實用價值，最後，終將面臨被更簡潔有效的文字系統所取代的命運。

漢字是把概念分類和發音濃縮到小小的方塊內，這種二維的表達，比一維的英文字串，承載了更豐富而精緻的資訊，實在是有效而理想的文字表達方式。我們只有找出漢字在數位世界中進化的活路，才能夠讓漢字繼續保持它的實用與優雅。

相較於英文，漢字的優點，其實俯拾皆是，這方面的探討很多，無庸贅述。在這裡僅舉一個簡單例來說：「鱐、鯦、鱞、魨、鰉、鱨、鱴、魦、鰇、鰗」，雖然你可能都沒見過，不過大概知道不是魚的名稱、就是跟魚有關係的事物，甚至已經可以想像，大概是屬哪一型的魚。有了魚的部首，「有邊讀邊，沒邊讀中間」，就算讀音不甚確定，也是八九不離十。反觀英文就沒這個好處，Tuna , crucian , salmon , bass, abalone , trout , scombroid，雖然都唸得出來，但沒有事先學過，根本看不出任何關連，恐怕只有魚類學者才能弄明白真正的義涵。

◎ 結語

自從英文電腦發展以來的這幾十年來，我們進行了一場「電腦中文化」的努力。然而，在電腦普遍使用的今天，事實上我們已經漸漸地從硬體與技術的限制中解放出來，整個資訊產業正從「硬體技術」主導的產業轉移到以「資料內容」為主導的產業。因此「電腦中文化」也進入了「中文電腦化」的新階段，我們要從中文的真正本質與需求來運用電腦，而不再遷就於電腦硬體與技術。

當今的字碼，不管是 BIG5、GBK、或 Unicode 都是人為指定的一字一碼架構，而使得數位化的漢字失去既有的生命力，不僅使得漢字變成一種僵化的文字，也使得漢字漸漸地降低了他的實用性。這樣的「歷史錯誤」是我們要嚴肅地重新審視的。

中文碼對一個數位中華文化的發展，其影響可說是既深且遠，並且是無所不在的。在這中華文化邁入數位新世紀當中，中文字碼的架構正從根從本地影響了我中華文化的未來，希望我們能及早發現這個議題的嚴肅意義，期能引發各界深思熟慮，尋求解決之道。

作者註：本篇文章希望讓大眾發現潛藏在我們生活中的字碼是如何地影響著我們中華文化的現在與未來。如果能獲得你的認同，歡迎轉載與拷貝，讓我們一起來等待新漢碼的未來。

關於作者：陳昌江，網名阿江，部落格；畢業於台灣科技大學電機系，曾任易符智慧科技董事長（易符科技從事 CPU及嵌入系統的開發其中也包括中文字形及其相關的中文造字系統），現為「剎那搜尋工坊」籌備處負責人，主要從事中文資料庫之搜尋及中文缺字之處理。

本文章參考易符智慧科技所發表「中文資訊的表達與易符無限字庫」，針對當今中文數位化之困局加以剖析闡述，文中許多觀念源於中央研究院謝清俊教授之啟發及葉健欣先生之導入，特此銘謝。全文依據創用CC「姓名標示 2.5 台灣」授權條款出版，授權條款之詳細內容，請參考此處。

PS: docs.google.com 有一份 [原稿]。

由 jserv 發表於 05:27 AM | 迴響 (15)

迴避 spam comment

今天 caleb 在 #dot 提到要輸入帳號密碼才能瀏覽 comment，這是昨天改的迴避 spam comment 的方式，當處理 comment 的 CGI 被呼叫時，瀏覽器會跳出要求認證的視窗，如下：

User Name 為："nospam"，而 Password 為："iamnotspam"，因為 spam 攻擊實在太嚴重，才會出此下策，造成您的不便，請多包涵，謝謝！

由 jserv 發表於 11:40 AM | 迴響 (5)

Qing 的「開放原始碼的回收與再利用」

日前，Qing 在 UbiSunrise 的讀書會分享 [開放原始碼的回收與再利用] 的主題，強調兩項程式設計師應該有的兩個能力與技巧：熟悉回收與再利用，非常好的分享，原始網址提供 PowerPoint 簡報下載，這裡再轉換 [PDF 格式]。

由 jserv 發表於 09:10 PM | 迴響 (0)

ZJWord - 類似 MS-Word 的多功能文書處理軟體

瞥見 [ 免費文字處理類辦公軟件：ZJWORD]，功能介紹讓我非常心動，所以就在 Windows XP 安裝了這個來自大陸浙江的軟體作品，執行畫面如下： (click to enlarge)

操作起來實在有種親切感，跟 [AbiWord] 根本就是同一個模子打出來的，看一下目錄結構：

 ZJWord$ find -type d
.
./dictionary
./AbiWord
./AbiWord/bin
./AbiWord/strings
./AbiWord/plugins
./templates
./clipart

也可以找到 AbiWord/bin/libAbiWord.dll，但是，[AbiWord] 授權方式為 GNU GPL，所以很明顯了，ZJWord「理論上」也該比照類似授權，不過我沒有找到 source code 或進一步的資料。看來 ZJWord 似乎對 Gtk+ 與 AbiWord 做了一定程度的修改，許多 UI 被挪移了，但 symbol 大致還找得到。

由 jserv 發表於 02:52 PM | 迴響 (1)

Design Patterns in Qt

這是我在接近五年前的翻譯短文，因為有網友來信指教，我決定整理一份 web 版本，首次發表於 SayYa BBS 站。

Published on The O'Reilly Network (http://www.oreillynet.com/) http://www.oreillynet.com/pub/a/onlamp/2002/01/10/designqt.html

Design Patterns in Qt
by Matthias Kalle Dalheimer, author of Programming with Qt, 2nd Edition
01/10/2002

繁體中文翻譯與修正潤飾：Jim Huang (黃敬群 / jserv)
Jan 18, 2002

所謂的 GoF 書《Design Patterns》(GoF 指由作者群 Erich Gamma、Richard Helm、Ralph Johnson，以及 John Vlissides 等「四人幫」) 對軟體工程發展具有相當的影響力，也因此，每個程式設計師都閱讀過這本大作，或至少宣稱閱讀過了。在本文，我將會探索在 Qt 程式設計中，Design Patterns 是如何應用的。

Design Patterns 是個與語言無關的描述一而再、再而三在程式設計中出現的慣用樣式 (Patterns)。其實沒有什麼新東西，Patterns 已經在這幾十年間被採用，但是 GoF 書則是大力強調如何描述 pattern 的標準化、給予常用的 pattern 命名，以便全世界的程式設計師都可以查閱，並且，最後開創讓開發者可以識別新 pattern 與彼此分享的新運動。這些命名已經在開發者間相當的普遍，以致於我們常常可以在雜誌看到如「如何以某個程式語言來實作 Observer」這類的專欄 -- 這意味著沒有必要額外去解釋 Observer 是一種在 GoF 書中規範的 patterns 的名稱。

先讓我們此時保留 pattern 的議題，轉向去思考完全不一樣的東西：C++ GUI toolkit Qt。Qt 是由挪威的 Trolltech 公司發展，在 Windows 與眾多 Unix 平台上都可運行 (也有 Apple Mac 的版本)。Qt 依循 single-source 典範 (paradigm)：一個由 Qt 撰寫的程式碼，可以在任何所支援的平台上被編譯與執行，而不需要修改原始程式碼。當然，在現實上，由於編譯器或開發平台本身的問題 (例如在 Win32 下需要更改 Make rules)，可能需要小幅度的更改，而且如果你想保持與平台無關的特性，也不能直接使用任何原生 (native) 的 API 功能呼叫。然而，Qt 仍然是個協助開發展撰寫可移植性 (portable) 軟體的良好工具。近年來，Qt 已經因為創造 KDE 這個 Unix 系統下免費而強大的桌面環境，而大獲好評。 Qt 擁有可擴充的參考文件，而程式設計師的參考手冊與開發資訊可透過我在 O'Reilly 出版的書籍《Programming with Qt, 2nd Edition》。

實地開發 Qt 程式時，你應該會遵循部份在 GoF 書中描述的 patterns，即使程式碼看起來可能與書中所示的不同。在這裡，我們將探討在 Qt 程式碼中常見的兩個 Patterns 並試圖找出對應於 GoF 書中的 Patterns。

Qt 擁有獨特的 signal & slot 概念，這是一個允許以軟體元件 (component) 為基礎程式設計的系統：軟體元件可以定義可以在某些狀況下發出 (emit) 的 signal 以及伴隨定義的參數，同時，軟體元件可以定義如同正常 C++ method、但卻由前置處理器所偽裝的 slot。signal 與 slot 在執行時期可以藉由 QObject::connect() 來作聯繫，而這 QObject 正是 Qt 的中樞。

讓我們看看這個小範例。典型的情況是提供一個 Push Button (像是 "OK" 這樣的標示) 等待按鍵以結束這個對話框 (dialog)。經過查閱 Qt 參考文件後，我們可以發現有 class QPushButton 與一個在被按下時會觸發的 clicked() signal。同時， class QDialog 擁有一個關閉對話框的 accept() / reject() slot。為了讓這兩者產生關聯，可以使用底下的程式碼：

  QObject::connect( myPushButton,
                    SIGNAL( clicked() ),
                    myDialog,
                    SLOT( accept() ) );

這意味著，當 push button 被按下時 (因此觸發 clicked() signal)，對話框的 slot accept() 就會被呼叫 (對話框因而被關閉)，至於這動作是如何發生的，在 Qt 文件裡詳細的描述過，不在本篇文章討論的範圍。

現在，我們回到 patterns 的討論議題上，在 GoF 書上描述一個稱作 Mediator* 的物件行為模式 (object-behavioral pattern) 如下：

這邊使用的例子正與 GoF 書中舉的 GUI 系統的對話框一樣，在書中介紹的 mediator 物件負責指揮協調在對話框中的一群物件，像是按鈕、選單、文字輸入欄，之間的互動，避免相互指涉；這群物件只認得 mediator，因此可降低互連數目。這正是我們在 Qt 所具有的特徵： QObject class 扮演著任何需要協調物件的仲裁者。在 GoF Mediator pattern 也引入 Colleagues class，當 Colleague 物件想與其他 Colleague 通訊時，得透過 Mediator 來間接進行，而在 Qt 中，這些可以是直接或間接繼承於 QObject 的 class，並且因此獲有 signal/slot 機制。

需要留意的是，GoF Mediator pattern 假設每個 Colleague 類別都知道他的 Mediator 物件，但這對 Qt 來說並非必要的，因此，Qt 能夠提供耦合性更低的途徑。當然，在 Qt 裡也是可以遵循原本 Mediator pattern，只需要透過建立特殊的 Mediator class -- 在其 constructor 中設定所有 Qt connection (譯註：此乃 Qt 程式設計之術語，表示兩個物件之間低耦合的鍵結行為，為避免用詞混淆，這裡保留原文) 並且在 destructor 中把 Colleague 的 connection 取消。

[譯注] 簡單的互動圖用來說明以上行為：

signal/slot 機制也是另一個 GoF pattern 的例證，Observer pattern，描述如下：

定義一對多的物件依存關係，讓物件狀態一有變動，就自動通知其他相依物件，以作對應的更新動作。我們可以考慮如此的狀況：每個 Qt signal 可能被多個 slot 所連結 (也可能是全部都沒有)，而每個 slot 也可能被許多 signal 所連結，所以，我們實際上擁有一個多對多的相依性存在，but one that is much easier to maintain that typical many-to-many-dependencies that involve direct invocations. (不知道要如何表達這種感覺，所以保留原文)

就剛剛的範例來說，咱們再度回顧對話框。按下 OK button 的動作常常不只是關閉對話框，而且還會依據對話欄內變更值，作應用程式狀態的更新 (但是 Cancel button 就只有關閉對話框的動作)。也有可能直接在對話框內作更新 (典型的例子是在使用者自訂的 slot)，有時候我們比較偏好讓應用程式自己更新，以避免暴露過多關於對話框的內部資料結構。(換句話說，這意味著對話框的結構必須暴露與開放給應用程式，這種是需要取捨 [譯註：考慮便利性與物件封裝性]) 更新的過程可在使用者定義的 slot 中完成，這裡，我們姑且稱為 updateState()，然後我們會參照 push button 的 clicked() signal (譯註：當然我們忽略底層視窗系統是如何轉送視窗與滑鼠事件，總之，我們可假設 Qt 會自動將底層事件觸發時，會分類並遞送 clicked() "signal" 表示如此的事件) 來建立以下兩個 connection：

  QObject::connect( myPushButton,
                    SIGNAL( clicked() ),
                    myDialog,
                    SLOT( accept() ) );

  QObject::connect( myPushButton,
                    SIGNAL( clicked() ),
                    myApplication,
                    SLOT( updateState() ) );

於是，這邊就有兩個物件：對話框物件與應用程式物件，這兩者都在觀察 (observing) button 的按擊。

[譯注] 上述的模型可以表示如下圖：

同樣的，你將可以在 Qt 程式設計內發現 GoF patterns，如 Singleton、Iterator、 Command，以及 Flyweight。
[譯註] 這篇文章是很好的出發點，若讀者覺得意猶未竟，可參閱 Bruce Perens' Open Source Series 出版的經典著作《An Introduction to Design Patterns in C++ with Qt 4》，探討最新的 Qt 4.x 核心設計中，涵蓋多少典型的 Design Patterns，同時該書也有一份 wiki [OopDocbookWiki]。

To conclude, the Design Patterns described in the GoF book also apply to Qt programming, which should not be surprising, given that Qt follows good software engineering practice--sometimes with an unusual syntax.

Matthias Kalle Dalheimer works as an independent author, translator and software consultant in Northern Germany, where he lives in a tiny village with his wife and son.

O'Reilly & Associates will soon release (January 2001) Programming with Qt, 2nd Edition.

oreillynet.com Copyright 2000 O'Reilly & Associates, Inc.

短文至此，也讓我想到翻譯前幾天，曾寫下以下札記：

Patterns in Qt?!

補充：

由 jserv 發表於 10:48 AM | 迴響 (1)

OSDC.tw 2007 Calls for Papers

[OSDC (Open Source Developer Conference)] 2007 即將來到，以下引述 [OSDC.tw 2007 徵稿] 的訊息：

詳細的 call for paper 方式請參見 [OSDC] 官方網站。又是一次很棒的研討會，如果有機會的話，我考慮分享 Realtime Linux 的開發經驗，到時候應該會準備一份 [jserv's lab] RT nanokernel 的展示或 pre-release，相關的資料可參照之前的 blog [簡報：Approaches to Realtime Linux] 與 [SA-RTL : Stand-Alone RTLinux]。

我想說明的概念是，在台灣，開發一個新的作業系統並非不切實際的工作，相反地，在銜接 Free / Open Source software 運動的巨變的同時，其中很重要的理念就是客製化與最佳化。Nanokernel / Hybrid-kernel 途徑的提出，就是針對應用需求，比方說進階能源管理，我們常需要新的系統架構，以配合台灣快速的 hardware system prototyping 能力，又，眾多 Realtime Linux 系統的提出，證明了我們可在符合特定需求的 Hard Realtime kernel 上面運作 Linux Kernel，對既有的 Linux 應用程式來說，修改的幅度也是相當低，所以，新的作業系統設計絕對有其價值，特別是 nanokernel / picokernel / hybrid-kernel / virtualization 等技術逐漸成熟的今日。

不過呢，這個提案又是極度冷門，還在想該如何表達。Anyway, see you later!

由 jserv 發表於 12:28 PM | 迴響 (10)

自我印列 ELF 簽名

[Jollen] 兄最近寫了不少 ELF 相關的文件，相當受益，作為「深入淺出 Hello World」系列演講的延伸資料相當合適，下次我會補進去。

在之前的演講提到 Linux Address space，我做了一張 slide： (click to enlarge)

當然，這是針對 IA32，我們可以看到 0x08048000 位址以上有兩個 segment，是 exec image 映射於記憶體空間的區域。hexdump 這個工具指定自訂印列格式，所以我寫了簡單的格式檔：

$ cat format 
"%04.4_ax  " 32/1 "%_p" "\n"

這個格式表示法為前面十六進位位址與 32 字元為一欄長度的可印列文字。然後隨便挑選一個 ELF 格式的執行檔，進行分析：

$ hexdump -f format elf | head
0000  .ELF........................4...
0020  0.......4. ...(.#. .....4...4...
0040  4...............................
0060  ................................
0080  ....@...@...............@...@...
00a0  @.......................T...T...
00c0  T.......................(...(...
00e0  (... ... ...........Q.td........
0100  ..................../lib/ld-linu
0120  x.so.2..............GNU.........

很明顯看到檔頭與 ELF 簽名字串，又我們可得知 exec image 0x0001 開始的三個 bytes 為 "ELF"，那我們能否在執行時期印列呢？於是我寫了以下小程式：

#include <unistd.h>

int main()
{
        write(1, 0x08048001, 3);
        return 0;
}

這裡要提的是 0x08048001，其算法就是 0x08048000 基底位址加上 0x0001。於是我們可見執行結果：

$ ./elf 
ELF

另一種方式是直接讀取 /proc/self/mem，在之前的 slides 展示過用 dd 直接輸出 linux-gate.so.1 的方式，不過剛剛發現在 Ubuntu feisty 上竟然失敗了：

$ uname -a
Linux venux 2.6.19-7-lowlatency #2 SMP Mon Dec 4 16:48:22 UTC 2006 i686 GNU/Linux
$ dd if=/proc/self/mem of=MEM bs=4096
dd: 正在讀取 「/proc/self/mem」: 輸入/輸出錯誤
0+0 records in
0+0 records out

頗詭異，有哪位好心的朋友能指點迷津呢？謝謝！

由 jserv 發表於 12:23 PM | 迴響 (2)

IRCConf - Xorg 嶄新的硬體加速與效能提昇機制 (續集)

之前的 blog [IRCConf - Xorg 嶄新的硬體加速與效能提昇機制] 提到 Debian@Taiwan 上一次的 [IRC Conference]，因為時間與內容的安排，所以本月份將安排續集，以下是相關資訊：

時間: Dec 27, 2006 (週三) 20:00-21:30
地點: #dot OFTC 請參考 IRC，注意「不是 FreeNode」
題目: Xorg 嶄新的硬體加速與效能提昇機制 (續集)
主講人: User:jserv
方式:
- 純文字介面 irc，UTF-8 編碼正體中文
- 自由發言、提問題
- 請勿使用注音文
大綱:
- 3D Rendering 與 DRI
  - 探索 3D Rendering 模型
  - 既有硬體加速機制
  - 迎向新紀元：Xgl 與 AIGLX
- 實做層面的效能提昇

詳情請見 wiki [IRCConf]，歡迎提問，並且多利用 IRC 討論，謝謝！

由 jserv 發表於 02:06 PM | 迴響 (3)

Qt4/ptrace-based Debugger

之前在 [深入淺出 Hello World Part I/II (台北場次)] 會場，lwhsu 跟我提及 [OllyDbg - 32-bit assembler level analysing debugger for Microsoft® Windows®] 這個強大的軟體，隔幾天在 Ubuntu 上用 wine 測試了很久，可惜該軟體花了太多動作在驗證 PE exec，所以沒機會使用到。

Evan Teran 以 Linux 的 ptrace API 為基礎，透過 Qt4 與 [ libdisasm - x86 Disassembler Library]，撰寫一個新的 binary debugger [EDB]，授權方式為 GNU GPLv2，功能相當不錯，可隨時 attach 既有的 process，一窺內部運作，以下是追蹤 gedit 執行的畫面： (click to enlarge)

恰好之前已經修改過 qemu，繼續思考是否能整合這個 debugger 進來，或許有機會在「深入淺出 Hello World - Part III」時作分析工具。

對了，因為大量使用 ptrace API，需要先行建立一份 symbol table，故，以我這裡的環境 (Ubuntu feisty development branch) 來說，採用 glibc 2.5，所以要執行以下操作：

$ ./make_symbolmap.sh /lib/libc-2.5.so > symbols/libc-2.5.so.map
$ ./make_symbolmap.sh /lib/ld-2.5.so > symbols/ld-2.5.so.map

同時也建議以 0.8.8 (含以上) 的版本，因為 symtab 的內部表示型態有調整過。

由 jserv 發表於 12:32 PM | 迴響 (0)

新設備購入

雖然我時常使用頗高檔的硬體設備，不過那些幾乎都是金主捐贈或商借的，前幾周去了新的光華商場，在來回許多店家後，終於買了一台新 PC，所以現在 [jserv's lab] 又多了新成員：

換了一個新的工作環境，木質地板感覺還不錯，在台北內湖有時運氣好可瞥見兩三個星宿，當然重點是這台新 PC，拉近一點看：

Processor

Type: Intel(R) Pentium(R) D CPU 3.00 GHz
Speed: 3000MHz
Count: 2

System Memory

Total: 2048Mb

明年 [jserv's lab] 的重點會擺在 virtualization / Realtime verification、embedded device simulation，以及 automation 等項目，有了這一台強大的 PC 肯定可派上用場，不過現在光是 Xen 的規劃就讓我想了兩週，硬體太好反而不敢惡搞。

由 jserv 發表於 03:10 PM | 迴響 (1)

使用 GNU 工具作為軟體開發基本工具

Tasuka 在 blog [ 使用 GNU 工具作為軟體開發基本工具 ] 分享了他所作的簡報，採用 Firefox/Mozilla XUL 格式，需要 Firefox 1.5+ 以播放：

Development with GNU Tools

非常用心且精美的簡報，編修也相當容易，直接點按 XUL 工具列的功能即可。內容包含 Linux/BSD 簡介、GNU 開發工具簡介、Linux 開發模式與其優勢等。

由 jserv 發表於 02:31 PM | 迴響 (1)

使用 coroutine 實做 user-level thread

Donald E. Knuth 的經典著作《The Art of Computer Programming》提到 coroutine 這個自 1960 年代即現身的多工實做技術，原理相當單純，在多數的文獻中會以 "yield" 來闡述，但不免令人困惑。coroutine 的 "yield" 是屬於程式語言層面，透過特定技巧或機制，讓原本循序執行的陳述指令，得以做出交錯執行的結果，而 multi-threading 的 "yield" 則偏重於系統層面 (如 CPU resource)，簡單來說，該如何一方面允許多 thread 並行，又能適當規劃個別單元對系統資源的使用。

拜讀 Simon Tatham 一篇經典文章 [Coroutines in C]，獲益良多，作者以 run-length decompression 為例，探討 coroutine 技巧可如何大幅改善原本的設計流程，如此的技巧遍及多種領域，像是知名的 SSH client PuTTY 就大量使用。

最佳的理解方式就是找個主題來驗證我們的認知，所以我試著在 Linux 上模擬一個 user-level thread system，以下是實做程式碼：

#include <stdio.h>                                                                                  
#include <unistd.h>

#define THREAD_INTERVAL 500
#define cr_start() \
        static
int __s = 0; \
        switch (__s) { \
          case 0:
#define cr_yield \
          { __s = __LINE__; \
            usleep(THREAD_INTERVAL); \
            return; \
          case __LINE__: ; \
          }
#define cr_end() \
        } __s = 0;
static int condition = 1;

static void user_thread_1()
{
        cr_start();

        for ( ; ; ) {
                /* do something */
                printf("Run %s\n", __FUNCTION__);
                cr_yield;
        }

        cr_end();
}

static void user_thread_2() 
{
        cr_start();

        for ( ; ; ) {
                if (condition) {
                        /* do something conditional */
                        printf("Run %s - (1)\n", __FUNCTION__);
                        cr_yield;
                }

                /* do something */
                printf("Run %s - (2)\n", __FUNCTION__);
                condition = !condition;
                cr_yield;
        }

        cr_end();
}

int main() 
{
        for ( ; ; ) {
                user_thread_1();
                user_thread_2();
        }
        return 0;
}

一般的 function/method invocation 是 context switching 的行為 (注意：這裡的 context switching 與作業系統的術語不直接對應，而是強調 stack-based operation)，而 coroutine 最重要的想法就是保持上一次的 context，所以常用的實做技巧就是透過 "generator" 來實現 coroutine 中對 "yield" 的認知："yield = context saver + jump"。由上面的程式碼列表可見，我們透過 C Macro 簡化細節以吻合 coroutine 的「表徵」，同時也可看到如此模擬出 thread scheduler 的行為，換言之，這是「合作式多工」的基礎概念。

以下為上述程式碼之執行結果：

$ ./user-thread
Run user_thread_1
Run user_thread_2 - (1)
Run user_thread_1
Run user_thread_2 - (2)
Run user_thread_1
Run user_thread_2 - (2)
Run user_thread_1
Run user_thread_2 - (1)
Run user_thread_1
Run user_thread_2 - (2)
Run user_thread_1
Run user_thread_2 - (2)
Run user_thread_1
Run user_thread_2 - (1)
...

而程式碼列表中的 usleep 則確保有機會透過 Ctrl-C 或互動式操作結束此程式，避免無謂的 busy-waiting。

由 jserv 發表於 01:23 PM | 迴響 (4)

新書廣告：次世代 Linux － Ubuntu 玩全手冊

記得高中住校的時候，身邊不僅沒有電腦，而且也常手頭拮据，但對 Linux/FreeBSD 有著濃厚的興趣，當時書店中技術廣泛的文件如 CLDP 印刷刊物等，就成為解饞最重要的寶物了，又，每次走到櫃台結帳，往往發現口袋空空如是也，所以不時攜帶鉛筆與筆記本，前往書店去「抄書」。十年後，憶及往事，相當懷念當時對於技術的「紮實學習」，一筆一劃烙印在心的細節，至今難忘，我想，今日願意在特定領域深耕，很大程度是受到那些優質文件的影響。

但十年前能參考的中文書籍實在很有限，除了以 CLE 作者群為名的印刷物外，我就只記得李建達的 FreeBSD 黑皮書，反觀今日，隨便去任何一家電腦圖書店走走，竟被其堆積成山的叢書所驚，也讓我突然想到以前讀過的一句話：「現代人能用的工具太多了，但唯一的問題是，沒有時間也沒有足夠的認知去駕馭那些工具」。

自 2004 年開始，Ubuntu GNU/Linux 延續 Debian 的嚴謹與強大套件支援，又廣泛加入易用性的新元素，至今已在入門、伺服器管理、桌上應用，甚至教育等範疇，獲得良好的表現，這些都是極佳的工具，但我們又遇到類似的問題：「沒有時間也沒有足夠的認知去駕馭那些工具」。很高興 DUCATI 與 dbtsai 兩位朋友著手撰寫《次世代Linux－Ubuntu玩全手冊》這新書，大幅縮減入門者的探索時間，以下是該書簡介：

「Linux 只適合用來作 Server」、「Linux 是給電腦高手用的」，相信不少人都有這一類的刻板印象。看完《次世代 Linux－ Ubuntu玩全手冊》，相信您對 Linux 的印象將會完全改觀。Ubuntu GNU/Linux 是近年來急速竄紅的 Linux distribution，以安裝容易、與商業作業系統相比毫不遜色的桌面環境，以及更新迅速著稱。本書屏除艱澀的理論說明，用最輕鬆有趣的方式，告訴您如何安裝系統、驅動程式，如何上網，如何在Linux 下執行 Windows 的應用程式，最棒的是，要在 Ubuntu 底下玩《魔獸世界》、《戰慄時空》也不是問題喔！當然，Linux強大的伺服器功能，本書也沒有省略，想要自己架個網站，與 PC/Mac OS X 分享檔案，架個防火牆防堵入侵，看完本書，這些工作也都能夠輕鬆完成。只要您對開放源碼懷抱熱情，在看完本書之後，相信您一定會對開放源碼的未來更有信心！作為本身推薦人，我必須說，這本書在許多細節必非盡善盡美，但絕對是本不錯的快速入門指引，而且可循著書中的建議作進一步學習，我想這是此書另一個重要精神。dbtsai 稍早已將編排過的大綱上線，請見：

[ CONTENTS / 目錄] (PDF 格式)
[ PREFACE / 推薦序] (PDF 格式)

過幾天在書架上應該就可瞥見本書的身影，Have Fun!

Update: 關於此書的更新資訊、勘誤表，以及相關的討論，請見 Ubutun@Taiwan 的官方討論區 [Ubuntu 中文書籍討論區]，感謝指教。

由 jserv 發表於 05:18 PM | 迴響 (6)

Jserv's blog

December 21, 2006

偉哉！Qtopia 4.2

等待新漢碼－漢字的數位化與中華文化的衝擊

December 20, 2006

迴避 spam comment

December 19, 2006

Qing 的「開放原始碼的回收與再利用」

ZJWord - 類似 MS-Word 的多功能文書處理軟體

Design Patterns in Qt

December 11, 2006

OSDC.tw 2007 Calls for Papers

December 10, 2006