Unicode摧殘正體字

 不學無術的「果迷」,給「黑體-繁」(又稱「Heiti TC」)所扣的帽子,最主要是指稱它「寫錯字」。正如在下連日來的論證,已說明他們口中所謂的「錯字」,是如假包換的正字,是符合字理的寫法,是符合《康熙》、《說文》等傳統權威字典的字形。要是嚴格地遵從字理而論,眞正寫錯字的人,是他們自己。

 他們另一項給「黑體-繁」扣的帽子,就是指它部件寫法不統一。例如《TCFail》網站上,負責人說:「同一個部首的許多字,也往往沒有依照一套固定的造字規則,例如『清』的『月』是寫成月,但是『晴』或『請』則寫成了日文貨幣單位『円』,毫無規則可言。」

 若有細讀在下之前的〈劣字驅逐正字〉,應該看到我的解說:問題關鍵在Unicode的編碼。換言之,這群人連眞正問題都沒査清楚,把Unicode編碼不善的賬,算到「黑體-繁」的頭上。

 理論上,Unicode只是編碼標準,不是字形標準。因此其官方說法是:它只對字(Character)編碼,而非字形(Glyph,每個字的具體形狀、寫法)。陸、港、臺、韓的「港」字右下從「巳」,日本的「港」字右下從「己」;港、臺、韓、日的「角」字中豎不穿頭,大陸的「角」字中豎穿頭;港、臺「起」字從「巳」,陸、日、韓從「己」……這些異形同字,Unicode都不分別編碼。例如「港」就是「6E2F」,不論從「巳」還是從「己」。

 然而,爲了相容不同地區的編碼,Unicode又有「字源分離原則」。好像日本JIS編碼同時收錄了「剣」、「劍」二形,Unicode爲了與之兼容,即使它們是同一個字,Unicode也分別給予編碼:「剣」是「5263」,「劍」是「528D」。

★ 橙字是正常Unicode編碼。
★ 黃字是兼容區編碼,難以正常輸入。
★ 若只有一個Unicode編碼,卻有兩個字形,表示Adobe以CID技術,在同一Unicode碼內製作了兩個字形,可用Adobe InDesign等軟件選擇心目中的異體字。但在不支援CID的軟件裏,只能顯示其中一形。

 結果,有些異形同字,被編進同一碼位,有些則區分作兩碼,造成了Unicode內的自相矛盾。「青」字旁的字正是好例子。「靑」、「青」分別編碼作「9751」、「9752」;「淸」、「清」也分別編碼作「6DF8」、「6E05」。每個形態都有一個常規編碼。在Windows 7或8裏開啟「倉頡輸入法」,鍵入「手一月」可輸入編碼爲「9752」的「青」,鍵入「手一月卜」可輸入編碼爲「9751」的「靑」。至於鍵入「水手一月」,則有「清」、「淸」二字可選。這四個字形都能正常輸入——不過有附帶條件:要把輸入法設定作輸入Big5碼外的字,以及使用支援Big5碼外的字之電腦字體。因爲在進入Unicode時代前,大家已慣用臺灣的Big5編碼去處理正體(繁體)字,它並不支援「靑」(9751)、「淸」(6DF8)。即使今天是Unicode時代,用「靑」(9751)、「淸」(6DF8)二字,仍要冒變成空格的風險——用戶端選了只支援Big5的字體,以致顯示不到。有些軟件甚至到現在都不支援Big5碼外字,剝奪了用戶選擇正字的權利。

 至於「精」、「靖」、「晴」三字,從「月」的字形,分別有「7CBE」、「9756」、「6674」這三個常規編碼;從「円」的字形,則獲編作「FA1D」、「FA1C」、「FA12」。問題是,從「円」的那些「FAXX」編碼,並非常規編碼,而是「兼容區」編碼。於是,在Windows 7或8裏開啟「倉頡輸入法」,無論怎麼拆碼,都輸入不到從「円」的「精」、「靖」、「晴」三字。碼不是沒有編,但根本不想你用。

 以下的字更可憐:「請」、「情」、「蜻」、「靜」、「睛」、「婧」、「靚」、「瀞」、「菁」、「箐」、「倩」,它們都只有一個編碼。字型設計者要麼把它們的字形寫作從「円」,要麼寫作從「月」。除非像小塚明體等日本字型般,支援CID字庫技術,替這些Unicode裏的同碼異體字另行編碼,讓使用者在支援CID的軟件(如Adobe InDesign)裏自行選擇,否則只能二擇其一。若字型設計者,盲從臺灣那套背棄正統字形的所謂「標準」,用戶根本沒機會選擇正字(從「円」者)。

 原版「黑體-繁」並沒盲從臺灣那所謂「標準」,像「請」、「晴」、「菁」、「蜻」等字它都從「円」。但像「青」(9752)、「清」(6E05)等字,爲使它看起來與「靑」(9751)、「淸」(6DF8)有分別,於是就依Unicode寫作「月」字底。這是那些「果迷」聲稱「不統一」的主因。在Windows 2000、XP年代,細明體還是細明體(未變成掛羊頭賣狗肉的標宋體)時,也有這種批評。

 既然Unicode對這些異體字的處理如此混亂,字型設計者若依從它,只會使字型也變得混亂。若說要統一這些部件的寫法,我同意。但統一的方向,應當是依照《康熙》、《說文》等正統印版字形,而非大陸或臺灣那套以手寫楷字竄改印版字形的所謂「標準」。換言之,只獲編一碼的「請」、「情」等字,當寫作從「円」部件;分別被賦予兩個碼的字,不管哪個碼位,不論是「9751」還是「9752」,是「6DF8」還是「6E05」,都同樣應寫作「円」部件。如是者,整套字型裏的字形才統一。不論輸入法、軟件對編碼的支援、字型涵蓋的編碼範圍如何,使用者都能顯示出正確的傳統字形。

 然而,這種主張也有人反對。在下強烈推薦的傑兄文章〈是誰寫錯字?(三)〉裏,But於留言欄的回應可作代表。他說:「舊版的細明體在Unicode下是有名的錯誤連篇。例如Unicode裏『為』、『爲』是兩個不同的字,但舊版細明體可能是因爲第一版只有Big5部分(按:宜作『份』),把『為』字造成『爲』了。結果擴充到Unicode範圍後,兩個碼位的文字無法區分。形成錯誤造字。」「例如『柿』跟『杮』是否能清楚區分。……在沒有區分必要的情況下,上面的點(宋體通常是豎)跟下面連貫倒無所謂。但因爲有一個木字旁『柿』跟『杮』會混淆的問題,只好像辦法區分它們……」

 對此,我看到But兄的回應有一大盲點:「『柿、杮』之別」與「『為、爲』之別」是兩個截然不同的概念,他卻弄混了。論證有訛謬,結論亦因此有誤。

兩個不同的概念:「不同的字」與「異體字」

 「柿」與「杮」是不同的字。從「市」的「柿」,粵音「ci2」或「ci5」,北音「shì」,是種植物或水果。從「巿」的「杮」,粵音「fai3」,北音「fèi」,解作削木。這兩個是不同的字,只是字形較像,音、義俱無關係,當然要作區分。然而,「為」與「爲」本來就是同一個字,它們的音、義俱同,只是寫法上有些分別,是異體字。不必專門修讀文字學,也應當知道:處理異體字的方法,與處理「根本是兩個字」的方法,並不相同。兩個不同的字,寫成同一個模樣,就是寫別字。但異體字本來就是同一個字,若無書法等特殊需要,在日常使用下,一般人都會統一取其中一形。平時我們閱讀的書刊、報章,編輯都是這樣做的。

 我並不反對在某些特殊情況下,有使用者要顯示異體字的不同寫法,把編碼「70BA」顯示作「為」,把「7232」顯示作「爲」。例如這一篇硏究異體字的文章,就有這種需要。但,這種特殊情況,不應影響到以下大原則:一、使用有字理依據的正統字形,是種應獲保障的權利,任何人在任何情況下都不應指鹿爲馬,把有字理依據的正統字形視爲「錯誤」。二、對印版字體而言,在一般情況下,應把寫法上有點兒差異的異體,統一作正統字形。三、能使用正統字形的機會,不應比使用各種訛俗字形低,因此若無特別指定,應以正統字形爲準。

 要實踐這些大原則,其實不難:電腦作業系統,應以符合正統字形的字體,作系統預設字型。同時,提供各種符合不同「標準」(包括臺灣「標準」、大陸「規範」、Unicode混亂異體編碼「標準」等)的字體,供使用者按需要選擇。那麼,我平時寫文章,不必擔心輸入法能否打出哪個「青」,不用憂慮軟件是否支援Big5碼外字,不需害怕讀者的瀏覽器能否正確顯示。總之,輸入「青」字,就必定顯示出從「円」的正寫。到我有需要指定某個異體寫法,或者But兄要擧出Unicode收錄不同的字形時,則可以向軟件下指令,改爲顯示另一款包含在系統裏的字體,以應付這些特殊需要。以Windows的實況作例,目前各種符合不同「標準」的明體和黑體都有了,只要把實爲標宋體餡的細明體易名作「標宋體」,然後再提供回字形依正統寫法的正統細明體和正統黑體,作預設系統字型,問題不就解決麼?

 偏偏,現在的情況是:作業系統只提供了符合各種所謂「標準」的字型,卻不提供符合正統字形的字體!大家使用正統字形的權利被剝奪,連用正統字形的權利都沒有,更遑論無特別指定時是否以之爲準了!如是者,受着各種訛體俗字耳濡目染,連大家對正統字形的認知也越來越模糊。漸漸,大家只會擁抱着各種有問題的所謂「標準」,指鹿爲馬、顚黑倒白地,指責符合字理的正統字形是「錯字」——就像那些不學無術的「果迷」,聲稱與「標楷體」(臺灣「標準」)不符的正字是「錯字」、「一整個不對」、「不應該寫成(如此)」、「毫無規則可言」、「可能是來自日文漢字的寫法」、「根本就是錯字」。也如高擧Unicode混亂異體編碼「標準」的But兄,罵與之不符的寫法是「有名的錯誤連篇」、「錯誤造字」。符合字理的正統字形,不但喪失了獲大家使用的權利,更要背負上「你是錯字」這種無稽的罵名,天有眼嗎?天,有眼乎?!

