2020年7月2日 星期四

漢字使用環境的建置 —— 部件檢索更新

Unicode + CNS 漢字

隨著 Unicode 13.0 的到來,部件檢索也作出了更新,這次不僅支援了所有 G 區漢字的檢字,更一舉涵蓋了台灣 CNS  標準的所有編碼漢字,配合全宋體字型,能檢索、顯示的漢字逼近十二萬大關,該是目前漢字使用環境下一個最強而有力的支援工具。

有理拆分 vs. 無理拆分

這一版的拆分資料,我新引入了「有理拆分」與「無理拆分」的概念。所謂的「有理拆分」是按照傳統的漢字構形意義來拆分;而「無理拆分」則是不管構形的意義,直接按字形的形狀切割細分,通常最後可以細拆到一筆一畫為止。舉例來說,像「魚」這個字,按字理是個獨體字,也就是說它自成一個完整形體不可切分。若按「有理拆分」的原則,它就是不可拆分;但若按「無理拆分」的原則,它就可以拆成「⺈田灬」,甚至可以繼續再往下細拆。

顯而易見的,若選擇「有理拆分」,由於拆分只會進行到獨體為止,檢索的響應一定會比較快;若選擇「無理拆分」,由於可能會細拆到一筆一畫,所以速度自然就較慢了。可是反過來說,當輸入「⺈田灬」來檢索時,若選擇「有理拆分」,因為「魚」不可拆分,它就找不到這個字;反之若選擇「無理拆分」則可以。所以兩種方式各有其優缺點跟不同的適用領域,這一版的部件檢索同時內建了這兩類數據,使用者可以依據不同的使用情境,隨時切換。

獨體查詢

如前所述,獨體字是自成一個完整形體不可切分的。可是如果這個獨體字我用正常的輸入法打不出來,又不能拆分開來檢索,那要怎麼找到它呢?除了切換到「無理拆分」的辦法外,這一版還提供一個「獨體查詢」的功能,它能列出該模式下的所有獨體字(請注意:「有理拆分」與「無理拆分」模式下的獨體字是不一樣的喔!)

關於「有理拆分」、「無理拆分」與「獨體字」的認定,這其實是需要一些學理上的專業。我並不具備這樣的專業,因此目前建立的數據可能並不完整,也不見得正確。我只先建立起一個架構,希望將來或許能有更多的專家學者在這個基礎上進一步地幫忙完善這些數據。

細部調整

這一版的部件檢索程式碼,我其實做了很大的調整。首先放棄了對 IE 7.0 以前較舊版瀏覽器的支援,讓程式碼更為精簡。也全面採用 css 方式來控制版面樣式,方便使用者做客製化的調整。再來就是修正了一些細部邏輯,讓使用者的操作響應更為一致、合理。

由於漢字的總數逼近十二萬大關,檢索的響應速度勢必會變慢,這一版特別加強了沒有勾選「即時查詢」時操作的合理性,若覺得檢索的響應速度實在太慢,不妨取消「即時查詢」的勾選試試。

類聚鍵盤

這次跳脫了舊式思維,我設計了一種新的虛擬部件鍵盤,採用「物以類聚」的分類概念,讓性質相近的部件類聚在一起,希望讓使用者熟悉之後能「反射式」地定位部件的所在,加快輸入的速度,改善傳統鍵盤按筆畫數分類,使用者難以記憶反射的缺點。


當然,目前的按鍵安排還在起草階段,可能還難以盡如人意。不過這次按鍵的定義我改採簡單明瞭的陣列式描述,有興趣的朋友不妨看看原始碼(不懂程式也能改),您可以很容易地按自己的意思增減,定義自己專屬的鍵盤。不過若有好的 ideal,千萬記得反饋給我,呵呵!

如果真的無法適應新的類聚鍵盤,我還是提供了傳統鍵盤的版本,供大家自由選擇。


下載連結:部件檢索(測試版).7z



使用實例

