這個bug也正在處理中,將很快修復。
倉頡字元序列計畫
版面规则
公正客觀講理,杜絶廢話連篇
公正客觀講理,杜絶廢話連篇
Re: 倉頡字元序列計畫
這條可能少了括號以及包含作用:
"萬":"{並十}/{田}#豎形%覆匡;-一+點形"
要改成:
"萬":"{並十}/({田}#豎形%@覆匡~(?一+?點形))"
這樣我們拿它去組字「厲勵勱」等,就不會有問題。
「有左右」是否應判為包圍分體?
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
"丯":"{豎形}%{斜撇};%斜撇;%斜撇",
可能要改成:
({豎形}|{豎形})%(外圍/外圍)
{豎形}&{斜撇};&斜撇;;&斜撇
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
構造:
(也)_|(母)
真字:
(七形*五中)_|(@母圍&齊首;~?點形)
字首劃分:
{七形*五中}_|({@母圍}&齊首;~?點形)
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
「夕瓦卪凡舟母」等較窄的空間,對於丶應該都是有染包圍。
「兔寬寸」的空間相對較寬,因此是包圍,無染。
上次由 ejsoon 在 2024年 6月 10日 11:19,总共编辑 3 次。
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
目前我的個人看法是,「夂友犮反发」判為連體,「有左右存在后孝老考」判為包圍分體。
「存」是(尹有-豎形)包圍「子」,「在」則是包圍「土」。
「后」是(尹有+一)包圍「口」,「垕」是包圍「口-土」。
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
你的結構判定有時還是會少括號,比如「所」:
"所":"{斜撇-尸}|{連脈}+一-豎形",
上面的左右分體結構判定是無效的,因為右邊沒有括號。
可能要改成:
{斜撇-尸}|({連脈}+一-豎形)
唯有左邊或右邊是單個字元時不需括號,比如「胡」:
(十-口)|月
另外,如果你的結構判定不對,那字首劃分也不對。則你的字首劃分應該是在「真字」裏面手工填的。
最好是統一用自動劃分字首功能,這樣不僅快,而且能檢查結構判定是否正確。
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
四中八分儿向上的連接統一為上聯「^」。
比如「虎」應為儿上聯:
[{貞占}-{七形}]^(斜撇|仰鉤)
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
「产亲」不太對,亠跟兼上是「立連」,所以是普通的相接。
對點的下聯可參考「商」:
{齊首}-{對點}\(@覆匡>(?四中/?口))
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
現在保存與提取的數據是全部數據,這對於網路、數據庫、前端內存,都會壓力很大。
目前1200多的字數,data大小是近50k。則每次保存時,都要把全部的50k數據提取一次。
那如果字數達到5000、10000,那就是不止50k了。
因此保存和拉取數據的機制需要改變。
計畫的改變是:
分成兩組數據,第一組是「字頭數組」,第二組是當前的「全data」。之後前端將不再加載全部的data,而只加載字頭。當需要某個字的data時,才由php後端精準提供單條數據。
這樣前端(也就是瀏覽器)的負擔就會小很多,但缺點是每當「真字」裏存在需要展開的字,就需要向php後端索取一次數據。
要不要這樣做,還待未來的體驗。如果每次拉取全數據(差不多1M)確實負擔過重,反應也太慢,這時就需要改。
我估計後期是要改的,因為現在有時已經感覺有點慢了。
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
Re: 倉頡字元序列計畫
{@己上~?一}/{工形|口}/(寸架>點形)
此前的「尋上」是己上&一。目前我們暫定,雪下,尋上,都用陸標(@己上~?一),尹倉也是這樣編碼的。
這樣一來,「蔧槥」等字就能快速的確定它的末碼。
https://ejsoon.win/
弈趣極光:享受思維樂趣
弈趣極光:享受思維樂趣
在线用户
正浏览此版面之用户: 没有注册用户 和 1 访客