星期四, 8月 31, 2006

昨天的實驗室會議

感覺起來,在昨天的 Lab Meeting 裡,報告的學弟被項老師罵得很慘。

這位學弟的所做的研究,是處理「明清到近代台灣行政區域沿革」,希望能夠建立模型與系統,來幫助(例如,進行一些簡單的推理)使用者檢索相關文件,並提供閱讀上的參考連結。

他這幾天相當認真,因此應該也期望能夠得到正面的回饋。可惜,老師才看了幾張投影片,問了幾個學弟無法精確回答的問題,就開始發飆了。

我猜老師是希望,學弟先努力地想好資料模型,讓系統不但能夠提供合適的功能,還能減輕日後資料維護的困難。因為手頭擁有的歷史資料,本身可能並不完備(缺乏某些時期的資料)、也可能不一致(資料的訊息產生衝突),因而日後應該需要慢慢補齊與更正。如果缺乏良好的模型,每次處理就可能都需要「重頭來過」,那麼處理起來就很令人沮喪了。

不過,我覺得老師昨天的詰問,似乎失去了準頭。雖然他所強調的重點是正確的,但是學弟所做的,其實也沒有偏離那些原則太遠。

然而,當我嘗試替學弟說明,並提到「模型與實作的差異」時,老師卻說「你們不要用那種憐憫的眼光看著我,好像我什麼都不懂似的...」。

我很確定自己並沒有「用憐憫的眼光看老師」。那老師為什麼會這樣說呢?我猜想,或許是因為老師心底深處,對於理論與實作之間的鴻溝,有著矛盾與不安。老師對於理論很在行,但是實作方面的經驗卻不是很充分。他聽多了「實作上會有 ... 困難」這樣的話,卻又無法分辨提出困難的人是否只是在推託搪塞,最後乾脆一竿子打翻一船人。

於是,情況就是:即使遭遇困難的人努力溝通,但因缺乏實際的經驗,老師怎樣也無法感受困難之處究竟在那兒。溝通本來就不是一件容易事,學生們又很難用精確的話語描述那些是心裡想的、那些是實際上做到的,因而就惹得老師不耐煩了。

那麼,模型與實作之間,真的會有很大的差異嗎?有寶寶的人或許可以說,這就像是育兒書的內容,與實際帶小朋友長大之間,就是會不一樣、甚至「差很多」。

看育兒書,上相關網站看別人如何照顧寶寶、如何善用時間,這就類似於理解「模型、理論」。打理照顧大寶寶、到實驗室寫論文與修改程式、並抽空到月子中心陪太太,這就類似於「實作」。兩者之間的差異?因人因事因時因地而有不同。重點是,只看書了解理論,很容易低估「實際動手做」的困難處,而這或許就是所謂的「知易行難」吧。

星期二, 8月 29, 2006

樂觀

說來也頗奇妙,自己近來在許多地方似乎變得樂觀許多。

有人說,看到杯子裡剩下半杯的水,樂觀的人高興於還剩半杯,但悲觀的人會憂傷於只剩半杯。我從前確實會感傷消逝的部分,並一直惦念著剩下的半杯水;但最近回想起這個問題,卻發現自己似乎已漸漸接受少了半杯水的事實,並且感恩(雖然這聽起來像是宗教用詞)剩下的部分。

同樣的外在客觀條件,或許也會導致類似的外在行為(例如,珍惜這剩下來的半杯水),但中間微妙的不同處,就在於不同的心境。

心境的轉化,似乎無法強求。然而,憑藉著自己的本心,真誠地面對自己,時候到了,似乎就可以看見轉機,似乎就能夠超越過去的自己,達到另一層的高度,用另一種角度來看待這個世界與人生。

就自己來說,是什麼時候開始產生這樣微妙的變化呢?

我也不是很清楚。回想起來,應該是在這一年內閱讀了許多好書,並努力打開心靈的窗口,因而在潛移默化裡,讓自己有了這樣的轉變吧?

當然啦,抱持著懷疑論的角度,或許我這樣的自白,只不過是潛意識被「催眠」了,只不過是「自欺欺人」的一種表現。我的確無法確認自己是否「真的」變得樂觀許多,也無法確認自己是不是身處夢中。然而,我對那半杯水的感覺,卻那麼明顯地和從前有了不同,這真是奇妙啊。

星期一, 8月 28, 2006

從餵食母乳談起

我很喜歡看寶寶含著媽媽的乳頭,滿足地吃奶的模樣。那是種很難說清楚的奇妙感覺。