2013/01/10 01:07 +0800

討論區

kmc, 2013/01/10 08:54 +0800

拜讀大作,感悟頗深,keep 'em comin'!

內木一郎, 2013/01/19 00:29 +0800

kmc大見笑了。承蒙錯愛,實在萬幸!^^~

But Ko (由錄主從fb搬運過來), 2013/01/18 17:45 +0800, 2013/01/28 05:33 +0800

我的理念很簡單:「字型應該根據他提供的字集範圍,提供明確可以區分的字形」。例如若是Big5 range,就不用區分「點起筆的『為』」跟「爪頭『爲』」。但如果是Unicode BMP range,這就必須區分「為」(Unicode 70BA)跟「爲」(Unicode 7232)了。若是Unicode Ext-D range,連「埶頭『勢』」跟「執頭『𫝑』」都必須區分了(可能會影響隸書之類的字型)。這樣才符合Unicode技術標準。

分別被賦予兩個碼的字,不管哪個碼位都寫成相同部件這種作法,不能稱爲Unicode字型,反而該稱爲特殊用途字型。(就像那些Big5編碼的簡體字型……)

話說從頭,爲甚麼Unicode BMP會兼收「月底『青』」跟「円底『靑』」兩個字?其實就是有某個源字集兩者都收了(應該是日本JIS收了,日本很多異體字在人名都經常區分使用)當年業界提出好幾種國際碼方案,不乏人主張既有的編碼收字標準都太亂了,應該分析漢字原理,將正體字與異體字做有體系的整理云云,例如臺灣CNS11643的作法,把正字作爲1字面,異體編到同碼的第2之後字面。但這些方案都失敗了。因爲技術上不易實作,既有文件難以相容。如果併了「月底『青』」跟「円底『靑』」,原本用JIS製作,有區分這兩個字的檔案,轉成新國際碼時反正資訊遺失了。

考慮既有文件相容性是美麗的設計最討厭的事情(very dirty),但工業史一直證明了相容的技術才活的下來。Unicode用很爛但很有效的方案處理這問題。原則上Ideographic進行Unify(整併),但是,源字集(既有的Big5、JIS、GB等等)其中一者有區分的字,那就區分吧。所以,某個既有字集區分了「月底『青』」跟「円底『靑』」,在Unicode裏他就被分開了。這樣一來,就能確保每個既有字集跟Unicode的編碼都存在一對一關係了。

依據以上Unicode設計理念,「月底『青』」跟「円底『靑』」是因爲源字集相容性需要而區分的,字型檔當然有必要區分出這兩個字形,才符合Unicode理念。

所以,就像你說的,這是Unicode的錯。其實我同意。這確實是Unicode的設計造成的麻煩事。但,現實的世界總是最不純粹,最能解決現實需要的技術,最能茍活下來。(所以該死亂七八糟的True Type規格,我到現在還沒看懂……)

異體字跟不同的字有時並不是這麼容易區分的概念。像「机」在臺灣的習慣認爲是「機」的簡體;在日本反而等同於「几」,是桌子的意思。那麼,Unicode的「机」字,到底該視爲「機」的異體還是「几」的異體呢?

一切考古追溯字源,就是會碰到很多向上面這樣的麻煩問題。Unicode處理世界其他語言的時候,都傾向字義分離原則。例如英文的「A」、希臘文的「Α」、俄文的「А」,在Unicode是三個編碼。但是Unicode組織在漢字踢到鐵板了,像上面的情況,以一樣的標準以語意分離,就應該把「机(Machine; Chinese Han Character)」跟「机(Desk; Japanese Kanji)」區分成兩個編碼了。

但這一來,考證過程不知道要花幾年時間,有些罕用字,每個學者意見也各有分歧。例如「鮪」字吧。中文、日文都有「鮪」,但指的是不同的魚。有些學者認爲是日文誤用了中文「鮪」字的本意;有些學者認爲是兩地自己造了這個字,剛好長得一樣而已。根據前者理論的話,兩者本爲一字,應編一碼(一字衍生不同意思);根據後者理論的話,兩者不同字源,應分兩碼。

但Unicode上線時間迫在眉頭,實用的技術實在無法等待字源考證慢慢跑啊!即使今天急着相信一派理論,也許明天找到新的古籍,發現另一個理論才是對的。但某次會議就忽然決定了CJK併合的方向──以形狀區分,不以字義區分;並且每個字都命名爲CJK Unified Ideograph。

我也曾經鍾情在「正字」學上,但現在倒是放棄了。好比說「黃」字,在《說文解字》的理論,認爲應從「田」(敎育部從此說);但現今漢字學根據甲骨形,認爲從「由」更正確(香港字形表從此說)。實務上,即使我們知道這是正字,也不可能把「在」寫成「扗」了。也不可能把「奧」寫成「宀+釆+大」了。在字源學,這是很有趣的話題;但實用上,別人看不懂是沒用的。

寫太長了,在此打斷。

內木一郎, 2013/01/18 17:51 +0800, 2017/05/30 20:18 +0800

長不要緊,有理便可,但請不要把「正字」妖魔化、邊緣化或他化,非鑽到極端情況不可。像閣下所言「机」、「鮪」等,是「同形字」,字形是一模一樣的,Unicode收和不收,不影響到大家能否使用一個應當有權用到的字形,與本無討無涉。

我關注的,是一個大家應當有權用到的字形,何以變成無法使用,甚至還這麼理所當然般。既然其中一個原因在Unicode的編碼上,我看不到盲從的理由。特別是,Unicode的官方說法,更說明它只是編碼,而非字型。Unicode分別編收「月底『青』」和「円底『靑』」,只爲處理字集兼容問題。Unicode官方並非要以「青」字作常用字標準。連官方都表明其用意都不在此,卻硬說它是字形標準,最後還是不能用從「円」的正字,這太本末倒置吧?

若還是覺得「該字體覆蓋了多少Unicode編碼,編碼內的字就要區分,才符合Unicode技術標準」,那很簡單,說明這字型不是所謂「Unicode技術標準」,只是符合傳統字書的「正統標準」即可。不符所謂「Unicode技術標準」有何問題?像原版細明體,甚至過去照相植字機使用的寫硏明體,對,它們是不符合所謂的「Unicode技術標準」,卻是不少編輯、作者、出版人員需要的,能顯示出正確「青」部件的字體。我們日常用字,寫字也好,閱讀也好,印刷也好,才不管它是否符合所謂「Unicode技術標準」,只知它是否我要的字,以及能否正常的顯示出來不會變樣。

擧個實例。一個稱職的編輯,不論用甚麼技術,他有責任確保在同一篇文章中,使用同一字體時,於「月底『青』」與「円底『靑』」、「從入的『內』」與「從人的『内』」、「入頭『全』」與「人頭『全』」、「外形內聲的『裏』」與「左形右聲的『裡』」、「一個大框的『冊』」與「兩個小框的『册』」、「從𦘒、𣶒的『肅』」與「從肀、𣶒的『肅』」等異體字間,統一作一形。除非那篇是硏究異體字的文章(那就是特殊需求了)。這就是實際生活的情況。我們面對的,不是各種編碼技術如何、是否符合所謂「Unicode技術標準」的問題,是我選擇的字型能否正確顯示、能否統一之問題。這番說話,是曾當編輯的在下,與同道中人的切身體會。

現在的問題,不是技術上做不到,而是不同系統在不同原因下,都變成不提供這樣的字體,使用者變成無法使用。先不談沒指定時以哪者作預設,連最基本的有得用與否都成問題。科技不是以人爲本嗎?技術不是替實際需要服務嗎?爲何一個這麼理所當然要用的字形,爲了甚麼甚麼技術,變成不能出現?

不管甚麼技術,基本的有理字形能獲使用,應當是任何識字的人之基本權利。其他異體、寫法,有得揀當然最好。要是全部「青」部件的字,都能挑選寫法,我擧腳贊成。要是不能挑選,最起碼,任何人都應有權用正統字形。現在,不能使用,卻視爲理所當然;有人提出解決方案時,別的人卻東扯甚麼標準西談甚麼技術說不允許,令問題無法解決,是一種涼薄。眼看着民間冒起一個又一個自行修改的字型,都是爲解決正統字體問題,就知此問題已冰封三尺。

日本其實已有很不錯的解決方案:發展CID標準。就是不管理Unicode如何,總知要用的字形,有編碼、能使用。只要是異體字,不理它在Unicode編碼中有否被併合,使用者都可以選。這樣才是眞正面對問題,並且尊重傳統的做法。可惜這方面仍有待發展,一天瀏覽器不支援,一天我寫本錄文章時,無正字可用的煩惱仍在。

