求助大神,在合成mdx時候出現這樣的字符,請問應該怎麼辦

標準不是問題的核心,而是對於問題的透徹
仁兄依然未參透,切兩塊的優先於切三塊,四塊,筆劃多的優先於筆劃少的…理解了嗎?哈!哈哈哈

那为什么 wfg 和 chaizi 的解法不同?

取決於一開始他們分拆的部位就不太一樣,或排序上不同,這很正常的,不需揪結於如此細節差異,對於全局并不影響

同一个字拆成不同结果,这就是没有标准的问题,和参不参透没关。我是想自动处理拆字问题,肯定要找一个标准或者服从大多数人的习惯从这几家拆字里做参考做选择。

這是排列組合的問題,他們并沒有列出所有的排列組合,只是取其中的一,二而已,所以不用被其限制住

我不熟悉拆字,只想选一家做部件搜索的参考。

俎==> 1. [人][人][且]
2. [仌][且]

[仌]==>[人][人]
[且]==>月 , 一
月 ==>冂 , 一 , 一
冂==>丨 , 乙

我知道拆成人人且就够用了,但程序不知道,要不要继续拆那个且字,这个字也可以拆。

从这个角度看,在 mdx 里,直接把字拆成部件不太合理。应该搜索的时候,用部件输入,选择完整的字,再去搜索。

上面的例子只是解釋一個字大塊就有兩種或多種拆法,拆到最後面沒法再拆時,最原始的部件都是一樣的

如果 mdict 支持先部件检索,再去查找字,是不是就不用做索引的时候拆字了?

應該是這麼解釋,每個拆出來的區塊在上下層的關係既是一對多,也是多對一,道理是一樣的,若能參透就能解,不是什麼很難的概念

1 Like

是 词典软件支持 部件检索好,还是 mdx 的词头拆成部件好?

老兄,您的意思我看不太懂,這應該是不相違背吧!
Top-Down or Buttom-Up ==> 皆然…皆然也

是这样,我在做词典软件,打算支持多种搜索模式,比如拆字搜索,想看看哪种方案好,现在看软件读取词典词头,生成索引的时候自动把词头拆成部件不太行,索引类似 mdx 里的@@@LINK 跳转,软件自动给奰字,加上目目目大的跳转,支持直接搜索目目目大,但问题是,我不可能去穷举所有组合,还是让用户自己拆字的好,直接把 汉文博士,wfg 这种部件检索,内置到词典软件里更好些,在输入的时候,先通过部件查找到完整字,再去搜索词典的词头。

您的想法不錯,主要是 WFG 兄的部件檢索速度太慢,很卡,因有很多字是無法顯示,只能用內碼吧,他應該是用 js 去呼叫那個字型碼顯示,若能在資料拆解上對映好,其實應該可以不需透過如此複雜的 js 方式,只需處理好顯示就好了,所以才會去試那個拆字檔,雖不足20000吧,有些方塊沒法顯示,若能處理到顯示,其它應該都只是細節了!

1 Like

慢可能是 js 的原因,改成别的语言应该会好很多,感谢指教!!!

仁兄太客氣了,指教不敢當啦!哈!哈,他那 js 除了呼叫內碼顯示外,我想最主要的效率都卡死在找拆解的部首,和與此部首有哪些中文字上,我相信花在查找的 loop
上比花在顯示上消耗了更多的資源和效率,如此當然很卡,所以若在原始資料上就先處理好了對映關係拆解和衍生出的中文字,那就不會卡了,只需處理顯示呼叫內碼便會很快了!
若裏面的部件有10萬個,那每個部首拆解,一次就是10萬個loop,還不包刮找出部首衍生的中文字群,如此淺顯的道理可想而知

1 Like

这表述很专业啊,没仔细看过代码,如果提前映射好所有关系,确实可以省去重复查找的时间。

是的,這樣就會是 instant 及時值,不需繞一大堆沒有效率 Loops