剛出生的嬰兒,幾乎所有時間都在睡覺。如果醒來了,不是因為尿布濕,就是因為肚子餓了想要喝奶。聽太太說,月子中心裡,似乎也只有她不願讓護士用湯匙或奶瓶餵寶寶,似乎也只有她夜半會起身來餵寶寶吃奶。

我想起數年前,在中興醫院的月子中心,我也只看到太太與另一位媽媽,會在夜半起身抱寶寶到哺乳室。雖說近年來,台灣也開始鼓勵媽媽們哺餵母乳,但或許是因為當今雙薪家庭多、或許是因為親自哺乳很辛苦(爸爸是無法代勞的),使用配方奶粉的媽媽佔了大多數。

寶寶每天大約要吃十次奶,每次大概要吃半個鐘頭。寶寶吃過奶後,太太還得用擠乳器把多餘的奶水擠出來(否則會溢出而弄髒衣服與床具),這樣又需要另外半個小時。扣除吃飯、泡盆的時間後,能夠睡覺休息的時間,當真也不多。

所以,產後的媽媽如果不能適當地宣洩鬱悶的心情,或許就容易有憂鬱傾向。我想,身為爸爸的人,是真的該多了解、體貼媽媽們的辛苦才好。

星期四, 8月 24, 2006

用 PHP 處理中文

用電腦處理中文,經常是件瑣碎又麻煩的事。

先前(例如,談古契書資料處理:之一)曾經提過,光是中文編碼,就有可能讓程式設計者忙昏頭又倍感沮喪。PHP 有一個「也算是令人感到麻煩」的地方,就是它的系統是被假設在 ISO-8859-1 編碼下運作的。

另一方面,現在「比較先進」的系統架構或程式語言,內部的編碼似乎都傾向於使用 Unicode(通常是 UTF-16,至於是大印地安 Big Endian 或者小印地安 Little Endian,則似乎還是涇渭分明,各有擁護者)。或許,有相當大的一部份原因,就是希望能夠減少程式的開發與維護時,處理各種編碼轉換的複雜性吧。

那麼,要用 PHP 來處理中文,該怎麼做呢?我想,程式設計者只能自己處理編碼的問題了。

好在 PHP 有提供轉碼的函式,使用上還算方便。一般來說,採用 UTF-16 或者 UTF-8 來處理字串,應該都是可行的。例如,假設我們的輸入與輸出字串都是以 BIG-5 的方式編碼,但是想要用 regular expression 找出字串中符合樣式的子字串,那該怎麼做呢?以下是一種方法:
<?php
mb_internal_encoding('UTF-16LE');
mb_regex_encoding('UTF-16LE');

function mb_utf16($s) {
return iconv('BIG-5', 'UTF-16LE', $s);
}

function utf16_to_big5($s) {
return iconv('UTF-16LE', 'BIG-5', $s);
}

$s = "雖然感覺上像是藉口,但實際上感覺的東西,很難說清楚。";
mb_ereg_search_init(mb_utf16($s), mb_utf16('感覺|藉口'));
while ($match = mb_ereg_search_regs()) {
print utf16_to_big5($match[0]) . "\n";
}
?>
它可以成功地比對出三個子字串:「感覺」、「藉口」、「感覺」。當然啦,如果要進行字串的取代,PHP 也提供了 mb_ereg_replace() 這樣的函式。

「麻煩囉唆」的地方,就在於必須反覆地呼叫 mb_utf16()utf16_to_big5() 這類函式,這讓程式(至少看起來)一下子變得複雜許多。只是,相較於物件導向的程式語言,經常需要建立一堆物件來處理(正規表達式的字串比對),我還是覺得 PHP 在使用上比較簡單些。

另外,值得一提的是,要在網路上找到使用 mb_ereg_serach_init()mb_ereg_search_regs() 的範例程式,竟然比想像中來得困難許多。因為不知道合適的查詢字串長得什麼樣貌,我只能混用這幾個關鍵字,加上 example、source code 之類的字彙來查詢。然而,用 Google 搜尋的結果,找到的幾乎都是 PHP manual 的內容 --- 而很不幸的是,目前 PHP manual 沒有列出使用的範例。

這或許也是搜尋引擎的限制:當多數網頁都含有「並非使用者想要」的類似內容,而搜尋引擎又認為這些網頁是「相關網頁」時,很容易讓使用者感到挫折。通常,解決的方式是將問題推給使用者,希望使用者能夠自己找到更合適的查詢字串。但問題是:使用者該怎樣做,才能找到合適的查詢字串呢?