所以文章裏,我才主力說另一解決途徑:提供不同的字型供人選擇。這情況套用到互聯網上也一樣。「新字形」的中文web font,目前已有了。我絕對不是說要推翻它,不要誤會,有使用者喜歡新字形,他也有權用。但與此同時,會否也提供「舊字形」的中文web font,供使用者選擇呢?兩者並無矛盾,相反,這才是多元化,照顧不同使用者的需求。未知But兄覺得如何?

至於像「黃」字正確寫法這種標準的爭議,也與現在在下的討論無關。那是一些較細微的、較訓詁的爭議。我現在說的,只是一個眾所周知的傳統合理字形,何以「被無法使用化」。

也順帶一問,But兄若不同意在下所說的解決方法,未知有沒其他實際上可行的解決方案?

But Ko (由錄主從fb搬運過來), 2013/01/18 18:17 +0800, 2014/01/04 19:41 +0800

我不太能同意您說「黃」的案例是「較細微的、較訓詁的爭議」;而「靑」的問題是「眾所周知的傳統合理字形」。同是異體寫法,試問,你有辦法提出一個準確的標準,去劃分甚麼是「細微不要緊的」,甚麼是「傳統合理需要遵循」的嗎?

以「康熙字典體」爲基準?拿「草字頭」來說好了,傳統印刷體其實都是造成三筆的,包括你所愛的舊版細明體。反而是《康熙字典》特別造成四筆,以傳統明體來說,反而《康熙字典》的風格是比較特殊的。

「青」字應該從「円」,您說這是「眾所周知的傳統合理字形」。那麼「前」跟「俞」呢,是不是應該比照《康熙字典》寫成兩點的「舟月」?話說傳統明體對於「月」跟「舟月」的區分,看得比「肉月」還要重,但反而重視這個的人並不多?到底哪個重要,哪個不重要,到底怎麼去找這個準?

拿您這張圖使用的傳統風格黑體來說好了(應該是您們同好改出來的版本吧?),我實在很難找到您選擇「應該尊重傳統」跟「無所謂」的標準取決方式。「帝」字上面從橫是重要的,「削」字上面從「小」也是重要的,不過下面的分不出來是「月」還是「肉」好像不要緊?「的」字裏面作橫,非常嚴謹。那「帽」字怎麼右上變成「曰」了呢?該怎麼訂出明確的取決標準?

這些標準眞的是很難訂的。尤其是各說其是時,有時候只能硬性訂一訂,照做就對了。《敎育部標準字體表》(編按:指臺灣的敎育部)其實就是在做這件事,雖然我完全同意《敎育部標準字體表》所選擇的規範有些字很詭異。不過,我也相信,永遠不可能討論出一個大家都覺得合理的結果。

我要強調,我沒有說過「円底『靑』」是「錯字」。當初「黑體-繁」出來的時候,我也多次像zonble抗議這不是錯字,只是字型爲了適應Unified Ideograph原則的結果。我說的是,如果Unicode 9752顯示「靑」,那他是「錯誤造字」,因爲他眞的不符合Unicode規範書。

另外,說官方並非要以「青」字作常用字標準,這也不太對。Unicode採用字源分離原則把「円底『靑』」跟「月底『青』」區分後,那傳統的Big5與Unicode對應時,要對應到哪個碼,這個步驟就是制定標準了。顯然,Unicode會議時,臺灣方面的參考文件是《敎育部標準字體表》。所以決定讓Big5 AB43對應到Unicode 9752的「青」。要說他不是字形標準,也不太能這樣說。

也就是說,本來Big5沒有明訂字形的寫法。但是,當Unicode誕生,接着Unicode跟Big5對應關係確定後,Big5的標準寫法等同就被定義了(現在是臺灣國家標準CNS11643的附件,Big5-2003的部份)。所以當字型廠商去參考Unicode規範文件時,當然所看到的臺灣字源例示字型,會是《敎育部標準字體表》的版本。

我會很堅持作業系統提供的字形應該符合Unicode規範,把「青」(9752)跟「靑」(9751)兩個字碼的字形區分出來,這並不算是特殊情況。而您所認知的一般情況(兩個字碼都造成「円底『靑』」),我反而認爲這必須視爲特殊用途字型。因爲這會讓使用者混亂。例如,「青」(9752)跟「靑」(9751)兩個字碼都造成同一個形狀,這樣使用者打字的時候會不知道選哪一個。同一個檔案也很有可能實際上混了兩個字碼,但是使用者不會發現,因爲他看起來是一樣的!所以我明明檔案裏看得到「靑年」這個詞,但我嘗試搜尋「靑年」卻找不到他,因爲檔案裏那個靑實際上是9752!

要說解決方案嘛。技術上的解決方法很多,創造一套新字型、CID字型,都是方法。造一套專門用來顯示傳統寫法的字型,當然是很好的解決方式。

其實我相當認爲自由資本主義市場上,任何問題只要眞的有需求、有市場,它就會被解決。日本爲甚麼CID字型非常盛行?因爲日本人眞的很在意。像「吉野家」的「吉」上面是個「土」,有些姓「辻」的人會在意他的「辶」是一個點還是兩個點;因爲稱職的編輯很多,有這樣的市場需要,出版社願意採購適合的字型,所以日本的字型業界會去生產這樣的字型。

對岸是很鴨霸把GB18030寫法作爲強制標準,這點無解;但臺灣跟香港從來沒有這樣規定過,所以字型要長甚麼樣子,那是字型廠商的自由,是微軟的自由。我相信微軟會在Vista把字型都改成敎育部標準,一定是經過他的市場調查後做的決定。如果「使用正統字形」眞的是市場上的「基本需求」、「基本權利」,相信微軟不會做這樣的決策。

沒有人不准你用傳統的字形。但別把責任都丟給微軟。不認同微軟的決定,就自己想辦法改變啊。

容我說得難聽一點,臺灣跟香港現實就是「沒有需求」,說得更精準則是「需求不到市場規模」。字型公司根本沒有做不出來的問題,國內公司就辦得到,像華康天天都在做日本的外字專案。但臺灣市場沒有人願意花這個錢找華康做啊。

