Tiger也把中文變羅馬字了

在 Mac OS X v10.4 "Tiger" 推出後，我們看到不少中文環境方面的變動和改進。這次想提出來的，是由站友 Ban 發現的中文轉羅馬拼音的功能。

在過去我們曾提到 Mac OS X 10.3 具有將漢字依日語發音轉成羅馬字的功能，但是無法轉成中文拼音。到了 Tiger 則終於出現了轉成中文拼音的功能。只要是以繁體中文介面開機（這可以在系統偏好設定中的「國際設定」中調整），系統即會在特定的情況下，將使用者輸入的中文自動轉為漢語拼音。

例如，到系統偏好設定的「帳號」開一個新帳號，輸入中文帳號名稱並移到下一個欄位，系統即會自動填上名稱的漢語拼音作為簡稱。而若是到系統偏好設定的「共享」裡輸入中文的電腦名稱，也可以看到系統會將名稱轉為拼音以作為內部網路連線的位址名稱，另外打開「終端機」這個工具程式同樣可以看到被轉成拼音的電腦名稱。只是電腦名稱似乎非得全部以中文命名才行，若是中英文夾雜則系統只會保留英文的部分作為羅馬字形式的名稱。

經過測試，這項功能也適用於簡體中文及韓文。以簡體中文介面開機，中文一樣會被轉為漢語拼音。而若以韓文開機，諺文的部份會被轉為羅馬拼音，漢字則無法依韓語發音轉換。

由於簡短形式的帳號名稱以及電腦名稱都只能以英數字的格式被系統辨認，但是 Mac OS X 又想接受使用者輸入自己習慣的語文作為全稱，因此自動地幫使用者產生英數格式的名稱，也算是 Mac OS X 為使用者著想的一種表現。只是，「阿傑仔」的「仔」他拼成了「zi」....。

本文同步刊登於符號工作站

從一張舊地圖上的地名說起

Courtesy of the University of Texas Libraries, The University of Texas at Austin.

這張遼東半島一帶的地圖出現於 1912 年 Hachette & Company 的 Madrolle's Guide Book 一書。這張圖除了可以顯示當年當地的地理資訊外，也存在著其他有趣的訊息。

這張地圖裡出現的地名來自各種語言，包括漢、滿、英、日、俄等。漢語北方官話的地名最多，像 Fêng-t'ien（奉天，今瀋陽）、Chao-yang（朝陽）、K'ai-p'ing（開平）等等。奉天的另一名稱 Mukden 則是來自滿語。Dairen、Ryo-jun 是大連、旅順的日語發音，大連的另一名稱 Dalny 則是俄語。Port Arthur 指旅順港，改名的可能是俄國人，不過在這裡又被譯成了英文。這些地名顯示這個地區曾經有多種族群、國家牽涉其間。

另外我會特別注意的，是當時使用的中文拼音。從圖上明顯可知該地圖使用了「威妥瑪」式的拼音。威妥瑪拼音一直到前幾年都是在台灣佔有極大優勢的拼音法，不過一般人對於這個拼音有相當的誤解。

第一，有人以為威妥瑪拼音不區分送氣音與不送氣音，所以會把ㄅ與ㄆ（國際音標 p 與 p^h）、ㄉ與ㄊ（t 與 t^h）、ㄗ與ㄘ（ts 與 ts^h）等組發音相混，事實上威妥瑪會在所有送氣音之後加上 ' 符號，所以ㄆ拼為 p'、ㄊ 拼為 t'。第二、ㄜ常被拼成 e，例如「承」拼為 cheng、「德」拼為 te，其實威妥瑪拼音除了在舌根音後方之外，ㄜ是拼為有附加符號的 ê。 第三、 ㄩ的音常常被拼成u，例如「元」拼成 yuan，其實威妥瑪拼音是一律拼成附有兩點的 ü。第四、有人以為威妥瑪拼音「基」（ㄐㄧ）與「知」（ㄓ）都拼成 chi 而混淆、「欺」（ㄑㄧ）與「蚩」（ㄔ）都拼成 ch'i 而混淆，其實ㄓ是拼成 chih、 ㄔ是拼成ch'ih，也就是說，ㄓ、ㄔ、ㄕ的韻母（空韻）其實是拼成 ih，和ㄧ拼成 i 有所區別，h 不可省略。

