差異處

這裏顯示兩個版本的差異處。

連向這個比對檢視

Both sides previous revision 前次修改
下次修改
前次修改
說文:unicode摧殘正體字 [2013/01/10 04:17 +0800]
ichirouuchiki [Unicode摧殘正體字]
說文:unicode摧殘正體字 [2020/04/20 09:17 +0800] (目前版本)
ichirouuchiki
行 2: 行 2:
 ====== Unicode摧殘正體字 ====== ====== Unicode摧殘正體字 ======
  
- 不學無術的「果迷」,給「黑體-繁」(又稱「Heiti TC」)所扣的帽子,最主要是指稱它「寫錯字」。正如在下連日來的論證,已說明他們口中所謂的「錯字」,是如假包換的正字,是符合字理的寫法,是符合《康熙》、《說文》等傳統權威字典的字形。眞正寫錯字的人,是他們自己。+ 不學無術的「果迷」,給「黑體-繁」(又稱「Heiti TC」)所扣的帽子,最主要是指稱它「寫錯字」。正如在下連日來的論證,已說明他們口中所謂的「錯字」,是如假包換的正字,是符合字理的寫法,是符合《康熙》、《說文》等傳統權威字典的字形。要是嚴格地遵從字理而論,眞正寫錯字的人,是他們自己。
  
  他們另一項給「黑體-繁」扣的帽子,就是指它部件寫法不統一。例如《[[http://​zonble.github.com/​tcfail/​|TCFail]]》網站上,負責人說:「同一個部首的許多字,也往往沒有依照一套固定的造字規則,例如『清』的『月』是寫成月,但是『晴』或『請』則寫成了日文貨幣單位『円』,毫無規則可言。」  他們另一項給「黑體-繁」扣的帽子,就是指它部件寫法不統一。例如《[[http://​zonble.github.com/​tcfail/​|TCFail]]》網站上,負責人說:「同一個部首的許多字,也往往沒有依照一套固定的造字規則,例如『清』的『月』是寫成月,但是『晴』或『請』則寫成了日文貨幣單位『円』,毫無規則可言。」
行 8: 行 8:
  若有細讀在下之前的〈[[說文:​劣字驅逐正字|劣字驅逐正字]]〉,應該看到我的解說:問題關鍵在Unicode的編碼。換言之,這群人連眞正問題都沒査清楚,把Unicode編碼不善的賬,算到「黑體-繁」的頭上。  若有細讀在下之前的〈[[說文:​劣字驅逐正字|劣字驅逐正字]]〉,應該看到我的解說:問題關鍵在Unicode的編碼。換言之,這群人連眞正問題都沒査清楚,把Unicode編碼不善的賬,算到「黑體-繁」的頭上。
  
- 理論上,Unicode只是編碼標準,不是字形標準。因此其官方說法是:它只對字(Character)編碼,而非字形(Glyph,每個字的具體形狀、寫法)。陸、港、、韓的「港」字右下從「巳」,日本的「港」字右下從「己」;港、、韓、日的「角」字中豎不穿頭,大陸的「角」字中豎穿頭;港、「起」字從「巳」,陸、日、韓從「己」……這些異形同字,Unicode都不分別編碼。例如「港」就是「6E2F」,不論從「巳」還是從「己」。+ 理論上,Unicode只是編碼標準,不是字形標準。因此其官方說法是:它只對字(Character)編碼,而非字形(Glyph,每個字的具體形狀、寫法)。陸、港、、韓的「港」字右下從「巳」,日本的「港」字右下從「己」;港、、韓、日的「角」字中豎不穿頭,大陸的「角」字中豎穿頭;港、「起」字從「巳」,陸、日、韓從「己」……這些異形同字,Unicode都不分別編碼。例如「港」就是「6E2F」,不論從「巳」還是從「己」。
  
- 然而,爲了相容不同地區的編碼,Unicode又有「字源分離原則」。好像日本JIS編碼同時收錄了「剣」、「劍」二形,Unicode爲了與之兼,即使它們是同一個字,Unicode也分別給予編碼:「剣」是「5263」,「劍」是「528D」。+ 然而,爲了相容不同地區的編碼,Unicode又有「原規格分離原則」(又譯「字源分離原則」,但並不是指漢字文字學的「字源」,而是指「來源字集」。爲免混淆,一郎並不採用此翻譯)。好像日本JIS編碼同時收錄了「剣」、「劍」二形,Unicode爲了與之兼,即使它們是同一個字,Unicode也分別給予編碼:「剣」是「5263」,「劍」是「528D」。
  
-<WRAP right 400px><​WRAP center round box> +<WRAP right 400px><​WRAP center round box miku
-<WRAP centeralign>​{{:​說文:​cing_unified.png}}</​WRAP><​poem><​fc #​5F00BD>​★ 橙字是正常Unicode編碼。</​fc+<WRAP centeralign>​{{:​說文:​cing_unified.png}}</​WRAP><​poem><​color #​5F00BD>​★ 橙字是正常Unicode編碼。</​color
-<fc #​5F00BD>​★ 黃字是兼容區編碼,難以正常輸入。</​fc+<color #​5F00BD>​★ 黃字是兼容區編碼,難以正常輸入。</​color
-<fc #​5F00BD>​★ 若只有一個Unicode編碼,卻有兩個字形,表示Adobe以CID技術,在同一Unicode碼內製作了兩個字形,可用Adobe InDesign等軟件選擇心目中的異體字。但在不支援CID的軟件裏,只能顯示其中一形。</​fc></​poem></​WRAP></​WRAP>​ 結果,有些異形同字,被編進同一碼位,有些則區分作兩碼,造成了Unicode內的自相矛盾。「青」字旁的字正是好例子。「靑」、「青」分別編碼作「9751」、「9752」;「淸」、「清」也分別編碼作「6DF8」、「6E05」。每個形態都有一個常規編碼。在Windows 7或8裏開啟「倉頡輸入法」,鍵入「手一月」可輸入編碼爲「9752」的「青」,鍵入「手一月卜」可輸入編碼爲「9751」的「靑」。至於鍵入「水手一月」,則有「清」、「淸」二字可選。這四個字形都能正常輸入——不過有附帶條件:要把輸入法設定作輸入Big-5碼外的字,以及使用支援Big-5碼外的字之電腦字體。因爲在進入Unicode時代前,大家已慣用灣的Big-5編碼去處理正體(繁體)字,它並不支援「靑」(9751)、「淸」(6DF8)。即使今天是Unicode時代,用「靑」(9751)、「淸」(6DF8)二字,仍要冒變成空格的風險——用戶端選了只支援Big-5的字體,以致顯示不到。有些軟件甚至到現在都不支援Big-5碼外字,剝奪了用戶選擇正字的權利。+<color #​5F00BD>​★ 若只有一個Unicode編碼,卻有兩個字形,表示Adobe以CID技術,在同一Unicode碼內製作了兩個字形,可用Adobe InDesign等軟件選擇心目中的異體字。但在不支援CID的軟件裏,只能顯示其中一形。</​color></​poem></​WRAP></​WRAP>​ 結果,有些異形同字,被編進同一碼位,有些則區分作兩碼,造成了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裏開啟「倉頡輸入法」,無論怎麼拆碼,都輸入不到從「円」的「精」、「靖」、「晴」三字。碼不是沒有編,但根本不想你用。  至於「精」、「靖」、「晴」三字,從「月」的字形,分別有「7CBE」、「9756」、「6674」這三個常規編碼;從「円」的字形,則獲編作「FA1D」、「FA1C」、「FA12」。問題是,從「円」的那些「FAXX」編碼,並非常規編碼,而是「兼容區」編碼。於是,在Windows 7或8裏開啟「倉頡輸入法」,無論怎麼拆碼,都輸入不到從「円」的「精」、「靖」、「晴」三字。碼不是沒有編,但根本不想你用。
  
- 以下的字更可憐:「請」、「情」、「蜻」、「靜」、「睛」、「婧」、「靚」、「瀞」、「菁」、「箐」、「倩」,它們都只有一個編碼。字型設計者要麼把它們的字形寫作從「円」,要麼寫作從「月」。除非像小塚明體等日本字型般,支援CID字庫技術,替這些Unicode裏的同碼異體字另行編碼,讓使用者在支援CID的軟件(如Adobe InDesign)裏自行選擇,否則只能二擇其一。若字型設計者,盲從灣那套背棄正統字形的所謂「標準」,用戶根本沒機會選擇正字(從「円」者)。+ 以下的字更可憐:「請」、「情」、「蜻」、「靜」、「睛」、「婧」、「靚」、「瀞」、「菁」、「箐」、「倩」,它們都只有一個編碼。字型設計者要麼把它們的字形寫作從「円」,要麼寫作從「月」。除非像小塚明體等日本字型般,支援CID字庫技術,替這些Unicode裏的同碼異體字另行編碼,讓使用者在支援CID的軟件(如Adobe InDesign)裏自行選擇,否則只能二擇其一。若字型設計者,盲從灣那套背棄正統字形的所謂「標準」,用戶根本沒機會選擇正字(從「円」者)。
  
- 原版「黑體-繁」並沒盲從灣那所謂「標準」,像「請」、「晴」、「菁」、「蜻」等字它都從「円」。但像「青」(9752)、「清」(6E05)等字,爲使它看起來與「靑」(9751)、「淸」(6DF8)有分別,於是就依Unicode寫作「月」字底。這是那些「果迷」聲稱「不統一」的主因。在Windows 2000、XP年代,細明體還是細明體(未變成[[說文:​宋體滾蛋_還我細明|掛羊頭賣狗肉的標宋體]])時,也有這種批評。+ 原版「黑體-繁」並沒盲從灣那所謂「標準」,像「請」、「晴」、「菁」、「蜻」等字它都從「円」。但像「青」(9752)、「清」(6E05)等字,爲使它看起來與「靑」(9751)、「淸」(6DF8)有分別,於是就依Unicode寫作「月」字底。這是那些「果迷」聲稱「不統一」的主因。在Windows 2000、XP年代,細明體還是細明體(未變成[[說文:​宋體滾蛋_還我細明|掛羊頭賣狗肉的標宋體]])時,也有這種批評。
  
- 既然Unicode對這些異體字的處理如此混亂,字型設計者若依從它,只會使字型也變得混亂。若說要統一這些部件的寫法,我同意。但統一的方向,應當是依照《康熙》、《說文》等正統印版字形,而非大陸或灣那套以手寫楷字竄改印版字形的所謂「標準」。換言之,只獲編一碼的「請」、「情」等字,當寫作從「円」部件;分別被賦予兩個碼的字,不管哪個碼位,不論是「9751」還是「9752」,是「6DF8」還是「6E05」,都同樣應寫作「円」部件。如是者,整套字型裏的字形才統一。不論輸入法、軟件對編碼的支援、字型涵蓋的編碼範圍如何,使用者都能顯示出正確的傳統字形。+ 既然Unicode對這些異體字的處理如此混亂,字型設計者若依從它,只會使字型也變得混亂。若說要統一這些部件的寫法,我同意。但統一的方向,應當是依照《康熙》、《說文》等正統印版字形,而非大陸或灣那套以手寫楷字竄改印版字形的所謂「標準」。換言之,只獲編一碼的「請」、「情」等字,當寫作從「円」部件;分別被賦予兩個碼的字,不管哪個碼位,不論是「9751」還是「9752」,是「6DF8」還是「6E05」,都同樣應寫作「円」部件。如是者,整套字型裏的字形才統一。不論輸入法、軟件對編碼的支援、字型涵蓋的編碼範圍如何,使用者都能顯示出正確的傳統字形。
  
- 然而,這種主張也有人反對。在下強烈推薦的傑兄文章〈[[http://​www.ideographer.com/​articles/​article.php?​aid=69|是誰寫錯字?(三)]]〉裏,But於留言欄的回應可作代表。他說:「舊版的細明體在 Unicode 下是有名的錯誤連篇。例如Unicode裏『為』、『爲』是兩個不同的字,但舊版細明體可能是因爲第一版只有Big-5部分(按:宜作『份』),把『為』字造成『爲』了。結果擴充到Unicode範圍後,兩個碼位的文字無法區分。形成錯誤造字。」「例如『柿』跟『杮』是否能清楚區分。……在沒有區分必要的情況下,上面的點(宋體通常是豎)跟下面連貫倒無所謂。但因爲有一個木字旁『柿』跟『杮』會混淆的問題,只好像辦法區分它們……」+ 然而,這種主張也有人反對。在下強烈推薦的傑兄文章〈[[http://​www.ideographer.com/​articles/​article.php?​aid=69|是誰寫錯字?(三)]]〉裏,But於留言欄的回應可作代表。他說:「舊版的細明體在Unicode下是有名的錯誤連篇。例如Unicode裏『為』、『爲』是兩個不同的字,但舊版細明體可能是因爲第一版只有Big5部分(按:宜作『份』),把『為』字造成『爲』了。結果擴充到Unicode範圍後,兩個碼位的文字無法區分。形成錯誤造字。」「例如『柿』跟『杮』是否能清楚區分。……在沒有區分必要的情況下,上面的點(宋體通常是豎)跟下面連貫倒無所謂。但因爲有一個木字旁『柿』跟『杮』會混淆的問題,只好像辦法區分它們……」
  
  對此,我看到But兄的回應有一大盲點:「『柿、杮』之別」與「『為、爲』之別」是兩個截然不同的概念,他卻弄混了。論證有訛謬,結論亦因此有誤。  對此,我看到But兄的回應有一大盲點:「『柿、杮』之別」與「『為、爲』之別」是兩個截然不同的概念,他卻弄混了。論證有訛謬,結論亦因此有誤。
  
-<WRAP left round box>​{{:​說文:​diff_vs_var.png|兩個不同的概念:「不同的字」與「異體字」}}</​WRAP>​ 「柿」與「杮」是不同的字。從「市」的「柿」,粵音「ci2」或「ci5」,北音「shì」,是種植物或水果。從「巿」的「杮」,粵音「fai3」,北音「fèi」,解作削木。這兩個是不同的字,只是字形較像,音、義俱無關係,當然要作區分。然而,「為」與「爲」本來就是同一個字,它們的音、義俱同,只是寫法上有些分別,是異體字。不必專門修讀文字學,也應當知道:處理異體字的方法,與處理「根本是兩個字」的方法,並不相同。兩個不同的字,寫成同一個模樣,就是寫別字。但異體字本來就是同一個字,若無書法等特殊需要,在日常使用下,一般人都會統一取其中一形。平時我們閱讀的書刊、報章,編輯都是這樣做的。+<WRAP left round box miku>​{{:​說文:​diff_vs_var.png|兩個不同的概念:「不同的字」與「異體字」}}</​WRAP>​ 「柿」與「杮」是不同的字。從「市」的「柿」,粵音「ci2」或「ci5」,北音「shì」,是種植物或水果。從「巿」的「杮」,粵音「fai3」,北音「fèi」,解作削木。這兩個是不同的字,只是字形較像,音、義俱無關係,當然要作區分。然而,「為」與「爲」本來就是同一個字,它們的音、義俱同,只是寫法上有些分別,是異體字。不必專門修讀文字學,也應當知道:處理異體字的方法,與處理「根本是兩個字」的方法,並不相同。兩個不同的字,寫成同一個模樣,就是寫別字。但異體字本來就是同一個字,若無書法等特殊需要,在日常使用下,一般人都會統一取其中一形。平時我們閱讀的書刊、報章,編輯都是這樣做的。
  
  我並不反對在某些特殊情況下,有使用者要顯示異體字的不同寫法,把編碼「70BA」顯示作「為」,把「7232」顯示作「爲」。例如這一篇硏究異體字的文章,就有這種需要。但,這種特殊情況,不應影響到以下大原則:一、使用有字理依據的正統字形,是種應獲保障的權利,任何人在任何情況下都不應指鹿爲馬,把有字理依據的正統字形視爲「錯誤」。二、對印版字體而言,在一般情況下,應把寫法上有點兒差異的異體,統一作正統字形。三、能使用正統字形的機會,不應比使用各種訛俗字形低,因此若無特別指定,應以正統字形爲準。  我並不反對在某些特殊情況下,有使用者要顯示異體字的不同寫法,把編碼「70BA」顯示作「為」,把「7232」顯示作「爲」。例如這一篇硏究異體字的文章,就有這種需要。但,這種特殊情況,不應影響到以下大原則:一、使用有字理依據的正統字形,是種應獲保障的權利,任何人在任何情況下都不應指鹿爲馬,把有字理依據的正統字形視爲「錯誤」。二、對印版字體而言,在一般情況下,應把寫法上有點兒差異的異體,統一作正統字形。三、能使用正統字形的機會,不應比使用各種訛俗字形低,因此若無特別指定,應以正統字形爲準。
  
- 要實踐這些大原則,其實不難:電腦作業系統,應以符合正統字形的字體,作系統預設字型。同時,提供各種符合不同「標準」(包括灣「標準」、大陸「規範」、Unicode混亂異體編碼「標準」等)的字體,供使用者按需要選擇。那麼,我平時寫文章,不必擔心輸入法能否打出哪個「青」,不用憂慮軟件是否支援Big-5碼外字,不需害怕讀者的瀏覽器能否正確顯示。總之,輸入「青」字,就必定顯示出從「円」的正寫。到我有需要指定某個異體寫法,或者But兄要擧出Unicode收錄不同的字形時,則可以指改爲顯示另一款系統有提供的字體,以應付這些特殊需要。以Windows的實況作例,目前各種符合不同「標準」的明體和黑體都有了,只要把實爲標宋體餡的細明體易名作「標宋體」,然後再提供回字形依正統寫法的正統細明體和正統黑體,作預設系統字型,問題不就解決麼?+ 要實踐這些大原則,其實不難:電腦作業系統,應以符合正統字形的字體,作系統預設字型。同時,提供各種符合不同「標準」(包括灣「標準」、大陸「規範」、Unicode混亂異體編碼「標準」等)的字體,供使用者按需要選擇。那麼,我平時寫文章,不必擔心輸入法能否打出哪個「青」,不用憂慮軟件是否支援Big5碼外字,不需害怕讀者的瀏覽器能否正確顯示。總之,輸入「青」字,就必定顯示出從「円」的正寫。到我有需要指定某個異體寫法,或者But兄要擧出Unicode收錄不同的字形時,則可以向軟件下令,改爲顯示另一款包含在系統的字體,以應付這些特殊需要。以Windows的實況作例,目前各種符合不同「標準」的明體和黑體都有了,只要把實爲標宋體餡的細明體易名作「標宋體」,然後再提供回字形依正統寫法的正統細明體和正統黑體,作預設系統字型,問題不就解決麼?
  
- 偏偏,現在的情況是:作業系統只提供了符合各種所謂「標準」的字型,卻不提供符合正統字形的字體!大家使用正統字形的權利被剝奪,連用正統字形的權利都沒有,更遑論無特別指定時是否以之爲準了!如是者,受着各種訛體俗字耳濡目染,連大家對正統字形的認知也越來越模糊。漸漸,大家只會擁抱着各種有問題的所謂「標準」,指鹿爲馬、顚黑倒白地,指責符合字理的正統字形是「錯字」——就像那些不學無術的「果迷」,聲稱與「標楷體」(灣「標準」)不符的正字是「錯字」、「一整個不對」、「不應該寫成(如此)」、「毫無規則可言」、「可能是來自日文漢字的寫法」、「根本就是錯字」。也如高擧Unicode混亂異體編碼「標準」的But兄,罵與之不符的寫法是「有名的錯誤連篇」、「錯誤造字」。符合字理的正統字形,不但喪失了獲大家使用的權利,更要背負上「你是錯字」這種無稽的罵名,天有眼嗎?天,有眼乎?​!+ 偏偏,現在的情況是:作業系統只提供了符合各種所謂「標準」的字型,卻不提供符合正統字形的字體!大家使用正統字形的權利被剝奪,連用正統字形的權利都沒有,更遑論無特別指定時是否以之爲準了!如是者,受着各種訛體俗字耳濡目染,連大家對正統字形的認知也越來越模糊。漸漸,大家只會擁抱着各種有問題的所謂「標準」,指鹿爲馬、顚黑倒白地,指責符合字理的正統字形是「錯字」——就像那些不學無術的「果迷」,聲稱與「標楷體」(灣「標準」)不符的正字是「錯字」、「一整個不對」、「不應該寫成(如此)」、「毫無規則可言」、「可能是來自日文漢字的寫法」、「根本就是錯字」。也如高擧Unicode混亂異體編碼「標準」的But兄,罵與之不符的寫法是「有名的錯誤連篇」、「錯誤造字」。符合字理的正統字形,不但喪失了獲大家使用的權利,更要背負上「你是錯字」這種無稽的罵名,天有眼嗎?天,有眼乎?​!
  
 <WRAP rightalign>​--- //​2013/​01/​10 01:07 +0800//</​WRAP>​ <WRAP rightalign>​--- //​2013/​01/​10 01:07 +0800//</​WRAP>​
  
 {{page>​c:​by-nc-sa}} {{page>​c:​by-nc-sa}}
-{{tag>"​中文"​ "​字形字體"​}}+{{tag>"​中文"​ "​字形字體"​}}
  
 ~~DISCUSSION~~ ~~DISCUSSION~~
說文/unicode摧殘正體字.1357762653.txt.gz · 上一次變更: 2013/01/10 04:17 +0800 由 ichirouuchiki
回到頁頂
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0