要說錢傷感情,那談談免費的好了。知道日本GlyphWiki跟「花園明朝」(http://fonts.jp/hanazono/)吧,日本人就是有強烈的異體字使用需求,有志之士就出來架系統、分工,有人負責技術,有人負責造字,沒幾年的時間,各式各樣的所有異體都造齊了,有傳統的、有地區特色的,甚至有只出現在某本古籍的。整套「花園明朝」收錄可能數十萬字形了,比每個廠商的字形都還要完整;而且他的License絕對是沒問題的,不是甚麼拿現有字形偷改的結果。

務實一點,我完全同意可以提供舊字形的web font讓大家使用。應該說web font技術的出現本來就很適合做這種事情。只要社群有辦法製作出一套License沒有問題(ex.不是拿「細明體」去改的)的舊字形檔案開放使用,我相信justfont也會願意提供這套字型的web font服務。

失禮了。

內木一郎, 2013/01/18 18:27 +0800, 2017/05/30 20:30 +0800

分數點回應吧:

一、

i.imgur.com_u9nc07v.jpg「黃」、「艹」的寫法,不涉及所從的部件錯訛,它本身就是一整個部件。這些字的異體中,當然也有較合理者,但可以容後再論,不然就會東扯西拉,把我足以寫一部專書的材料都一次過嘔出來,要了在下小命。至於在下與朋友所改的字型,目前尚未完美,有些字的寫法仍應改善,但閣下所批的兩點,乃因圖太小,讓閣下看錯,以致誤批。看大圖就明白了。

不過,這些寫法的分別,我先不再說。且只用「青」字作例,說過如何解決正體字被打倒、無法正常使用的問題後,回一回氣,稍後再逐字細議。屆時確實要涉及文字訓詁的知識。

二、

不好意思,想問一問,閣下說:「我也多次像zonble抗議這不是錯字」,是否即是指「我也多次【向】zonble抗議這不是錯字」啊?而我不知道zonble是誰,是指抗議「黑體-繁」的網站和文章之作者嗎?(後按:査過了,果然是那不學無術、顚黑倒白、指鹿爲馬的人。)若是如此,更足證明在下批評他一言堂、顚倒黑白之說。

至於閣下說「錯誤造字」,大抵我跟你對「錯誤」二字定義不同,閣下用這二字讓在下很在意。配合上下文,閣下把「不符Unicode規範」就聲稱作錯誤。但這種作法,與那些抗議「黑體-繁」的傢伙,把不符標楷體規範就聲稱作錯誤,有甚麼分別呢?

在下以爲,即使是「不符Unicode規範」,但若該Unicode規範本身有錯或有爭議,字型設計者有意依從Unicode規範以外的標準,那就不應說成是「錯誤」,只應說它「不符某標準,而跟了另一套標準」。不依訛謬的「標準」,並非錯誤;依了不正確的那一套,才是錯誤。

而,「不符Unicode規範」,閣下認爲是很嚴重的問題、基本上是容不得的。但且看日本,不符就不符了,它的字形規範有問題,我且只支援其編碼,字形則另有標準。也運作良好啊!個人既指出了Unicode標準在應用上有一些問題,當然認爲應對症下藥,把問題解決。

誠然,像閣下般仍然持着Unicode標準的,在下也尊重,在提供的解決方法中也有照顧閣下的情況。但希望閣下不要輕看在下及同道中人面對的問題——在日常生活的實際應用上,管它的編碼是9751、9752還是甚麼,管臺灣敎育部在跟Unicode對應時弄了甚麼手腳,總之,我要用這個正確、有理、有依據、傳統的字形。這才是一般編輯、作者、出版人員的用字情況。

三、

Unicode官方的確明言它只是替字(Character)編碼,而非處理字形(Glyph)標準。這是Unicode自己說的,這點我沒有不對。所以不少日本字型,兼容Unicode編碼,一樣是符合Unicode,但不取其字形。

閣下說的,是把臺灣敎育部在跟Unicode對應時,所弄了甚麼手腳,一併算進「官方」內。我認爲這樣說易生混淆。臺灣敎育部當然想推廣其字形標準,但這只是「臺灣敎育部官方」,不是「Unicode官方」,兩個「官方」不是同一概念。

而「臺灣敎育部官方」,無疑是一家標準,但也只不過是一家。有符合這家標準的字體,我不反對。但只能依這一家,在下絕對反對。

四、

說到市場問題,若閣下有看我整個系列的文章,不難看到,我由此至始都說主兇是那群顚黑倒白、指鹿爲馬,更發動文攻武鬥的「群眾」,而不是微軟或蘋果。「自己想辦法改變」,你猜我不想嗎?我力竭聲嘶,都扭轉不到「黑體-繁」被那群顚黑倒白的人綁在十架上活活燒死的結局。他的抗議網站連回應欄都沒有,根本不容許他人說句和他意見不同的道理。我可不是神,有甚麼辦法?

唉!務實一點,中文字型工程浩大,既然閣下是我向來尊重的But兄,不是他人,這點在下不用說了。版權問題也確實弄人,除free以外還要顧一大堆條件。不過也不是完全沒法,「花園明朝」是一途,此外還有一些自由字體,也可供發展。在下的《刻石錄》上,側欄有「造字」一章,目前其旁邊仍放着個「working」的小圖示。若待些時候,沒那麼百務纏身,那個小圖示可以撕下,不知But兄可有意共襄大事?

不然的話,也許像我在接下來會刊出的〈說文:不知丹青,枉談漢字〉裏所言,只能留待CID普及,只能留待日本人去保存漢字的傳統瑰寶。唉……

五、

至於But兄提到的搜尋問題如何解決?系統大可把「青」(9752)、「靑」(9751)掛上關聯。使用者可以開啟關聯,輸入「青」(9752)或「靑」(9751),都搜尋得到 ;也可以關閉關聯,只搜尋「青」(9752)或「靑」(9751)其中一者。若有用google,可見他們已實行了類似的解決方法。比如你在Google裏輸入「靑」(9751)字,它會問你是否要搜尋「青」(9752)。

若碰上這種情況,要分別顯示及搜尋其中一個異體,那就是我這系列文章中所說的「特殊情況」——不是一般用字時考慮的狀況。有做過出版編輯的朋友,應該會比較明白,就如同我之前說「一個稱職的編輯,不論用甚麼技術……」那段落所言。

若要不統一字形,時而顯示某種寫法,時而顯示另一種,這種情況,在下指出是種「特殊需求」,But兄則認爲這才是正常情況。我也且不爭辯何者「正常」何者「特殊」了。畢竟程式語言師的側重點,與出版編輯的着眼點向來不同。但最起碼,不要剝奪大家顯示出這個傳統字形的權利。

最後,失禮了。雖然大家看法不同,但都能指出具體因由,交換彼此意見,個人覺得這樣的談話是理性和有意思的。

But Ko (由錄主從fb搬運過來), 2013/01/18 18:35 +0800, 2013/01/28 05:35 +0800

抱歉下午有點太激動了。

一、

好像有點能懂又不是完全能懂。我想如何訂出明確的準則,是一個重要的工作。

P.S. 我喜歡這個「月」,不過有沒有「前」(舟月)的範例圖呢?

二、

嗯,是「我也多次向zonble抗議這不是錯字」。

我沒有說「所有字型」不符合Unicode規範很嚴重,我是說理想上「系統字型」必須符合,因爲做爲系統UI文字,平常在搜尋啦、認字之類的,容易接觸到系統字型。而系統字型有字形無法分辨的情況時,就有可能造成困擾。

至於您說日本「支援其編碼,字形則另有標準」這點我不認同。日本是對這個問題最吹毛求疵的,應該多數商用字型的預設字,都是符合JIS、Unicode標準的。(不過JIS有舊標準、新標準,很多廠商還有分別販賣舊標準跟新標準兩種不同字型。) 確實有用CID去解決傳統字形問題,不過不會放在預設的glyph,都是放在要人工選擇的次要glyph的。Windows Vista的系統字型符合JIS新標準,按照日本常用字表,「青」也是寫作「月底『青』」。「円底『靑』」也是要選出來的。

三、

但是,Unicode跟Big5的對應表,也是Unicode組織官方的參考附件之一啊……Big5的「青」對應到Unicode,是對應在9752,不是9751,這就是嚴格標準,不能亂改的。每個作業系統、瀏覽器等的對應表都是9752,不遵行它,也是會出大事的。

四、

雖然我不認同「円底『靑』」是「錯字」,但zonble他們會這麼激烈要求,還有這麼多人聯署,這也表示市場確實不少人比較喜歡看到近楷形的新寫法囉。這是市場現實。

五、

關於搜尋技術。其實您說的這個方法,非常不容易。但,「顯示字型」是系統的工作,「搜尋」就是應用程式自己的工作範圍了。Google做得到那是因爲Google的專業是搜尋,他們是做這個維生的;但要去要求每個應用程式在搜尋時都要去考慮漢字文化的異體相容,這就是大事了(而且,中文、日文環境下,關聯相容集合還不一樣!!!)。 就算Word有去掛上關聯,沒有掛上關聯的應用程式還是沒辦法處理,成本是相當可怕的。

如果只是要解決「編輯要顯示傳統字形」,這是編排軟體的工作,應該讓這種傳統字形的字型,限縮成特殊字型,在編輯軟體自己去使用,別影響到編輯文章以外試算表、資料庫……各式各樣其他應用。

而瀏覽器,現在已經有web font技術了,不用擔心系統字型沒有,別人的電腦就看不到。Web font還可以跨越不同OS顯示相同的字型,效果更好。

六、

給個良心的建議:

1. 如果有一些精力的話,先別放在「改字型」上面。因爲改別人的字型檔,改到怎麼滿意,都會有侵權問題。尋求合法的方案吧。

2. 我剛剛確認過,GlyphWiki(「花園明朝」的字形來源)的著作權政策是完全開放使用的。如果你們覺得花圓明朝的字型風格還能接受,那應該用GlyphWiki來做是最快的。

3. GlyphWiki有提供「自動產生自訂字型檔」的功能(超強!)你可以在他系統上編一個表,註明Unicode哪一個碼位,要哪一個glyph。整個表編完以後,就可以下載成一個TTF檔。

4. 於是你可以花時間去編這個表,要做的工作只有編表(雖然也是有幾萬字)。但是,不用從造字開始,拉曲線。我相信幾乎各種傳統的寫法,GlyphWiki裏都有人造過了,要做的只有去整理出這個表而已。你可以把9751、9752都選擇9751的glyph。眞的欠缺想要的glyph,在GlyphWiki上造字也很快。

5. 編完表以後下載的TTF,就是你所要的全部是傳統寫法的Unicode字型檔就完成了。而且他授權上完全合法,可以自由複製使用,也可以作爲web font使用。

6. 要在網路上公開使用的話,因爲他授權上可以在網路上公開,做爲web font沒問題。這可以跟justfont談談看,借用justfont平臺來提供這套字型的可能性。也許要收些低廉費用,這個我不能作主。XD

內木一郎, 2013/01/18 18:38 +0800, 2017/05/30 20:42 +0800

不啊,說理也很清楚,言辭也有板有眼。反而在下說話一向挺「岩岩巉巉」,太過顧着把點說出來總不懂圓滑,希望沒有令人不舒服,還望見諒m(_ _)m。

一、

i.imgur.com_oajv8ub.jpg的確。訂出明確準則是重要的。然而,哪個字應如何訂,就留待以後說了。「舟月」可見右方附圖:

二、

二之1)果然如此。唉!也許我對Zonble那幫傢伙的評論,或者說及他們弄出來的流毒,眞的激動了,不過自問激動得有理有據。要是他們說「不喜歡」這種寫法,想「讓使用者自行設定,選擇自己喜歡的寫法」,爲此而爭取,那我無話可說。但他們直接指鹿爲馬,以錯爲正,把對的說成是錯的,並爲此煽動大眾發動文攻武鬥。這種做法,與大陸那一大堆政治謊言,以及鼓惑人心的手段,有何異哉!

若他們肯說理,留個聯絡途徑讓其他人說之以理。別人有理的話,就改正自己不對的地方。這是一場理性的群眾運動指揮者,必須承擔的責任。要是高擧謊言卻容不下異見,沒有討論空間,大石壓死蟹,別人指出其誤時就選擇性失明,那就絕對是反智、反理性。我以爲只是在下人微言輕,我的發文被他當成是junk mail或noise,而直接delete掉或無視掉,看也不看。雖然是憤怒,但仍只假設他由此至終都是「無知」,不知道「円底『青』」等寫法並非錯字。原來,連But兄也跟他說過了這問題,他並非「不知」,而是「明知而裝作不知」,故意不聽!他明知其說法不對,卻仍要繼續指鹿爲馬,顚黑倒白,知道眞相後,仍繼續大聲說與眞相相反的話!這就是欺騙公眾,故意向大眾隱瞞並扭曲眞相,以達成他那反理性、反文明的目的了!那可比在下初時的想像更卑鄙不堪!!

