漢字部件檢索

本程式改寫自 WFG 的「部件檢索」(http://fgwang.blogspot.com/2015/12/blog-post_30.html)。

修改說明

1. 效能修改：花幾天看懂程式後，其實相當讚歎 WFG 原始的演算法已經足夠簡潔，沒什麼可以加速提升效能的空間。不過在反覆測試以後，發現此工具操作時的卡頓感，其實不是來自於檢索本身，而是在於同步性。在每輸入、刪除一個字時，仍然需要等待上次的搜尋結果全部完成，才能處理下一次的搜尋，甚至鍵盤會失去反應，此種沒有回應、卡頓的感覺才是使用體驗不佳的主因。理想上，無論即時還是非即時搜尋，當使用者觸發新的查詢時，舊的查詢已經失去意義，應立刻中斷。本想試著讓查詢用平行執行緒來跑，可惜的是JavaScript是個用放棄平行處理來保證執行緒安全的語言，嘗試過各種方法，確定無法做到。最後想到的方法是將查詢碎片化，以分割來模擬多執行緒。將10萬字的資料庫切成100份，每50毫秒搜尋1000字，讓整個搜尋拉到最長5秒完成，比起原先在我的電腦上大約3秒比起來是慢了點，但換來的好處很多。首先當觸發新的查詢時，舊的查詢會即時結束，過時的查詢不再拖延使用效能。第二，分割的每個片段能即時顯示出目前已找到的結果，不是全部等數秒搜尋完才一次顯示，如此可提高互動性，使用者可以同時審視搜尋結果，減少等待的不耐感。第三，同時顯示出搜尋進度，讓使用者感受到系統的即時回饋，降低不確定感。經此修改，目前測試，即便是在手機搜尋，或許搜尋所要時間有些微增加，但使用時都有明顯更輕盈的感覺，不會感受到中斷。
2. 其中每個單位間隔50毫秒這個值相當難決定，例如我用兩三台不同機器測試，搜尋1000字所要的時間從10毫秒到60毫秒不等。完全與設備等級有關。目前我採取的方式是預設值50毫秒，但會在幾次搜尋之後根據實際執行情況動態加減速率。
3. 原始程式不知道為何，即使搜尋結果已經超過99/999字，仍然不會中途跳出（似乎是為了有精確符合文字的機會？），但這樣造成無論結果顯示99還是999字，只是差在畫面顯示的結果數量，程式實際上還是搜尋全部10萬字，這也是卡頓原因之一。已改成只搜尋到顯示字數＋1字（多找1個字是為了判斷訊息是「超過」還是「總共」）。
4. 原程式的資料索引方式，是將Unicode漢字區平移到一個陣列中，並使用預先設定的偏移值去找到資料的位置。這樣的好處是索引速度理論上飛快，缺點則是程式裡必須維護許多偏移量的值，使資料集本身增修不易，改動資料集時，都必須調整程式碼內的偏移值，才能正確運作。並且PUA區域雖有大量未定義拆分的文字、未實際作為其他文字拆分結果，但都必須佔用資料量（使資料集字數虛胖）。我試著嘗試改用JavaScript物件形式索引，從程式移掉複雜的偏移量資訊，也讓資料集理論上更好維護。至於效能，只好相信JavaScript內部的雜湊運算速度夠快吧。另外，移除偏移量的同時，也將程式裡其它的switch case都改用list的方式。
5. 整理3個區域（鍵盤、結果、快捷列）的操作一致性：原本此3區域綁有各種事件，如滑鼠單擊、雙擊、右鍵等，或許用習慣後操作會很快，但全都記憶下來可能需要一段時間。此版本改以浮動視窗顯示所有功能，並且盡可能統一此3區域的功能定義，讓使用體驗一致。副作用是藉此找到適合顯示巨大文字的位置，結果看得更清楚，也因此可拿掉調整文字大小的功能。
6. 畫面設計以CSS重構：盡可能拿掉所有HTML tag上的style指定，讓HTML與CSS分離，修改外觀可幾乎只動CSS區域。鍵盤也同時改為全由程式自動生成，這樣調整鍵盤變得理論上更容易，也提高易維護性。我已經將WFG原先設計的兩種鍵盤都內建在一起，本來的鍵盤收合功能改為兩種鍵盤、關閉之間的3者切換。
7. 對於智慧型手機等平台的支援：調整後的CSS設計，我也都加入自適應性設計的概念，讓版面在手機上減少不必要的顯示內容，維持正常易用。不過由於手機沒有滑鼠經過的概念，浮動視窗只好調整為兩段式點擊。另外，在手機上，因為畫面大小的限制，顯示出鍵盤無論如何都會讓整個系統變得很不好用。實際上，手機上因為本來就有內建手寫輸入法，部件挑選鍵盤或許其實不太需要（基本的部件應該可以寫得出來）。但考慮到平板電腦的使用者、既有使用者的習慣，我目前不敢直接對小螢幕拿掉整個鍵盤，目前先嘗試讓鍵盤在小螢幕先預設為關閉，只是仍然留下一整列的鍵盤空列在那裡，還是有點很可惜。可能還要試著重新規劃畫面排列。
8. 原先改寫程式時，本著維持原始程式的初衷，為了容易客製化，將檢索系統的邏輯(Seeker)與外觀(UI)切割為兩個類別。然而在完成上述各項修改後，尤其是將鍵盤程式化、增加浮動視窗設計、將事件管理從HTML層抽出來後，因為程式對外觀的介入更深，可惜的是UI層也變得比較不易修改了。目前我能想到的只有盡量把可客製化項目另外拉出一個Config類別，保持一定程度的調整空間。但不可否認的是只有基礎HTML、JavaScript概念時，容易修改的彈性範圍大幅下降了，這是今後的課題，如何讓可客製化程度提高。
9. 因為大幅度改寫UI的事件模型，已經難以相容IE8（若要相容IE8，很多部份都必須寫兩份，會讓程式碼大幅增加）。目前執行需求是IE9以上版本，或是Chrome、Edge等其他瀏覽器。另外不知道為什麼，IE在開啟開發者工具時，分割搜尋的過程會極度笨重（猜測是開發者工具試圖監控每一個setTimeout），其它瀏覽器沒有這樣的情況。不過，關掉開發者工具時，IE9+的運作也是相當平順的，應該不是太大問題。

• ps. 調整成明顯減少卡頓感後，我自己現在已經習慣隨時開著即時查詢功能，並沒有感受到明顯的反應遲鈍感。原先即時查詢可以自由開關、99/999的兩階段查詢數量設計，應該都是為了減少卡頓而生的。若卡頓已經不是個問題，我在想是否這兩個功能可以考慮移除，以降低系統複雜性。或許是個可以檢討的方向。不過這要看既有使用者是否能夠適應。

檔案說明

• source/corecode.js : JavaScript程式碼 (Seeker與UI類別)
• source/data_supp.txt : 漢字拆分資料集 (Unicode至ExtG的全漢字與CNS11643所收錄之PUA漢字等，11萬餘字)
• source/data_nosupp.txt : 漢字拆分資料集 (Unicode至ExtG的全漢字，PUA的文字只留下作為其他文字拆分用的最低限度，9萬餘字)
• source/data_vt.txt : 搜尋時包容異體的異體對應關係
• source/HanSeeker.htm : 執行用的HTML檔
• gen_release.rb : 將 source 裡的檔案轉換為 release 版本 (Ruby程式)
• release/HanSeeker_StandAlone_All.html : 可1個HTML檔獨立運作的釋出版本 (漢字拆分資料集11萬餘字)
• release/HanSeeker_StandAlone_Unicode.html : 可1個HTML檔獨立運作的釋出版本 (漢字拆分資料集9萬餘字)
• release/HanSeeker_WithoutData.html : 將資料集檔案區隔開來的HTML檔釋出版本，請與資料集放在同一個路徑使用 (預設handata_uni.js)
• release/HanSeeker_WithoutJS.html : 將Javascript、資料集都區隔開來的單純HTML檔釋出版本，請與seeker.js、資料集放在同一個路徑使用
• release/seeker.js : 壓縮過的JavaScript程式部份（corecode.js）
• release/handata_full.js : 壓縮過的漢字拆分資料 (11萬餘字)
• release/handata_uni.js : 壓縮過的漢字拆分資料 (9萬餘字)
• release/PUAExt-Regular.ttf : 輸入鍵盤、PUA裡會用到之最低限需要漢字Webfont
• release/PUAExt-Regular.woff : 同上(woff版本)
• release/PUAExt-Regular.woff2 : 同上(woff2版本)

在此提供幾種不同釋出版本。 將HTML與JavaScript、資料JavaScript檔案切開，或許可以期待瀏覽器cache住資料檔，不用每次都下載1.5MB的資料。

授權說明

• 程式碼、HTML部分
  • 比照 WFG 「部件檢索」原始的授權規定：無條件提供授權給一切非商業營利，有助於學術研究、有益於教育學習、有利於閱讀大眾的網站或個人使用。
• 拆分資料的來源由 WFG 整理自以下來源，依各授權規定聲明著作權資訊於此：
  • 中央研究院「漢字構形資料庫」 - GPL3授權 (https://cdp.sinica.edu.tw/cdphanzi/)
  • 漢字データベース「字形ＩＤＳデータ」 - GPL授權 (http://kanji-database.sourceforge.net/ids/ids.html)
• 字型檔部分
  • 萃取自 WFG 的全宋體。其字型主要收錄自全字庫宋體等。適用政府資料開放授權條款－第1版。

備註

此版本是為了「字嗨！」網站的Unicode文字檢索功能而改寫的。 https://zi-hi.com/sp/uni/CJKSeeker