這張地圖在使用威妥瑪拼音時，沒有混淆送氣音與不送氣音，開平拼為 K'ai-p'ing，而非省略送氣符號的 Kai-ping 。另外承德拼為 Ch'êng-tê，而非 Ch'eng-te 或 Ch'eng-teh（似乎有些人會以 eh 代替 ê）。而平泉的「泉」則拼為 ch'üan而非 chuan。顯然這張地圖上該有的附加符號也都有。整體來說，它在威妥瑪拼音的使用上還算嚴謹。

現在的人們基於誤解、偷懶、打字不便等原因常把威妥瑪拼音弄錯，尤其送氣與不送氣音的混淆最為常見。下次我們有機會使用威妥瑪拼音時，不妨多以謹慎的態度來拼寫。看到近百年前的地圖可以正確地印出這些符號，令人感到現代的人往往是不夠謹慎的，而那些無法或極不方便打出這些特殊符號的電腦作業系統，也算是一種荒謬的現代產品吧。

本文同步刊登於符號工作站

讓你的網站會說話

網路上有個叫 SitePal 的服務，它可以藉著 Flash 技術提供動態且具人工智慧的動畫虛擬人物，使用者只要把它整合到自己的網站上，就可以讓活靈活現的虛擬人物豐富自己的網站內容。例如，虛擬人物可以與網站參觀者藉由文字來互動並回答問題、甚至可以發出語音做網站導覽等等。而人物的外觀則可以由服務使用者來自行調整。不過這項服務是必須付費的。

我最感到興趣的是他們的語音功能。要讓虛擬人物發出語音，服務使用者除了可以自行錄音並上傳外，也可以直接使用其 text-to-speech 功能，也就是說，使用者想要人物念出什麼內容，只要把內容用打字的方式輸入，人物即會用語音合成的方式把它朗讀出來。這樣一來，就可以讓人物念出不受限制的内容，並輕易地配合自己的網站做變化。而且，其人物的嘴型還會配合所發出的語音做改變。

其實 text-to-speech 的技術對於很多 Mac 使用者來說並不陌生，因為 Mac 的作業系統一直內建有這種功能。過去的系統中除了英文之外，也具有中文（繁、簡體）與墨西哥西班牙文的文字朗讀功能，只是到了 Mac OS 9 和 Mac OS X 時代， 這兩種語言的朗讀功能就銷聲匿跡了。另外較為可惜的是，Mac OS 提供的語音合成品質一直以來似乎未有重大提昇。

相形之下，SitePal 的語音品質就好得多，更接近自然人聲，詞與詞、音節與音節之間的銜接都算是理想得多。而且 SitePal 可以朗讀十三種語文，其中也包括了中文，念起中文來比當初 Mac 上的「小趙」要優秀不少。不過中文的 text-to-speech 還必須處理一字多音以及上聲變調的問題，而要解決這些問題則經常需要一個資料庫來為文章做「斷詞」，SitePal 在這方面似乎還有不足之處。

看到 SitePal，我想到 text-to-speech 其實可以有多樣化的應用方式。

本文同步刊登於符號工作站

不完整的藏文？

在 #osxchat blog 網站上，刊出了一篇文章指出有一個新的 Mac OS X 藏文輸入法正在開發中，其中並描述了作者在製作時所遇到的問題，這套輸入法是以「OpenVanilla」為基礎進行開發，它所運用的也是 Unicode 裡提供的藏文字元。此套輸入法的出現對於想在 Mac OS X 上輸入藏文的朋友來說是相當好的消息。