星期一, 8月 21, 2006

生活雜感

雖然感覺上像是藉口,但實際上似乎又不是。

第二個寶寶出生了。太太去月子中心,我則儘量在家帶小傢伙。陪伴小孩子的時間過得相當快,轉眼幾天就過去了。清晨醒來才驚覺,這幾天都沒有看 New York Times,都沒有在早餐時間看書,都沒有在心裡掛念著一些想做該做的事。

我是還沒有到「一日不讀書言語無味,三日不讀書面目可憎」的地步,但時間過得如此迅速,心裡的感覺卻始終難以形容。帶點不安,有些徬徨,也感到迷惑。

古人四十而不惑,但自己呢?這一年來,看書比較有強烈感受的,幾乎都是與找尋自我有關。據說,能夠清楚地認識自我,就能夠活在當下,不以物喜,不以己悲。

雖然覺得這一年來,在人生的認識與態度上頗有長進,但還是會覺得「如果十年、二十年前就知道該如何讀書,知道人生該學些什麼、該怎樣去生活」,那有多好。但換個角度來說,光從這樣的感嘆,就可以知道,自己的修養還是差得多了。

帶小孩子的時光,雖然因為平凡而容易感到無趣,但有時卻是最溫暖美好的。小孩子,就是未來的希望。

星期五, 8月 18, 2006

迎接新生命的到來

貓和 Ankh 很機敏,知道我從網路上消失了幾天,是因為第二個寶寶出生了。

說實在的,這兩個星期真的過得很「充實」。先是行程緊湊的西雅圖研討會,接下來是忙於處理太太生產的相關雜事。

寶寶是 15 日凌晨出生的,轉眼三天就已經過去,必須辦理出院,轉到月子中心。雖然許多媽媽到月子中心,是希望能夠好好地休息一下,讓月子中心的護士幫忙照護寶寶,但為了讓寶寶更健康,為了更增添親自哺育的情感,我和太太都支持餵食母乳。

我真的覺得,當媽媽的人很辛苦。生寶寶時必須忍受痛楚;產後得復健,還必須每三個小時就起身餵一次奶。連夜半都得爬起來餵奶,如此怎能得到充分的休息呢?

而自從當上爸爸之後,我似乎更能體會到,天下父母心、「父母都希望小孩健康活潑」的那種微妙感覺。

也曾聽人家說,當上父母之後,人會變得更成熟。我想,在這裡「成熟」應該多少與人生、環境的認知有關。有了寶寶,就會事事替寶寶著想(而不僅只是顧著個人的感受),就會有愛(這裡「愛」是個動詞,表示對小孩做應該做的事情。為了讓小孩有自己豐富的人生,願意犧牲父母的一些個人利益,努力培養教育她)。

偶而有一些些空閒時間,還是會想要寫些感興趣的東西,想要整理 PHP Programming 的一些東西(很難說清楚目的是什麼,就先當成是想出一本書好了)。但照目前情形來看,這幾天恐怕還是僅能先想想,只能先處理一些比較簡單、比較獨立的部分。

哎,說的、想的總是比做的多。要能腳踏實地、亦步亦趨地實踐,還真不是件容易事呢。

星期一, 8月 14, 2006

西雅圖之行:回顧

這是相當充實的一趟短期旅程。

主要的目的,是參加小型的論文發表會議。由於某些因素,我並沒有計畫在西雅圖好好地玩上幾天。但也正是因為行程緊湊又難以妥善安排,讓我自己有機會能夠充分利用在西雅圖的三天時光,嘗試了數種交通工具。從坐機場巴士、搭市區公車、到自己租車,我的破英文在溝通上倒是發生了一些小趣事。

例如,搭機場巴士 (Grey Line Airporter) 到下榻旅館時,我問櫃臺服務的小姐,她卻表示沒有聽說過我住的那家旅館;我說我在網路上看到有轉乘 (Connector) 服務,可以接送到我住的那家旅館 (Quality Inn & Suites);她看了看電腦,就給我一張車票,然後嘰哩咕嚕說了一堆話。我沒聽懂,大約只理解到「從那個門走出去,...,一個大大黃色的東西 (a Big Yellow one)」,就拉著行李離開了。走了一段路,實在看不到什麼 Big Yellow one,只好再回去詢問那位有些年紀的女士。這回我記得詢問要在那條號碼線上等,才聽懂原來是她的意思,是「在 line 14 through 16 等候一台大大的黃色巴士」。