二之2)字型支援不同標準方面,其實大家的分歧並沒有初時看到的那麼大,大家都贊同可以有不同字形的字體,去應付不同選擇或需求。對吧?只是預設值是甚麼,這方面有分歧而已。我想,你的預設值比較程式語言師,我的比較出版編輯吧。

對此,我甚至覺得預設值在技術上也可用使用者設定。要是系統本身帶有「正黑體(康熙)」、「正黑體(臺標)」、「正黑體(Unicode)」三隻字體,那麼平時顯示哪種字體作預設,就只是一個控制臺裏的選項而已。屆時我寫一篇blog文,也可以按需要,這裏指定顯示「正黑體(康熙)」、那兒指定顯示「正黑體(Unicode)」。沒指定地方的就依使用者預設值,指定了的地方就依選擇而顯示。問題不就解決了嗎?這不是誰都能滿足了嗎?

二之3)日本的具體情況,你說得對。我先前的表述有所概括,你明白我的意思便行。然而,要選擇並非難事,在InDesign裏,我試過用小塚黑體,並一次過把字都轉作傳統模式。雖然有些轉錯,例如「翻」轉了「飛」字旁的寫法。但類似的方法,就可以解決問題吶。只是CID仍限於Adobe旗下數款軟件,未普及到瀏覽器、一般文書軟件(如Word)、網頁編輯軟件等其他軟件中。結果在下的苦惱仍在——在下的苦惱,並不單單是「編輯」要顯示正統字形。能使用正統中文字形,應是每個中文使用者,在不同軟件中都應有的權利。

三、

所以就造成Unicode官方說它不是要作Glyph標準,但字型廠商依Unicode標準設計字型,就變成摧殘傳統字形的實際情況。這個我可不知是可笑、苦笑、可嘆還是可悲了。像在下以前,安裝了「文鼎隸書U30」,卻發現本來用「文鼎中隸書」顯示正確的字,轉了「文鼎隸書U30」後就變了形。莫說「青」從「円」部件變成「月」部件,連「半」也由「ハ」部件變成「丷」部件。也許我以後只可以選擇「不符Unicode字形」的字型了(苦笑)。

這種情況,顯示跟Unicode官方的說法背道而馳,變成由Unicode限制字形(Glyph)寫法了。

由一份非眞正處理很具體的字形(Glyph)細節之「標準」,去決定很具體的字形細節寫法,是不當的。

四、

「市場現實」只是主觀喜好,而且會變的。要是他們說明這只是主觀喜好,該行動只是爭取他們的主觀喜好之選擇權,那我無話可說。但他們的行爲,遠遠逾越了客觀事實。這正好超出了面對眞相的底線、原則。唉!!

而且這個「市場」到底有多現實,在下認爲大有商榷之處!

五、

搜尋技術的處理方案,理論已說過了,在下不諳電腦編程,相信實踐成本等問題,But兄所知遠比我多。有時成本未必是長遠問題,長遠來說若有需要,相信會有相關投資、開發的,但時間卻是問題。正如web font技術有了,這點在下很支持。只是對在下的需求來說,還要時間等耐合用的字型。

六、

也謝謝良心建議。其實修改字型檔也不一定侵權,因爲已有open source的漢字字型檔——也要感謝日本人吶,當中很大部份都是他們的貢獻。但這建議確是另一個方法,而且應該較省時。只是有些朋友覺得它外框粗疏。我可以問問各方字型愛好者有沒興趣,這可能可以快些得到一隻傳統字形的字體(及web font)。

內木一郎, 2013/01/19 07:34 +0800, 2013/01/28 05:36 +0800

今天我整理過facebook上But Ko的回應,把它搬至本錄中。同時,發現我對But兄說的內容,有數點尚欠清晰回應,宜作仔細說明:

一、Unicode字體先天不能避同形

But兄多次強調,他認爲若作預設字型或系統字型,就要依Unicode對同一個字不同寫法的不同編碼,製作出異體的字形,避免同形。這樣做才能應付某些情況的需求——例如程式人員在試算表裏分辨兩個不同編碼的字。

可是But兄的主張,實踐起來是不可能的。即使現在Windows那「掛着細明體名字的標宋體」,都達不到But兄的要求。爲甚麼?因爲Unicode有些編碼,收錄了完全一樣的字形。好像5140是「兀」,FA0C也是「兀」;55C0是「嗀」,FA0D也是「嗀」。同一個「金」字字形,有91D1、F90A兩個編碼;同一個「車」字字形,有8ECA、F902兩個編碼;同一個「龜」字字形,更有9F9C、F907、F908三個編碼。試問有哪款字型,其設計師可以把5140與FA0C造出明顯的分別,讓人一看就知哪個是5140的「兀」字,哪個是FA0C的「兀」字呢?

因此,Unicode本身就令人無法避免同形。要眞的應付But兄所言的需求,以字形遷就Unicode並非良策。因這個不周之策,使正統字體不能正常地獲大家使用,更絕對是本末倒置。在下認爲比較好的解決方法是:在整個作業系統中,或有關的軟件裏,都能有快捷的方法,顯示一個字符的Unicode編碼。比如現在於Word或Wordpad裏,按「Alt+X」鍵,就會讓鼠標前方的字符變成Unicode編碼。再按「Alt+X」鍵,就會變回字符。這才是個根本方法,讓人眞眞正正地分清不同編碼的字元。

二、關於異體字的搜尋功能

But兄不太認同在下指出的異體搜尋功能,認爲會大大更加軟件開發成本。的確在下對編寫軟件的知識,絕不可能勝於But兄。不過仔細想想,其成本是否眞的如But兄所言般高昂呢?那怕是現在的Word,在搜尋時,有些字元是可以選擇是否一併搜尋的。請看看名爲「類似音符(日文)」的搜尋選項。無論是全半形假名、長元音、舊假名、「ぢ」與「じ」、「づ」與「ず」、「ば」與「ヴぁ」等,甚至連「變形漢字」,都可以由使用者自行選擇是否視作相同,一併搜尋。換言之,只要勾選了「變形漢字」選項,搜尋「国」字時,Word會一併找出「國」字和「圀」字。在But兄擔憂成本之際,Word已解決了這問題。

其實,繁、簡、日、韓等不同標準的異體對應編碼表,都有現成的。而且這項技術的應用,已降臨在我們身邊。成本之憂,眞的有這麼重嗎?

三、對「市場現實」的商榷

But兄認爲:「zonble他們會這麼激烈要求,還有這麼多人聯署,這也表示市場確實不少人比較喜歡看到近楷形的新寫法囉。這是市場現實。」我已說過對此甚爲不同意。現在說清楚一點。

縱觀整個臺灣,多年來的路牌都使用正統字形,每天印行的報章、雜誌,大都使用正統字形,刊印出版的書籍亦然。即使近數年,臺灣敎育部那「標準」字形使用量上升了,但在上述各範疇,其使用率都遠遠不及正統字形(即所謂「舊字形」)。若「市場現實」眞的如此擁抱「近楷形的新寫法」,這些天天面對民眾,甚至要靠銷量來賺錢的範疇,不是一早就應改掉嗎?難道它們不會天天接到投訴嗎?

因此,我看不到有如此的「市場現實」。

But兄所說的所謂「市場現實」,只不過由「黑體-繁」的批鬥事件、由一些「果迷」的身上看到。當時「果迷」看到字型變了,新的字型醜了,感到不滿。誠然,從字體的美術設計上,「黑體-繁」的確比過去的「儷黑」醜了。但「果迷」並沒有對此作客觀論證,反而訴諸非理性的主觀情緒,發表偏激的、情緒化的言論。

這時,那個叫zonble的騙子——據査他似乎在「果迷界」裏頗有影響力、號召力及傳播力——就順着這股情緒,發表一大堆歪離事實、卻正好應合這股非理性情緒的謊言謬論,指鹿爲馬,顚黑倒白。他更明知自己說的東西有錯,也拒絕更正,繼續散佈失實之言。這是故意撒謊,欺騙大眾,蠱惑人心。受主觀非理性情緒支配的一群「果迷」,自己不作査證,就相信了這堆符合他們當時情緒的謊言,三人成虎,集體把對說成錯。這個過程裏,zonble本身的影響力、號召力、傳播力,正好發揮作用,其謊言不停被散佈、滾大,形成了文攻。

Zonble不但公然撒謊,扭曲事實,更用具煽動性的言詞,「呼籲」(實爲煽惑)大眾透過各種投訴、擧報手段,聲稱依正統寫法的字形「有錯」、「有bug」,形成一股盲目的勢力,超出了文攻,進行了實際上有殺傷力的攻擊,即是武鬥。

在旁的人看到,「文攻」已聲勢浩大,「武鬥」更鋪天蓋地,自然以爲這是所謂「主流」、所謂「市場現實」。但它其實只是個別人士製造出來的幻象,經不起道理論證的考驗。歷史上已有太多的同類事件。