我們除了感謝作者的努力之外，也慶幸 Mac OS X 不但支援 Unicode，而且在簡體中文字體中也加入了藏文字形。但是該篇文章也說到，有的藏文符號和拼字法似乎仍不在 Unicode 的支援之列。例如，當「上加」用的ར就沒有辦法適當地加在輔音字母上。下面是一個正確添加ར上加的例子：

從上面的範例中可以看到，rta （意思是「馬」）這個詞是由作為上加的ར (r-) 加在ཏ (ta) 這個字母上構成的，但ར必須省略最後一筆，然後才加在ཏ之上（ཏ本身的位置也可能也變得較低）。ར當作上加時可以加在多種字母上，有時對發音沒有影響，有時則會影響輔音送氣與否或造成聲調高低的不同。然而翻開 Unicode 的符號表，卻遍尋不著這種省略最後一筆的ར上加，這的確是相當奇怪的事。

而在網路上有一個 Java 版的藏英辭典，除了可以在 Windows 上執行，也可以在 Mac OS X 中運作。神奇的是這個辭典可以正常顯示這種添加ར上加的字。經對照後，才發現它使用的藏文字體和系統的並不相同，而似乎有自己的一套字體。這樣看來，它可能並未利用作業系統提供的藏文環境，甚至也不是採用 Unicode 作為內部編碼。

所以，現行版本的 Unicode 在藏文處理上似乎還是有不足之處，也許我們只能期待在未來的 Unicode 版本中能提供更完整的藏文符號。

本文同步刊登於符號工作站

浴血戰場中的「中國古代文明」

最近 Macworld 選出了 Unreal Tournament 2004 為 Mac 平台上的年度最佳遊戲。剛好我正是第一人稱射擊遊戲的愛好者，而且也擁有這款遊戲。這套遊戲的優點之一是它有中文界面，不過似乎得升級到新版本才能正常顯示中文。網路上還有更完整的中文化檔案可供下載，只是目前好像只有簡體中文的版本。

遊戲中有許多華麗的場景，有趣的是，其中有一個場景是以東方特色為主的，建築物內還隨處可見中國文字（請參考附圖）。只是這些中國文字有一些詭異的地方。例如，它將「中國古代文明」這個「名詞組」（noun phrase）寫在各個牌子或燈籠上，對我這個懂中文的人來說似乎沒什麼太大的意義。另外，就是燈籠上的文字是左右相反的，「中國古代文明」也只剩前三個字而顯得較無意義。而在牆上的那四個一組的藍色字雖然不太看得懂，但最大的問題是它經常是上下顛倒或左右相反的（圖片中較上方的四個字即與下方的四個字上下顛倒），這些都並不合理。而更怪的是遊戲裡說明這個場景是在「古代的朝鮮」，朝鮮用漢字不奇怪，但到處寫著「中國」兩字就比較怪異了。

這似乎顯示出做這些場景設計的人是不夠懂中文的，因而弄出了一些不盡合理的安排。這些文字的主要功能大概是為了營造出一種東方味道，對設計者來說這些文字裝飾的作用恐怕遠大於字義的表達。這讓我想起 Engrish.com 這個網站。Engrish.com 裡有許多來自世界各地（主要是日本）誤用英文的圖片，而其中許多令人摸不著頭腦的怪異英文之所以產生，常常也是因為文字本身的外型成為設計或裝飾的一部份，至於字義與語法的正確性反而不被仔細看待。 Fred 兄的抓包地帶討論區裡也有一些和台灣有關的類似例子。

不過在遊戲中，玩家們都在忙著置對方於死地，誰還管得了這麼多？

本文同步刊登於符號工作站

希望猛虎不要變病貓

