圈圈之地

鶴飛四季 写了： 2024年 6月 9日 13:46 還有bug:
當填完兩邊相接的構字符號"後，刷新發現前面多了\，即\"。

這個bug也正在處理中，將很快修復。

@鶴飛四季






這條可能少了括號以及包含作用：

"萬":"{並十}/{田}#豎形%覆匡;-一+點形"

要改成：

"萬":"{並十}/({田}#豎形%@覆匡~(?一+?點形))"

這樣我們拿它去組字「厲勵勱」等，就不會有問題。




「有左右」是否應判為包圍分體？

@鶴飛四季

"画":"{一}/{仰匡}>田",

可能要加括號：

"画":"{一}/({仰匡}>田)",

ejsoon 写了： 2024年 6月 9日 16:49

鶴飛四季 写了： 2024年 6月 9日 13:46 還有bug:
當填完兩邊相接的構字符號"後，刷新發現前面多了\，即\"。

這個bug也正在處理中，將很快修復。

已修復。

倉字，你的編輯為：

{人}/{點形}/日-斜撇>口

我的修正為：

{人}/{點形}/((日#斜撇)>口)

"丳":"({豎形}+{豎形})%外圍;%外圍",
"丯":"{豎形}%{斜撇};%斜撇;%斜撇",

可能要改成：

({豎形}|{豎形})%(外圍/外圍)
{豎形}&{斜撇};&斜撇;;&斜撇

以上修改我已知悉。

鶴飛四季 写了： 2024年 6月 10日 11:01 以上修改我已知悉。

構造：

(也)_|(母)

真字：

(七形*五中)_|(@母圍&齊首;~?點形)

字首劃分：

{七形*五中}_|({@母圍}&齊首;~?點形)

對於丼字，井對於點形應該是有染包圍。

「夕瓦卪凡舟母」等較窄的空間，對於丶應該都是有染包圍。

「兔寬寸」的空間相對較寬，因此是包圍，無染。

ejsoon 写了： 2024年 6月 9日 20:01 「有左右」是否應判為包圍分體？

目前我的個人看法是，「夂友犮反发」判為連體，「有左右存在后孝老考」判為包圍分體。

「存」是(尹有-豎形)包圍「子」，「在」則是包圍「土」。

「后」是(尹有+一)包圍「口」，「垕」是包圍「口-土」。

@鶴飛四季

你的結構判定有時還是會少括號，比如「所」：

"所":"{斜撇-尸}|{連脈}+一-豎形",

上面的左右分體結構判定是無效的，因為右邊沒有括號。

可能要改成：

{斜撇-尸}|({連脈}+一-豎形)

唯有左邊或右邊是單個字元時不需括號，比如「胡」：

(十-口)|月




另外，如果你的結構判定不對，那字首劃分也不對。則你的字首劃分應該是在「真字」裏面手工填的。

最好是統一用自動劃分字首功能，這樣不僅快，而且能檢查結構判定是否正確。

横折夕架對點向下的連接方式統一為下聯「\」。

四中八分儿向上的連接統一為上聯「^」。

比如「虎」應為儿上聯：

[{貞占}-{七形}]^(斜撇|仰鉤)

@鶴飛四季

「产亲」不太對，亠跟兼上是「立連」，所以是普通的相接。

對點的下聯可參考「商」：

{齊首}-{對點}\(@覆匡>(?四中/?口))

倉頡字元序列計畫的壓力問題：

現在保存與提取的數據是全部數據，這對於網路、數據庫、前端內存，都會壓力很大。

目前1200多的字數，data大小是近50k。則每次保存時，都要把全部的50k數據提取一次。

那如果字數達到5000、10000，那就是不止50k了。

因此保存和拉取數據的機制需要改變。

計畫的改變是：

分成兩組數據，第一組是「字頭數組」，第二組是當前的「全data」。之後前端將不再加載全部的data，而只加載字頭。當需要某個字的data時，才由php後端精準提供單條數據。

這樣前端（也就是瀏覽器）的負擔就會小很多，但缺點是每當「真字」裏存在需要展開的字，就需要向php後端索取一次數據。



要不要這樣做，還待未來的體驗。如果每次拉取全數據（差不多1M）確實負擔過重，反應也太慢，這時就需要改。

我估計後期是要改的，因為現在有時已經感覺有點慢了。

尋：
{@己上~?一}/{工形|口}/(寸架>點形)

此前的「尋上」是己上&一。目前我們暫定，雪下，尋上，都用陸標（@己上~?一），尹倉也是這樣編碼的。

這樣一來，「蔧槥」等字就能快速的確定它的末碼。