對於Windows更換系統字型,我在噗浪上也有噗友指出,這可能也是一些「果迷」日吵夜吵,聲稱Windows字型差劣和不美觀的「成果」。多年來,不見得有許多Windows使用者,對細明體說過甚麼。反而是微軟未經任何市場諮詢,就把細明體換成「掛着細明體名字的標宋體」後,不少Windows使用者都說字型變醜了。但微軟都闊佬懶理。到底Windows改字型,是眞的因爲所謂「市場現實」?還是臺灣當局跟微軟做過甚麼?抑或是其他原因?

四、正統字形使用權

我在解釋正統字形使用權時,用了在下做編輯的經驗。可能因此讓But兄誤會,以爲只有像在下般的編輯,才需要顯示或使用正統字形。於是把它說成是「這是編排軟體的工作,應該讓這種傳統字形的字型,限縮成特殊字型,在編輯軟體自己去使用,別影響到編輯文章以外試算表、資料庫……各式各樣其他應用」。

有此誤會,可能是在下說得不好。非常抱歉。

其實,有權使用正統字形的,並不應只限於編輯。這決不是編輯獨有的特權!能使用正統中文字形,應是每個中文使用者,在不同軟件中都應有的權利。

打個比方:若有作業系統或程式,強迫法語使用者放棄正確的法語拼寫「café」,要改作非正統的「cafe」,你猜法語使用者會否感到自己應有的權利遭剝奪?會否感到受侮辱?

一種語文的使用者,自然應當有正確地使用該語文之權利。誠然,若他自己要選擇不正統的寫法或讀法,這樣做可能有語文老師會反對,但我個人仍會尊重。然而,若他要選擇正統的寫法、讀法,這權利在任何情況下都不應遭剝奪。否則,就是對該語文的所有使用者,以至對整個語文文化的踐踏,是極爲反文明、反智的惡行。

在下這系列文章裏所指出的問題,並不單單是「編輯」要顯示正統字形。能使用正統中文字形,應是每個中文使用者,在不同軟件中都應有的權利。若有其他需要,甚至因個人喜好,想選擇用非正統字形,這種選擇權我不反對,所謂「有得揀,先至係老闆」是也。但,決不能反過來,因爲有些人想選擇非正統寫法,就把大家使用正統寫法的權利奪去!這是面對人類文明不容逾越、不容踐踏的底線!

But Ko (由錄主從fb搬運過來), 2013/01/28 00:58 +0800, 2013/01/28 05:37 +0800

一、

我覺得「兩個『兀』」這個例子很故意。 你應該知道Unicode F900-F22D這塊根本不是CJK Ideograph,而是CJK Compability Ideograph(相容表意文字)。「相容」的意思是根既有的編碼方式維持一對一相容,也就是說如果某個字本來就在某個來源編碼中不小心重複了,爲了維持相容性,只好在Unicode也讓它重覆。像Big5就重複了兀字跟嗀字。

也就是說,Unicode本來就「規定」F900-F22D這個區域的文字只是爲了與之前編碼相容而留的,字形與主表中的文字完全一樣也是「當然」的。會有這一區,只是爲了讓舊有的文件,例如Big5文件轉成Unicode又轉回Big5時,能夠一模一樣。「兀」字不會從這個「兀」變成另一個「兀」。而Unicode組織也「不建議刻意去使用」這一區的文字。

字碼查詢功能太過技術性了,實在難以讓一般人使用。

二、

Word支援了。那Excel呢?PowerPoint呢? 眞的不要認爲只有文字編輯軟體才比較會受到異體字困擾。事實上就經常舊細明體的時代,就經常看到有人搞不清楚「市」跟「巿」的差異(舊細明體上方不做點,所以看起來太接近),在Excel搜尋地址時找半天,不知道爲甚麼找不到的案例(這是有登在很多網站Q&A的)。事實上臺灣人事行政局網站颱風假頁面,到現在還是打成「巿」。

問題是所有會處理到文字的軟體都要去面對這些CJK文字的特有問題,實在太不可能了。連我是臺灣軟體工程師,都覺得程式要去處理這個問題太困難了。更何況大部分的軟體都是不懂CJK的歐美人士寫的。

在Web應用上,如果每次select資料庫,都要比較過所有異體字的組合,資料庫根本撐不住……

三、

市場現實就是:

微軟跟蘋果都是Unicode組織成員。他們訂定策略時,當然會多考慮Unicode相容的問題。

在Vista新細明體改版時期,微軟在日本也把日文字型改成符合日本新的JIS2003標準了。而且委託華康開發的新細明體跟委託Monotype開發的微軟正黑體,兩者都「不約而同?」符合敎育部標準,我覺得根本不是巧合。應該是微軟自己整個亞洲市場政策就決定全面配合當地政府字形標準了。

有人覺得新版細明體好看,有人不喜歡,無論如何微軟沒有感受到強烈的壓力覺得這是個問題。(日本市場微軟在推JIS2003時就有被迫需要提供一些相容JIS1987的技術協助,大概是有大量企業用戶持續跟微軟反映這個問題,微軟被迫有需要回應;但臺灣市場,顯然就是沒甚麼人眞的在意,對微軟銷量不構成影響。)

四、

我的立場很明白:連正統字形定義都不明確了,哪來所謂正統字形使用權?

字型本來就是商業行爲,造字的人造自己喜歡的字,使用的人買自己喜歡的字。

造字的人造了沒有市場的字就賣不掉,買字的人想要沒有市場的字就買不到,如此而已。

眞的想要甚麼字形,買不到的話,就請自己造,或是花錢請人造,不然只能拉倒。

從我旁觀的角度看來,就是這樣。雖然你一直在講「正統字形使用權」,但我根本沒有看到哪個人有「義務」提供所謂正統字形給人使用。

要提供甚麼樣的字型,是作業系統公司、字型公司、字型設計師,基於自己的市場調查跟自己的設計喜好作的決定,如此而已。除了中國大陸不太一樣,那邊有法律規定字型必須符合GB18030字形標準。

內木一郎, 2013/01/28 00:58 +0800

看到But兄的新回覆了。不過在下於上方(fb上1月10日23:52、本錄上2013/01/18 18:38)的發言,則不見回覆。不知是不是fb功能有問題,還是But兄認爲在下之言有理,不再反駁了?

在下使用fb經驗尚淺,fb許多功能都不太清楚,還望見諒。

就But兄的新發言,回覆如下:

一、

其實這些例子並不刻意。平時打倉頡,就很自然的看到兩個「兀」字。接着,舊系統換新系統,又看到有些字被改形了。這些都是日常接觸到的、生活裏活生生例子。編輯也好,一般使用者也好,沒有人打字時,會去確認它是不是放在「CJK Compability Ideograph」區,總之系統能讓他打出來,就用;打不出或選不了,就無法使用。

所以我才指出,不論拿出所謂Unicode標準,還是以其他甚麼原因強壓過來,總之,不准他人把平時能正常輸入的「青」(Unicode 9752)、「精」(Unicode 7CBE)等字造成從「円」部件的寫法,實際上是奪去了大家使用這正統寫法的權利。是種有違人文的涼薄甚或殘酷之手腕。

若要說刻意,個人覺得反而上次But兄說及「鮪」這種同形字問題,比較之下似乎更刻意呢……

至於字碼査詢,其實若要處理技術性的東西,有時就難免有需求。說軟體工程嘛,這本身不就是一項較技術性的東西嗎?就技術性的需求,配備一個技術性的方法去治本,方爲上策。

二、

這項回應,其實也與上方「一、」那一項有關。之前寫「Unicode字體先天不能避同形」,我已想到這一點,但爲免論說過長,爲免一下子傾倒出太多,還是留待有需要才寫。那就是——莫說是同形字,即使對近形異字來說,即使字型裏所收錄的字形長得有點不一樣,但還是有分辨問題。

But兄說「市」與「巿」不分的問題,正好就是我想說的例子。但我必須指出,即使現在用那掛細明體之名的標宋體,仍有不少人打字時分不清兩字。把不分「市、巿」的問題,推諉給舊細明體,是種罔顧事實的狡辯,請恕我不能接受。

我從沒有否定過,在一些需求上,可以使用某種字形,甚至即使明知它是文字學上的「錯字」。英文也有OCR字體,以應符某些技術需要。像But兄般的程式人員編程時,選用一些即使近形甚至同形字,也刻意造出很大分別(甚至爲此而刻意寫錯字)的字體,我個人是接受的。只是不要因有些人想有這種需要或方便,就剝奪其他需要,甚至剝奪事物本來那正統而有實際價值的面目。

因此,對處理不同編碼的技術問題,我也同時指出從編碼上的解決方案,並且指出這才是較治本的解決辦法。透過字型去處理不是不可以,但只是治標;透過編碼處理,卻是更直接的對症下藥。

我不是說馬上就要實現「透過編碼處理去解決」這方案,不是說此刻要實行它的局限都已掃清。但我看到它的實踐狀況,已超越了、突破了But兄原先說的一些限制。它雖被But兄說得這麼沒可能,卻已在現實裏逐步實行,用例還越來越多。

三、

那即是說But兄上方以「黑體-繁」爲例的「市場現實」,並不見得那麼「現實」了吧?在But兄的論說中,「市場」指何者,我看到已移動了、走位了。之前說的市場,似乎是像zonble那些用戶投訴或要求;現在變成了以生產商是否某些組織成員,由生產商配合甚麼組織協定,作主要的衡量準則。明明兩種東西差得很遠……

縱觀許多不同事件裏,「市場」二字,經常是虛無飄渺的、易變形的,卻協助霸權殺死許多理性思潮的兵器。許寶強老師著有《資本主義不是什麼》,對此有詳細探討,在此不贅。