最後一天租車的情況也類似。我從櫃臺的先生那兒,隱約只理解到「右轉直走到 601 ... 搭電梯到六樓,那兒會有其他的服務員 ... 離開時需要這張票」。走出 Hertz,剛好門牌的號碼是六百多號,我以為 601 指的是門牌號碼,要到門牌 601 號處取車。結果門牌號碼 601 是一間辦公大樓,怎麼看都不對勁。再回租車櫃臺詢問,才知道是「右轉後進門可以看到電梯,搭到六樓後,在 601 停車格取車」。

在麥當勞點餐,也遇到類似的「有聽沒有懂」狀況。雖然知道點餐後,服務生都會詢問是否要在店內用餐(for here or to go,有時是 to go or for here),但倉促下往往沒聽懂,以為服務生是聽不懂我想點什麼,所以會重覆一次點餐的內容。後來學乖了,點了餐後自己加上「to go」或「for here」,才減少了應對上雞同鴨講的尷尬。

三天的行程裡,花在交通上的時間很多。其中,光是花在步行上的時間,加起來應該就有十幾個小時。西雅圖的氣溫相當涼爽,很適合走路。華盛頓大學的校園相當漂亮,走走逛逛,感覺也是很好。然而,由於在行車的路徑上事先沒有做太多功課,開車起來相當累人。西雅圖市區車輛眾多,且幾乎都是單行道;而停車費一小時大概都要美金 $1.50,又找不太到加油站休息。開車逛街一兩個小時,很快地就感到疲倦了。

最後,還是該記錄一下與 workshop 相關的一些感想。雖然自己的 paper 內容與 workshop 多數成員所關心的的主題間,似乎有著一段距離,但我還是取得一些與會成員的意見回饋。有人問說,有沒有考慮投到更相關的其他會議。有人(應該是 Doug Cutting 吧?)覺得論述 convincing,但詢問說,除了理論方面的探討外,是否有打算用實際的資料來做更深入地檢視。此外,Hugo Zaragoza 問了數個問題,也在休息時間的討論裡,說論文很好,內容相當有趣。(這兩位都跟 workshop 論文發表者比較無關;他們都是 workshop 最後 panel discussion 的 panelists。)

星期五, 8月 11, 2006

疲累的一天

今天是 workshop presentation 的日子。

時差不易調整,早上還是四點半就醒過來了。怎樣也睡不著,只好閉著眼睛儘量休息。

吃過早餐後,依照昨天探勘的路線搭公車到華盛頓大學門口,走路穿過校園到 workshop 會場。奇怪的是,怎麼還是沒有看到任何關於 workshop 的標誌?

等了十幾分鐘,心想是不是 workshop 改地方,還是自己弄錯時間了?想用筆記型電腦上網查詢,連外的網頁卻都被鎖住了,需要有 ID 與密碼。這下怎麼辦呢?只好衝進大樓裡,找個「看起來知道怎麼回事」的人問問看了。

好不容易知道會場確實是在這棟大樓的 251 室,走進去詢問是否在這兒報到,才又被告知,報到的位置改在一棟叫做 Mary Gates Hall 的建築裡。匆匆趕去報到,拿到名牌後,服務人員告訴我 Proceedings 已經沒貨;也就是說,我預購的 Proceedings 賣光了。她說,沒有預料到如此,但會退費到信用卡帳戶。哎,怎麼會搞出這麼多烏龍啊?

後來才知道,許多人也遇到類似的問題。於是,workshop 開始的時間被迫順延半個小時(原本預定在早上 8:30 開始)。

雖然英文講來仍不順暢,但有一兩位聽眾似乎頗感興趣。其中一位 Hugo Zaragoza 還看出我投影片中,隱約暗示論文的結果,應該也能應用在 closed document repositories。我在休息時間向他請益,他稱讚我說做得相當好。

這個 workshop 從 8:30AM 開到 5:00PM,參加人數不多,自己也不好開溜。起得早又睡得少,報告完了之後精神鬆懈下來,其實自己已經頗有盹意。只好趁休息時間喝些可樂來提神,讓自己能夠從頭聽到尾。

結束一天的會議後,搭公車到市區,徒步走回旅館,並順道買份麥香雞堡來當作晚餐。市區的麥當勞賣得特別貴,但這時因為太過疲累,也顧不了這麼多。回旅館後,趁著還有些氣力,胡亂地寫下一些今天的遭遇與感想。