部件檢索的使用請參見  漢字使用環境的建置 ㈡ —— 輸入篇 的說明,這裡不再贅述,改用幾個實際例子來引導大家進入使用的情境:

即地解構

 假設我們要檢索左邊這個字。
左邊的「⺶」當然屬「動物區」,直接找到,點擊輸入。右邊的部件不太好輸入,但我們想起翺翔的「翺」也有這個部件,可以加以利用,於是直接輸入「翺」。
按一下解構按鈕,這時「翺」就會裂解成「臯羽」,我們便取得了這個難輸的部件。
再按一下倒退鍵,消掉「羽」,於是我們就完成了輸入,找到該字。

字頭部件

 假設我們要檢索左邊這個字。
左上的是個常見的字頭部件,這次的類聚鍵盤為大家整理了一個「字頭區」,直接在這區就可找到這個部件。左邊中間是個「口」,「口」當然屬「人體區」。左下是個「冊」,「冊」是書,往「書樂區」去找。右邊是個「殳」,「殳」是兵器,屬「軍事區」。這樣我們就可依次輸入四個部件,順利找到這個字(其實輸入第三個部件時就已經找到)。

包圍部件

 假設我們要檢索左邊這個字。
左邊的是個包圍部件,包住一個韭菜的「韭」,類聚鍵盤為大家整理了一個「包圍區」,直接在這區就可找到這個部件。「韭」當然在「植物區」。右邊的「毛」在「動物區」。

部分查詢

若這時我們突然想知道左邊的兩個部件是否能合成一個字,不用清除重查,請直接反白選取這兩個部件,按一下查詢鍵,即可查到「韯」字。

快速替換

如果想用「韯」替代原先的兩個部件,直接右擊「韯」字,即可快速替換上去。善用「部分查詢」及「快速替換」的功能,可以增加查詢時的便利性與靈活度。

複製部件

有時候我們想直接複製虛擬鍵盤上的部件,而不是想輸入,例如直接右擊顏色區的部件按鈕,該部件的字符「靑」即會被複製到剪貼簿。

未竟之功

由於全字庫的拆分是拆到最細(最大拆分),而做為部件檢索用途,最小拆分才能達到最佳效果,因此我需要逐字加以調整、訂正全字庫的拆分。目前完成了數千字,還有萬餘字等待檢覈。原本想等全部完成後再對外發布,無奈父親一病讓我耽擱了大半年,再加上 G 區字既出,很多朋友等著有工具可以支援,因此只好先將這個尚未完全優化的版本推出,讓大家先有個工具可用,至於進一步臻至完善,只好徐徐後圖了。

未來展望

整合完全字庫的 CNS 編碼漢字後,我的下階段目標是將教育部異體字字典裡的所有圖片漢字整併進我的字庫之中。三年前,我擷取了教育部異體字字典的數據做成一部《教育部異體字字典》自用。由於官網的十萬漢字之中只有約一萬八千字是文字化的(Unicode 編碼),其餘全部以圖片加上編號來表示,這非常不利於檢索查詢。雖然與全字庫官網類似,官方都提供構形檢字的方式來查詢,但其實後台的數據都不完整,很多字都檢索不到。如果不信,我們便以「一」的異體字為例:


到官網的「複合查詢-條件七-形構」,輸入第一字的「匕天又土囗日」,或是第二字的「匕矢又土囗臣」,或是兩字共有的「匕又土囗」,都是查不到任何字。

三年來,我陸續將這些未文字化的圖片整理還原,目前已經還原約四萬字,106302 字中共有 56729 字是可以直接利用部件檢索來檢字的,已經超過一半。如果能將它全部完成,不僅可以檢索到《教育部異體字字典》的每一個字,對一些古籍的數位化也能提供幫助,可以大幅減少缺字的困擾。只是這是個恐怖的工作量,憑我一己之力,不知要到何年何月才能完工!大家只好慢慢等囉,呵呵!