有幾位朋友能夠拿到蘋果提供的 Mac OS X 10.4（代號 Tiger）早期版本，因此提供了關於 Mac OS X 10.4 的中文環境方面的消息。有人說到在目前蘋果所釋出的 Tiger 預覽版本中，提供了較方便的繁簡中文轉換服務，也就是可以讓使用者利用「服務」選單來轉換繁簡中文，不過沒有提供快捷鍵。另外在繁體中文輸入法選單裡也有轉換為簡體字的功能，看起來應該是可以將輸入窗裡的字，在還未送出到應用程式之前加以轉換，不過將這樣的功能建立在輸入法中會有多少實用性還很難說。

另外 Tiger 中的輸入法也有了新的架構。各個中文輸入法現在不是包含在單一繁體中文輸入法中，而是各自獨立為單獨的輸入法而出現在輸入法選單中。在倉頡輸入法中使用者現在可以將動態提示視窗設定為直的或橫的。

看起來 Tiger 的輸入法做了相當程度的更動。但是有著嚴重問題的倉頡呢？很抱歉，有人表示在目前的版本中，倉頡的程式錯誤依然故我，完全沒改正。原來他們有時間東改西改，就是沒有時間把一個顯而易見的錯誤改掉。當然 Tiger 還在發展之中，但這項錯誤早應該在 10.3 的更新中就改正，本人也早已在今年初送出報告，結果在新版本的系統中只看到蘋果的相應不理。似乎碰到了中文（尤其是繁體中文）， "Tiger" 就成了病貓、美麗的蘋果就成了爛蘋果。不相信？看看這張圖就知道了：

本文同步刊登於符號工作站

Mac OS X 信件標題亂碼的解決之道

Mac OS X 自從升級到 10.3 後，所附的「Mail」電子郵件軟體就出現了一個怪問題。中文信件若未被認為是中文編碼而成為亂碼，使用者可以選擇 Message > Text Encoding （郵件 > 文字編碼）來選擇為中文編碼，內容即可正常顯示，可是糟糕的是信件的標題卻不為所動，不管如何更改信件的編碼，標題永遠都是亂碼。這在英文介面的系統裡尤其是個問題，因為編碼不詳的信件都會以預設的語言來顯示，而在英文介面下預設的語言是西方語系，中文信件自然就成了亂碼，需要更改編碼的機會也就多了。

一位朋友 Luke 發現解決之道。若您是以英文為作業系統及 Mail 的主要語言，那麼您可以開啟開機硬碟之下的 System/Library/Frameworks/ 這個檔案夾，並找到其中的 Message.framework，再打開裡面的 Resources，將 zh_TW.lproj 裡的 LocalizedDefaults.plist 取代 English.lproj 裡的 LocalizedDefaults.plist 即可。因為這個目錄無法任意更改，所以您最好有管理者的權限，並可能要把 zh_TW.lproj 裡的 plist 檔拷貝至桌面、再從桌面拷貝至 English.lproj 裡才能順利取代。

若在 Resources 裡沒有 zh_TW.lproj 這個檔案夾，也可以用 Property List Editor 來編輯 English.lproj 裡的 LocalizedDefaults.plist，並增加一項 NSPreferredMailCharset 的項目並將其值設為 big5 即可。若您也沒有 Property List Editor....，則請將該 plist 檔的內容用文字編輯器改為：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPreferredMailCharset</key>
big5
<key>SendFormat</key>
<string>MIME</string>
</dict>
</plist>

關掉 Mail 再打開，即會發現信件標題也會依所選語系來顯示了。以上方法適用於繁體中文信件，其他編碼的信件未能測試。

我不明白為什麼蘋果公司不立即解決像這樣的錯誤並發布軟體更新來讓使用者升級，我們似乎一定要等到下一次重大的系統升級（例如 10.3 -> 10.4）才有可能看到這類問題被解決。但是照以前的經驗來看，重大的更新都必須以相當的價格才能購得，而且竟然沒有任何升級價。換句話說，使用者必須付出昂貴的代價才能讓軟體的問題被解決，這顯然是極為不公平的。

本文同步刊登於符號工作站