這真是累壞人的一天啊。

星期三, 8月 09, 2006

初至西雅圖

西雅圖的天空,層層地疊起多片雲層,看起來頗有美感。

到旅館把行李卸下後,看看時間還早(下午五點左右,西雅圖到九點才天黑)。背上背包,徒步到旅館四處逛逛,看看一下旅館四周的景色,也了解一下它們在地圖上的位置所在。

雖然從網路上,已經知道旅館距離有名的西雅圖針塔 (Space Needle) 相當近;但隨便走過兩個 blocks,針塔就在眼前,還是讓自己小小地吃了一驚。

不過,可能是因為先前聽說西雅圖很漂亮,以致於心裡產生過高的期望,當我看到街道不算是太乾淨時,心裡其實是有些失落感的。

我想探勘一下公車的路線,因為明天自己必須試著搭公車去 workshop 會場。循著地圖往商業區走去,比起台北來,路上的行人數量不算多,但汽車的密度卻差不多。我沒有把握明天就學會搭乘這裡的公車,心想,如果到時候迷路了,就坐計程車吧。

沒能像阿尼那般自在瀟灑。除了想到上台用英文報告會緊張,連交通行程自己都還是走一步算一步。雖然有從網路上取得一些資訊,但真槍實彈地搭公車轉乘,還是會擔心自己錯過站。

不過,旅遊的一部份趣味,正是在於小小地探險。因此,用半生不熟的英語問路,有時也會變成旅遊的有趣回憶。這也是為什麼我會試著從機場搭 Airporter Shuttle 到旅館 --- 除了省些錢外,還可以讓自己詢問櫃臺小姐與司機,該如何乘坐到下榻的旅館。(我其實也不是一開始就自願要這樣問路的。主要的原因,是自己並沒有在網路上租到便宜的汽車,而在西雅圖機場租車,價格卻是市區的兩倍左右。)

雖然許多行李是由太太幫忙打點,但這可是自己第一次,一個人出國「半自助旅遊」呢。因此,即使是「問路」這種小問題,都還是會讓我的神經緊繃。雖然事後看起來還頗有意思,但身在其中,就很容易感到緊張煩躁了。

星期二, 8月 08, 2006

參加 Workshop 前夕

我覺得,最近總感覺不到太多悠閒,即將出國參加 workshop 應該也是一大原因。

從辦理美國簽證、機票、旅館住宿、甚至該如何到旅館、如何到 workshop 場地(是否要租車),都頗為繁瑣。努力地想省些錢,最後卻經常發現很難省到,令自己平添一股怨氣。

此外,希望能夠做好投影片,希望自己上台報告時不要太出醜。光是想儘量給一份可聽可看的 presentation,就會讓自己悠閒感盡失。

其實,英文非自己母語,聽說能力不好,也不能說太丟臉(只能說自己過去努力不足)。能夠將論文投上 workshop,多少已經表示論文有些內容,因此也不必覺得內容羞澀無法見人。此外,workshop 應該也練習學術溝通的好機會,既然是練習,偶而出醜也是難免,真的也不需看得太重。

然而,說的還是比做的容易。閒暇時,三不五時就會想起投影片某個地方的英文用字不妥,因而持續對投影片做小修改。基本上,由於了解自己英文報告的能力不佳,「策略上」我都嘗試把要講的東西儘量寫在投影片上,讓聽眾可以「用看的就懂」,而不需要聽我的口頭報告。

會對參加 workshop 感到緊張煩躁,多少表示自己還是頗重視這樣的場合吧。出國報告,可是得花費一筆不小的費用哪。只可惜,因為寶寶就要出生了,我這回的行程排得像是在「出差」,時間相當緊湊,沒有任何觀光旅遊的餘裕。

也或許,時間的過去,就是任務的完成。就是把這樣的機會,當作一場不錯的學習經驗罷。

星期一, 8月 07, 2006

十年前的軟體系統

週末幫別人安裝、設定一台需要執行 ET + dBASE 的電腦。

MS-DOS 6.22?倚天?別開玩笑了,這個年頭,大家都已經習慣用 Windows XP + M$ Office 2000+ 了,誰還在用這些老掉牙的軟體啊?

但還是有這樣的需求。被取代的,是一台已經有十年以上機齡的電腦。最近因為這台機器老舊,開始出現一些狀況,因而需要重新安裝一台新的電腦。舊機器上的許多軟體,因為經常在使用、且已經習慣使用,因而最好能在新機器上執行。