四、

如果在下連番論說,仍讓But兄覺得「正統字形定義都不明確」,可能是在下論說得差,特此再三致歉。然而,如此多次爲在下論說技巧致歉以後,我也得想想,我是否眞的解說得這麼差?同樣是字形愛好者,爲甚麼極限論壇上的朋友看到在下指出的事實、豆瓣上的朋友看到在下指出的事實、以前在北大論壇認識的朋友看到在下指出的事實,但But兄都看不到呢?

說正統字形如何定義,在下說了這麼多。說定出來的具體方案,在下也擧了(見〈說文:不知丹青,枉談漢字〉)。這還眞的不明確?

而,造字型並不純粹是商業行爲,它甚至完全不是商業行爲。在下過去造「日和字集」、造「香港開源字型」時,都不是商業行爲。日本有志之士造「花園明朝」、「M+」及許多開源字型,日本政府提供開源字型等,都不是商業行爲。造字型,更是爲文字的保存和應用問題,爲這文化需求,提供應對方案。

當然,我沒否定過造字可以是商業行爲,我也沒有對商業公司提出與商業上衝突的、矛盾的要求。例如微軟,我沒有說他們要額外花錢花資源開發一款免費的傳統字形甚麼甚麼。只是它們本來就有較接近傳統字形的字型,如今變成掛羊頭賣狗肉。我就提出不應掛羊頭賣狗肉,是「標宋體」就叫「標宋體」,供使用者自行選擇用「細明體」還是「標宋體」,這並不會讓微軟額外多耗甚麼資源。

要是日本有企業用戶有要求,就是「市場」的訴求;Zonble煽惑群眾文攻武鬥,也是「市場」的訴求;在下和同道中人的說法,就不是「市場」的訴求。那麼,在下未免要質疑,「市場」二字是否有清晰定義?還是,它成爲對某些聲音、某種意見涼薄的遁詞,傷害了理性討論、傷害了公平?

在下主觀希望,在下一直說的涼薄、踐踏,只適用於指鹿爲馬、顚倒黑白、故意說謊、煽惑群眾的那些無恥之徒身上。

內木一郎, 2013/01/28 00:59 +0800

有點擔心在下又只顧說論點,把話兒說得太死。還望But兄見諒。

補充一點,在下的「正統字形使用權」之議,解決方案可以在民間。之前我提出的方案基本上都是這樣。對不同軟件商,我是有評過是非,畢竟這文化問題軟件商是有能力解決的。但我也沒硬性要求他們非怎麼額外花資源去做甚麼不可。反倒是zonble煽惑群眾文攻武鬥,卻是硬性要求(不,是強迫)軟件商如何如何。細閱在下這系列文章,對軟件商的評議,以及對zonble之指責,這方面的對比應當是明顯、清楚的。

若But兄認爲,在下這樣的評議,已干涉了「市場」,不予認同。那麼,以同一把尺,zonble等鼠輩的干涉不是億倍兆倍以上嗎?那樣的話,在下還望看到公允的評價。

But Ko (由錄主從fb搬運過來), 2013/01/28 01:00 +0800, 2013/01/28 05:37 +0800

老實說我還眞的不太能理解……

事實上,《大漢和辭典》所用的石井細明朝體,是專爲《大漢和辭典》開發的版本。因爲字書有區分五萬多漢字的需要,只好這樣造字(跟Unicode要區分所有字的情況很像)。實際上,一般販賣的照排機所用的石井細明朝體,字型是以日本新字體爲準的。

尤其像是草字頭4筆的部份,這完全是個特例。今日日本市場裏,我還沒看到哪個字型草字頭是4筆的(包括OpenType的異體字選擇)。

寫研跟森澤銷往臺灣的照排機,多數也是日本新字體爲主。只有「部份」常用字有調整爲繁體字。好像http://www.bookweb.com.tw/inpage-hs/in0409-2.jpg,是《漢聲小百科》的內頁,應是使用照排排版。可發現當年楷書字樣就是「從入的『内』」、「從殳的『没』」,也相當從俗。

您的說法是「臺灣敎育部不知道日本字型含金量多高」,實際上當年的情形是當年坊間能用的照排字型多數是日本的簡體。「從丷的『説』」、「從己的『巷』」、「從亚的『晋』」、「日本新字形『発』」等大量異體,都充斥在臺灣刊物。敎育部才決定來編製標準字體。

當然,敎育部最後定出來的標準,有些部件決定從俗。但這也沒有這麼不堪,如同「在」字現今實在沒有理由寫成「扗」。

舊版細明體也絕沒有你說的這麼尊重傳統。只是他碰巧用了傳統「靑」部件;然而像「最」之類的部件就不太準確。其「言」字頭作橫,與其說是尊重原理,不如說只是設計巧合(如「音」、「郎」等字多做豎),事實上日本也有很多明體、黑體字型,「言」的上方是作豎的。「草」字頭也是三筆,「月」、「肉」旁無法區分……

如同您給的圖例,《康熙字典》自己的字樣也很奇怪。「育」的上方,《康熙字典》自己就定義是三筆,卻又給了怎麼都看不出來如何寫成三筆的字樣。有趣的是,標宋體傾斜的四筆草字頭。《康熙字典》的字例正好也是長這個樣子。

其實 a) 敎育部標準字體的部件整理 b) 明體筆畫的楷化 是兩個不同議題。現在全混在一起談,焦點就混亂化了。只有 a) 的部份能夠討論正確與否;而 b) 是設計面的問題,並沒有正確與否的絕對標準。

內木一郎, 2013/01/28 01:01 +0800, 2013/01/28 05:38 +0800

But兄剛剛的回覆,都是在說那些我早已說過暫時「先不再說」的寫法分別(因爲要說就會「把我足以寫一部專書的材料都一次過嘔出來,要了在下小命」)。我必須一步一步,如之前所說,先談好「如何解決正體字被打倒、無法正常使用的問題後,回一回氣,稍後再逐字細議。屆時確實要涉及文字訓詁的知識」。

現在,But兄未免太心急了吧?在這回應中,都說那些要容後才說的細節東西。至於我逐點提出的論說,或要求回應的爭議,But兄卻沒有作回覆。

But兄聲稱「敎育部標準字體的部件整理」與「明體筆畫的楷化」是兩個問題,認爲後者沒對錯之分。這種說法我不能苟同,也不符合客觀事實。因爲有些明體筆畫楷化了,正好變成了另一個部件,或者令兩個本來在明體裏有分別的部件相混。而且,即使是同一部件,不同寫法間也有【較合字理者】與【字理較薄弱者】之分。明體楷化後,往往把前者變成後者(例如「橫起筆的『言』」與「豎起筆的『言』」),這就丟失明體本身的優點。當然,具體如何丟失要容後再談,不用急於一時,一次過把不同部份都堆在一起談,以致淹蓋了原本的議題(就像But兄心急地顧着說這些,結果我原先提出的反駁與質疑,But兄都沒回應了)。現在先確立【每個漢用使用者,都有權用正統字形】這基本底線。

唯一要現在就澄清的,是我說的「臺灣敎育部不知道日本字型含金量多高」。But兄單單截了這句出來,看不到前文後理,對我的話有誤解。我在通篇文脈中已清楚表明,那「含金量高的日本字型」,指的是《大漢和辭典》方案——即是在《大漢和辭典》裏,實際上査出來是甚麼字形、如何寫,而不是「一般販賣的照排機所用的石井細明朝體」,不是像《漢聲小百科》內頁的那種字型。而且But兄挑出來的一些舊版細明體甚至《康熙》的不足處,其實《大漢和辭典》大都解決了。

這些字形的細節,以後再詳談。現在不必急於偷步,先回到本來的討論中,對在下提出的數方面,看看還有沒有補充便成。沒有的話,可以作結。

xtricman, 2013/10/11 23:38 +0800

Unicode编码最大的缺陷在于异体字兼容性处理。按照对字编码不对形编码的原则。应该是按照语言文字学研究结果,只有繁体字,简体字,日语独有汉字,喃字,方块壮字等字符进行分别编码。压根就不该有什么字源分离原则和CJK兼容区。Unicode做兼容性设计本来就是超级恶心的,居然在早期版本和晚期版本使用两种兼容性处理方案(早期字源分离原则,晚期CJK兼容区),更是恶心。对于同一个字在不同地区有不同字形的,应该统统使用Adobe CIS技术解决。所以我觉得Unicode应该放弃兼容性,删除那些同字不同形的码位,删除CJK兼容区。一个字只留一个编码。

但是这有俩问题。 第一是繁体字经过大陆简化,和简化后的字按理算同一个字,可是他们之间不是一一对应的,而且简化前后字形差异太大,还是应该分开编码。可这还是有些违背最初的对字不对形原则了。 第二是Adobe CIS技术无法以纯文本形式传输数据。一个字只有一个编码,但要在一个文件里使用字体中的多个字形,就必须存储额外的信息来确定到底要使用哪个字形,最后就无法通过纯文本形式传输数据了。

yixing, 2017/06/09 13:54 +0800

(改正重发) 所言极是!搂主的出发点或许是善意,然而立论本身有逻辑问题。

在下认为汉字必须坚持整体的整理规范思路,并牢固树立“纯文本无(固定)字形”观念,否则就无法在域名网站邮箱等场面使用汉字,也就无法在全球实现汉字无障碍通讯。

