Closed upsuper closed 5 years ago
好像还有漏别的,暂时先关了
声母是21 个没错呀。
所以 w
和 y
只是一个补写规则。
那么finals应该返回原本的形式还是补写的形式呢?
我觉得定义音节、声母和韵母数据结构吧,这样的话,用户拿到音节数据结构,自己决定调用方法显示原始形式还是补写形式?
我设想当中的样子:
/// 声调
#[derive(Debug, PartialEq, Eq, Copy, Clone)]
pub enum Tone {
/// 第一声: 平调(阴平)
First,
/// 第二声: 升调(阳平)
Second,
/// 第三声: 降升语调(上升或折调)
Third,
/// 第四声: 降调(去声)
Fourth,
/// 第零声: 轻声调(不标符号)
Neutral,
}
// 整体认读音节
pub enum PrimitiveKind {
Zhi,
Chi,
Shi,
// ...
}
pub enum Syllable {
/// 整体认读音节,不区分声母和韵母
Primitive {
primitive: PrimitiveKind,
vowel: char,
tone: Tone,
},
/// 常规音节 ( 或 两拼音节 + 三拼音节 ),典型的 声母 + 韵母 或者 声母 + 韵母 + 鼻音 的结构
Normal {
initial: Initial,
rhyme: Rhyme,
// 再加一个鼻音部分?
tone: Tone,
},
/// 自成音节,没有声母
Rhyme {
rhyme: Rhyme,
tone: Tone,
},
/// 鼻音音节 (注: 这个并不在 `汉语拼音` 规范当中,属于扩展性质)
Nasal {
initial: Initial,
tone: Tone,
},
}
那么finals应该返回原本的形式还是补写的形式呢?
你这个提醒到我了,汉语拼音整体认读音节(如: zhi
、chi
...) 这些在返回 initial
时,应该是返回所有?
感觉那样就太复杂了……用户有这样的需求吗……或许应该把initials和finals整个去掉,然后开发一个新crate用于解析拼音结构?
是比较复杂,我当时也研究了好久 -_-
把当前对 initials
和 finals
的支持去掉,这好像会导致接口无法向下兼容,我个人还是比较支持去掉的,因为现在的实现是不完善甚至是错误的。但是不知道其他人是怎么看的 )
我之前做了一个拼音结构原型,但是不太满意,希望有天能把这个坑填上 ...
可以直接把新接口里的initials和finals从公开接口里隐藏掉,然后compat去掉的时候我们就可以把相关代码删掉了
写测试的时候检测出来的……测试写完再提交