23 則留言:

  1. 试用了一下,類聚鍵盤很有创意!但要求我们需要事先熟悉分类,否则依然很难找到。在
    我的长期实践中,我更常使用文中提到的“即地解構”方法。

    若有可能的话,建议:
    1. 增加一个部件收藏功能,用户可以按自己的心意自由收藏部件。
    2. 更大胆的一个想法,将解構功能和搜索功能二合一,全部放入搜索功能中,搜索结果包
    含两个部分:(1)将汉字拆解为部件,(2)将部件组合为汉字。在具体体验上,可以
    只解构搜索框中最后一个汉字,且使用有理拆分,结合即时搜索,体验应该很不错。

    回覆刪除
    回覆
    1. 感謝您的支持與建議。類聚鍵盤當然還是需時間稍微適應一下,正因為不可能有百分之百完美的鍵盤方案,所以我設計了「即地解構」來輔助,讓大家能各依習慣搭配使用。

      您的「解構、搜索二合一」想法我還是有點掌握不到重點。這兩個功能目前分別都具備了,將兩個有點背道而馳的功能放在一個查詢裡,能激盪出什麼效果,容我再仔細想想,呵呵!

      刪除
    2. 其实根源就是用户比较懒,希望解構功能也不用点击按钮,而能“即时”解构。

      虽然查询结果包含有两个完全不同的方向,但用户各取所需就好。

      刪除
    3. 当然,在没有实现异步查询之前,这个只会更加拖慢每一次的查询速度。因此,等以后有异步查询功能之后,再考虑这个问题,暂时先忽略吧:)

      刪除
  2. 将其加入mdx后,在GoldenDict中相应的javascript无法使用——无法切换键盘的收缩和展开。

    解决方案:将id为padbtn的标签a更改为标签span

    回覆刪除
    回覆
    1. 感謝您的提醒。這個 a 標籤本來就要改掉,年紀大了,轉頭即忘,呵呵!不過感覺 GoldenDict 的相容性還是沒有很好。

      刪除
    2. 在几天的试用中,这个版本与GoldenDict的兼容性已经很好了,没有发现其他问题。

      刪除
    3. 我自己的測試,在 GoldenDict 中點擊查詢的結果(href="entry://xxx")是無法跳轉到其他辭典的;在 MDict 中則可以。此外,像我製作的《說文解字》字典,點擊頁碼用 javascript 將開卷碼送到剪貼簿的功能,在 GoldenDict 也是不工作(無論使用 a 標籤或是改用 span 標籤、button標籤);在 MDict 則是工作正常。

      刪除
  3. 使用了几天,比之前的版本好用了很多!

    不知道能否实现异步查询(Asynchronous I/O support):目前的即时查询功能让我们输入时总觉得卡壳,需要等待第一个字查完,才能输入第二个字,若能加入异步查询功能,用户只管流畅的输入/编辑待查询的文字/部件,而系统则只检索最新的那个,之前没完成的检索则终止,那将极大提升用户体验。

    类似的机制在文本编辑器Vim第8版中有很好的体现,仅供参考: https://github.com/skywind3000/asyncrun.vim

    回覆刪除
    回覆
    1. 用 javascript 寫程式是遠不如用原生 API 撰寫桌面型應用程式彈性來得大。目前我有針對輸入法特別處理,也就是您如果用正常的輸入法來輸入,在輸入的中間過程是不會觸發查詢拖慢速度的;但如果使用虛擬鍵盤、類聚鍵盤輸入,我就沒辦法防止觸發查詢。新版加強了不勾選即時查詢時的操作合理性,建議取消勾選即時查詢試試,體驗應該會比較好。

      刪除
  4. 此外,“發布網址:部件檢索 (WFG製作)”的链接依然是链接到旧版本,建议也一并更新。

    回覆刪除
  5. 楼主功德无量,万分感谢!

    回覆刪除
  6. 廣義地說任何一個字都有可能是另一個字的組成部件,是字當然就有讀音。但有些部件只是為分析字形而析出,本身並不見得成字,當然也就沒有讀音。大致來說,我們熟悉的 214 個部首都有讀音(可以查閱字典或是維基百科),其餘成字的也有讀音,不成字的就沒有一定的讀音。有些時候我們會用一個常用字做為基準來稱呼一些部件,例如用「齊頭」來稱呼「齊」字的上半部部件,不過這都是俗稱,沒有嚴謹的標準。

    回覆刪除
  7. 若有可能的话,建议:

    部件可以增加上下結構,左右結構,包圍結構的查詢條件。
    比如上下結構查詢條件下,將符合左右結構和包圍結構的部件過濾掉,只顯示上下結構部件和未分類的部件。
    如此,或許可以減少找部件的負擔。

    回覆刪除
    回覆
    1. 在設計「部件檢索」之初,我便排除了使用 Unicode 定義的 12 IDC 來描述漢字(俗稱「構字式」或簡稱 IDS),原因是有些漢字既不是左右結構也不是上下或包圍結構,難以用 IDS 來表達。例如我們常用的「東」字,最直覺的拆法就是「木日(曰)」,12 個 IDC 中大概只有「重疊」可以勉強描述這兩個部件的空間關係。可是單一個「重疊」很難精準描述空間關係,是整個重疊(大概不成字)?還是部份重疊?而「部份重疊」我也可以疊出「果」、「東」兩個不同的字來,所以部件間的空間關係是遠複雜於目前 IDS 所能描述。

      您的構想很好,可是實踐上卻不容易,很多漢字的結構關係複雜,模稜兩可很難分類。再加上目前收字量龐大,難有人力願意幫忙逐字分類,所以大概難以實現。另外就是,如果只以上下、左右、包圍分類,估計能過濾掉的約有1/2~2/3,若是輸入的部件過於簡略,命中者常常超過千字,就算過濾後也還有三、五百字,成效可能有限。

      刪除
    2. 當使用空間關係檢索時,可以認爲放棄了選擇「重疊」。
      這是個取捨問題。正如當選擇上下結構,便放棄了其他空間關係。

      「部件檢索」的用途跟「倉頡」的用途是有區別的。
      如您提及的例子所示,但「部件檢索」不需要像「倉頡」那樣索引得到「東」的結果
      這種方式可以充當一種補充形式,可以更快方便檢索。
      重點還是取捨問題。另外人力問題,確實是個巨大問題。

      刪除
    3. 可能有個誤解,通過空間關係的過濾,我的意思指的是過濾部件,而不是參與部件檢索的演算法中去。
      因爲個人在使用「部件檢索」的第一感觀是「部件太多了」,如果能更快速的選取個人想要的部件就好了

      刪除
    4. 有點不了解您的說法,「部件太多了」是指類聚鍵盤上的部件嗎?您的意思是「不是要篩選檢索的結果,而是要篩選類聚鍵盤上的部件」,是這樣嗎?

      如果是,這些類聚鍵盤上的部件多半已是很精簡的模樣,大多分不出什麼上下、左右結構,用這個方式篩選幾乎沒有什麼意義。「部件太多了」這是沒有辦法的事,所以我設計了「類聚」的方式來分區塊。實用上要組合出足夠的漢字,這些部件已經算是很基本,您也可以完全不要管這些部件,直接在輸入框打上您要的部件即可。

      如果您的意思不是這樣,或許您可以舉例描述一下您心目中的操作方式,否則我不容易理解,呵呵!

      刪除
  8. 改變了思路,加了一個功能,按筆畫過濾部件,慢慢做,現在弄到動物^-^

    https://www.pinterest.com/pin/468374430008691893/

    回覆刪除
    回覆
    1. 歡迎自行動手改造,不過您留的連結我開不了,呵呵!

      刪除
    2. https://drive.google.com/file/d/16oPxB9wgv_fK3wmR9BluvHPXCIbZX8Q2/view?usp=sharing

      功能已完成

      刪除