希望在中文区有更多更多此类的呼吁。

yixing, 2017/06/09 13:24 +0800

因為查詢一些字體問題偶爾光顧貴網站,見有提及統一碼的編碼對象是Characters,而非Glyphs。感到能注意到這一點的人實在是鳳毛麟角,不覺想請教一下:

既然統一碼的本意原本是不介入各地規範,即是說只決定漢字碼位,字體則悉聽尊便(本人認為這個原則是極富科學合理精神的)。若如此,討論“統一碼標準字體”是否就自相矛盾?因為統一碼並未展示“標準字體”,只不過標準文件上為了表示某個碼位而“隨機地”使用了一個具體的漢字罷了。

既然統一碼不設“標準字體”,也就是說統一碼不曾有過對字體字形的主張,那麼是否也就不應該有“統一碼摧殘正體字”一說? 如果說統一碼的確矛盾重重的話,是否應該理解為造成矛盾的編碼思路(IRG成員的認知問題),而不是統一碼本身的問題⋯⋯?

這一連串現象該如何釐清?

(很抱歉在兩處投書,這次修改了一處錯字)

內木一郎, 2017/06/15 02:09 +0800, 2019/01/11 19:10 +0800

首先,兩處投書會造成混亂。既然這兒回應版本修改了錯字,那麼一郎就刪去另一處的版本,集中在這裏回應。請見諒。

誠然,Unicode的本義,確是只處理字碼,至於每個字碼所載之字形,本當按各地文化裏本身的寫法來設計。若Unicode實技操作出來時,有嚴格依從他們的初衷,有極力去避免違背他們初衷的結果出現,那麼的確如閣下所言,不會有「Unicode摧殘正體字」的現象出現,那麼,屆時一郎也不會寫出這篇文章。

不過事實上,處理Unicode的人造出來的實際結果,並沒有眞的依從他們說的這初衷。他們的「標準」文件上,用來展示一個碼位的字樣,絕不是閣下所言的「隨機」,而總是以陸規先行,接着就是臺標,之後才到其他字形。而且像《康熙》或《大漢和》等學術標準,更不獲收錄在「標準」文件上。在Unicode文件上收錄、獲Unicode背書的,往往就只有那些違反正體漢字之道的政權「標準」。於是,對字型廠商或軟件商來說,依從Unicode標準,就可能變成依從政權「標準」的遊戲。客觀上形成了摧殘正體之實。

要是Unicode有秉持他們所說的宗旨,那麼他們的編碼在字形分或合的處理上就不應如此矛盾無道,造成了不同碼位間有字形對立之實;他們的「標準」文件也不應只爲政權「標準」字形背書,應公平地廣泛收錄各學標準字形,並使他們跟各政權「標準」平起平坐。這才不致於造成客觀上摧殘了正體之實。

一郎之言,乃依據客觀事實上正在發生之事,並非在下立論有「邏輯問題」,而是Unicode他們做出來的事並不符合他們宣稱的初衷。希望閣下能認眞看清事實,收回指稱一郎「立論本身有邏輯問題」這不實指控。

yixing, 2017/06/24 08:26 +0800

一郎閣下既認識到了統一碼的編碼原則(A),也認識到沒有嚴格按照其初衷設計之錯誤(B)。

請問 A 和 B 是由同一集團?或是工作機構?還是由什麼具體勢力來操作的麼? 把 A 和 B 視為同一集團或機構或勢力的行為,是根據事實在說話,還是有什麼特殊的理由?

——如果能回答清楚這些問題,閣下對“他們”的憤慨才有現實對象可以著落,“統一碼摧殘正體字”一說方能成立,是麼?

如果統一碼的編碼原則制定者,是對漢字不甚瞭解的一個群體,而表意文字小組又是誤解了編碼總原則的另一個群體。假如我們能分得清這兩個行為並非一回事,兩個行為的主體沒有絲毫的同一性,那麼對“他們”的憤慨還有甚麼心理現實性可言? 若如此,閣下是否能夠收回“統一碼摧殘正體字”一說? (這個網頁不必刪除,只需表示一下即可,因為估計誤解的人不計其數,可以讓大家都瞭解瞭解)

如果明明知道統一碼的編碼對象是Characters,而非Glyphs。而又稱“統一碼”(請注意您未說表意文字小組)摧殘正體字,是否有點兒張冠李戴?而且自相矛盾?

另外,請注意提醒一下閣下並非是“指控”,充其量是“指出”罷了,不必著意渲染。

內木一郎, 2017/07/10 04:03 +0800, 2017/07/10 04:26 +0800

理論上,在非洗腦等特殊操作下,任何人都有自己的個人意志。因此,在任何公司、組織、團體、旗號或名目之下,總可能會有內部意見分歧的時候。閣下這種強調要在「Unicode製訂者」之下區分出A和B兩種人的「邏輯」,其實是站在一個必定對的高地上說話。

不過,強調到如此細末的小節,有時不但無關討論的宏旨,甚至反而會擾亂對宏旨的思考。因爲語文是一套很有限制的符號。受到現實的條件限制,我們說話時,總會有所省略。不省略「A和B是兩種人」這一點,是否眞的有助對討論宏旨的思考?有助的,就不應省略;無助的,省略更好。

閣下強調的「統一碼的編碼原則制定者」,到底是誰?他們有沒甚麼發言,突顯他們跟「表意文字小組」的不同?兩者之間對「Unicode時而合併編碼,時宜區分編碼,摧殘了正體字」之問題,有沒有明顯的立場上角力、爭持等表現,可供大家看到,可供大家作出與討論宏旨尤關的探討?

一郎無法看到所有Unicode文件,不敢說沒有疏漏。但在下所目睹者,非但看不到「統一碼的編碼原則制定者」跟「表意文字小組」對此問題有任何意見相左,而且由包含漢字的Unicode 1.0.1公佈起,就已存在着「Unicode時而合併編碼,時宜區分編碼,摧殘了正體字」這問題。一郎所批評的問題,在Unicode始創不久經已存在。從客觀現實呈現出來的現象,一郎實在看不到區分兩者,對思考眼前這問題有何幫助。Unicode幾乎時從一開始就不遵守它自己宣稱的規則,一開始已經是邊宣稱只對字(Character)編碼,邊把同一字的不同字形(Glyph)編進不同的碼,直接造成此問題,直接摧殘了正體字。

正因Unicode從一開始加入漢字時就已經如此,它是打從起點就已摧殘正體字。我的立論完全符合客觀事實,並無任何誤解,亦無張冠李戴。一郎拒絕收回一個符合客觀事實的立論。倒是閣下的強辯,似乎有刻意要洗白「統一碼的編碼原則制定者」之感。可是即使洗白了它,也對現在的討論宏旨——Unicode對正體字在客觀上的摧殘,沒有任何裨益。

最後,閣下措辭的強烈,一郎着實感到是指控,而非「指出」。正如一郎對Unicode如此摧殘了正體字,也是指控它,而不僅僅是指出。發言措辭如此,非一郎着意渲染。

P.S.既然閣下用這種指稱一郎「誤解」了Unicode,那麼對於上方But兄那種堅持要「9752」、「9751」兩個碼位分形的說法,又如何看?

yixing, 2017/06/24 08:32 +0800

致樓主: 真抱歉,對自己的跟帖做了修改,以便容易理解,請刪去前次發言。謝謝!

dine, 2017/07/20 17:13 +0800

我是大陸人,從小習慣簡化字和大陸新字形,但是有時候爲了與日文韓文相通也想使用舊字形。然而像知乎、貼吧這樣的網站都衹能輸入純文本,不能設置字體或語言信息,有的時候想用舊字形,用 Unicode 分立出來的編碼(如 U+9751 靑),便能在字形層面上獲得保障。然而對於 Unicode 未分開的編碼(如 U+76F4 直),就無計可施,衹能任由這種在日文、韓文語境下頗爲怪異的字形飛得到處都是。

另:justfont blog 好像在用 cwTeX 明體的網絡字型。

內木一郎, 2017/08/29 06:26 +0800

三年前,字友趙瑾昀兄在其《知乎》網站專欄上寫了這篇文章〈書體與漢字的區別〉,也說到Unicode同一個問題,大家可以參考:https://zhuanlan.zhihu.com/p/19751881

Timothy Chou, 2018/01/07 02:56 +0800

其實應該是有需要關注,不過在台灣似乎沒人在關注這種東西

我個人興趣是大眾運輸,坊稱公車迷/鐵道迷,從指標、告示到路線圖、時刻表都常有接觸

時常在想,指標、告示、路線圖、時刻表這些東西是否應該遵照教育部標準、或至少是常用寫法,避免作錯誤教材或是有人會看不懂?

在研究歷史的時候,也會有舊字型的問題,腳脚問題很常見

另外常碰到的問題是,站名常常跟著地名,不一定都是常用字,例如新北市的錦繡站、𫙮魚坑

呃…這個字還會造成我顯示上的問題…

總之照理來說,有需求應該會有市場,可在台灣連要正確顯示地名都有困難…

Timothy Chou, 2018/01/07 03:07 +0800

順便一提,台北車站的舊式發車時刻表(翻轉板),自強號的強一直是作强,這幾年變更發車站需要加字的時候才一併改掉

輸入您的意見. 允許使用維基語法:
 
說文/unicode摧殘正體字.txt · 上一次變更: 2017/05/30 20:07 +0800 由 ichirouuchiki
回到頁頂
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0