[潜在bug]table编码存在带声调字符从而引发注释~剩余编码计算出错引发崩溃

[amzxyz]

问题描述

当字典词库的编码列包含“带调拼音”与“ASCII字符”的混合编码（例如：jiā'QQ）时，RIME 在尝试生成剩余编码提示（即 ~ 开头的注释）时会出现问题,。导致全角字符被切~ā'QQ

现象表现为：

1. 程序崩溃（Crash）；

原因分析

推测是 librime 在计算 remaining_code 长度并执行 substr 截取时，未能正确处理 UTF-8 多字节字符（带调拼音）与单字节字符（ASCII）混合后的字节偏移量。导致切分点落在了多字节字符的中间，破坏了字符结构。

复现示例

在 .dict.yaml 中添加：

加QQ	jiā'QQ
转换后编码jwqq

前端

Fcitx5

自行规避策略

使用有规则的转写改写注释段，或者清空
comment_format:
    - xform/^~.+$//

可能的程序规避建议

1、积极支持声调类字符，毕竟这与拼音与输入关系极大
2、检测到非法字符禁用剩余编码提示

[eagleoflqj]

一些上下文：
方案是 https://github.com/amzxyz/rime_wanxiang/releases/tag/v13.12.1
现象是输入 xnp 后，产生了非法 UTF-8 字符串，作为候选词 小鹏G9 的注释。

非法字符串产生的地点是

librime/src/rime/dict/dictionary.cc

Line 330 in 4703320

remaining_code = syllable.substr(code_length);

其中 str_code 是输入 xnp，code_length 为 3，syllable 是候选词编码 xiǎo'péng'G'jiǔ，切分点位于 ǎ 中间。

两个问题：

1. 非 ASCII 编码可能未被 librime 正式支持
2. 假设编码是 ASCII（xiao'peng'G'jiu），也不应该用 xnp 的长度直接切编码，需要将 n 按小鹤双拼规则展开为 iao，同时正确处理用作间隔的单引号，当然这可能也不是 librime 正式支持的 table 用法

[lotem]

table 是一顆固定深度的編碼樹，remaining_code 主要用途是查詞時比對編碼中未索引的字節。
單以根據編碼查字典的功能看，並不需要關心輸入是如何編碼的，只管當成字節序列就行。

可是涉及到顯示就出現了問題。
最初設計只考慮 ascii 字符做編碼。
很可能對 Context::input 的操作也不兼容多字節編碼字符，才會出現「拿半個字來查字典，剩餘編碼還有半個」的情況。

[lotem]

總之是超出設計了，窟窿可能很多。預備在 R²ime 解。

爲什麼不用 ascii 轉寫呢？
最終呈現在界面上的編碼可以通過拼寫運算還原成帶調的字母。

[amzxyz]

这是认知未到造成的，原来注释这里没写不觉得有啥，自从有了这个bug，我认为核心在于设计，应该将转写前、转写后设立清晰的接口，注释的输出也应该从两个源头来输出可做选择，编码提示应基于转写后数据来实现，逻辑就恰当了，顶层设计解决。
可能是我首次将带声调符号引入词库作为基础编码，很幸运rime能支持，这就导致无论声调显示，输出，类型变化，都有了较为原生的数据，也没有性能问题，如果按照OpenCC做法，则性能不好，且不能解决语句流中浑然一体的多音字词拼音的正确输出，这也是顶层设计
因此希望rime2将原生支持声调符号这些字符的使用

[lotem]

此處代碼截取的是字典編碼。

因此只要字典用 ascii 編碼，截取的編碼就是正確的，後期用 translator/{preedit_format,comment_format} 生成的Unicode應該不會再出錯。

這些規則得額外考慮截斷的編碼怎樣顯示。比如已經輸入了 a，提示只顯示聲調符號？

[amzxyz]

哦不是，只是看您谈到了rime2,我是有感而发，认为从顶层设计的角度应规避这种绕圈圈的行为，建立两者映射关系后，如果想要利用编码提示此类功能可以直接拿转写后的数据作为源头，如果想要显示声调，那么preedit_format可以调用原始带声调数据再加工，
而对于剩余编码提示这种主观的功能想要自带就应该采用安全的方式，不管是不是前面说的顶层设计。留出接口让用户启用或者关闭，而不是直接计算，当然了如果顶层足够安全了直接算也无不可，就看最终如何抉择！

[lotem]

r2 要原生支持Unicode字典碼。