為了把系統移植到新的機器上,我著實花了不少時間。理論上,新的電腦應該可以吃舊的硬碟格式,新版的 Windows 也可以用相容模式執行舊版的軟體,但...實際上就是會出些狀況。

例如,在新電腦上若同時置入新的(至少數十 GB 容量)硬碟與舊的(只有 1GB 容量)硬碟,必須將它們放在不同的 IDE channel 上,否則就會聽到「嗶、嗶」的警示聲。但即使放在不同的 IDE channel 上,用新硬碟執行 Windows 系統,把舊電腦的內容拷貝出來時,系統會相當不穩定,很容易當機(系統自動重新啟動)。

然後,為了讓新的硬碟是可以開機的,我必須在硬碟上安裝 MS DOS 6.22 的開機系統,這樣又花了不少力氣。再來,就是測試倚天系統與 dBASE,反覆弄了好幾趟才成功。

印象深刻的,是舊的硬碟上,含有 ET + dBASE + Windows 3.1 + M$ Office 5.x 的軟體,壓縮起來後,總共竟然只需要 100+ MB 的容量。相較起現在動不動就是幾百 MB 的軟體,真令人不禁懷疑,那些儲存空間究竟是被什麼怪物吃掉了。

範本檔案損壞了?

學弟說,我的網誌在 IE 上觀看,左邊的 sidebar 會看不見。

我試了一下,果真是如此。奇怪啊,雖然我已經習慣使用 Firefox,但先前似乎也曾用 IE 來檢視過。怎麼會(什麼時候開始)出現這種狀況呢?

調出 Blogger 的範本,意外地發現,範本檔好像有些毀損。奇怪啊,自己應該有一陣子都沒有動過範本檔了,難道是 Blogger 想幫我修改些什麼,卻意外地把範本檔案弄壞了?

好吧,只好從新建構一個範本。可是,我早已忘卻,如何在左方的 sidebar 加上「最近 post 的一些網誌」了(之前好像是 MPH 告訴我怎麼弄的,但這類的設定最好能夠找到參考資料,否則每次都會忘卻)...

星期四, 8月 03, 2006

PHP 的字串處理

喜歡 PHP 的另一個原因,是因為它提供許多方便的字串處理函式。

文件上說,PHP 這個程式語言,是採擷 Perl、C、以及 Java 的一些優點所形成。Perl 的優點是什麼呢?我覺得,主要就是提供一套強大的處理函式,可以利用正規語言表達式 (Regular Expression,或可直接譯為「正規表達式」) 來對字串進行比對與取代。

雜事做多了,就自然能夠感受 Perl 或 PHP 那些處理字串函式的優點。例如,很常見的一項雜務,就是一個「a,b,c,d,e」這樣的字串,用逗點切分,放在陣列中供後續處理;或者反過來,將一個陣列的內容一個個地傾印出來,但是在兩項內容間,加入一個分號。PHP 的 explode() 與 implode(),就可以做這樣的事情:

$s = "a,b,c,d,e";
$array = explode(",", $s);
$t = implode(";", $array);

就像是 Perl,PHP 也提供了更強大方便的 regular expression 的字串處理函式(事實上,PHP 支援了 Perl-Compatible 與 POSIX-Extended 兩種正規表達式的處理標準)。例如,由於 HTML tag 的屬性值,可以用雙引號、單引號、或甚至「沒有引號」來標示,我們可能會想將一篇文件的 href 統一用雙引號來框住。也就是說,會想將

<a href='www.yahoo.com'>Yahoo</a>
<a HREF=www.google.com>Google</a>

這樣的字串們取代為

<a href="www.yahoo.com">Yahoo</a>
<a href="www.google.com">Google</a>

在 PHP 裡,要達到這樣的功能是頗容易的:

$pattern = "/<a href=(['\"]?)(.+?)\\1>/i";
$replaced_by = "<a href=\"$2\">";
$t = preg_replace($pattern, $replaced_by, $s);

只要大家嘗試用一般的字串處理函式來實作,吃過苦頭(因為麻煩又無趣)後,應該就會同意,正規表達式在字串處理上的的威力與優點。

雖然,現今廣用的程式語言幾乎都有提供 regex.Matcher 與 regex.Pattern 之類的物件,可以依循正規表達式處理字串;但我覺得,繼承了 Perl 的優點後,PHP 在正規表達式的使用上,還是比那些物件導向語言,來得自然、方便太多了。