我正在探索如何将CFStringTransform应用于希伯来语音译文本,我遇到了一些不一致之处,在这些不一致的地方,字母的发音应该完全相同,或者是苹果算法没有考虑到的特殊情况。
Kaf (כּ→K)诉Khaf (כ→Ḵ)
כִּי中的kaf发音与英语中的K类似,而שָׁכָֽחְתִּי中的kaf发音为loch或Bach,通常音译为CH、KH或Ḵ。然而,这两个字母都被音译为K。
贝(פּ→P)诉费(פ→F)
פַּרְעֹה中的pei发音为P,在英语中发音为P(并相应地音译),而יוֹסֵף中的(尾)F发音为F(并相应地音译)。然而,两者都是用P音译的。
尾声辅音与pataḥg‘’nuva
来自英文维基百科关于希伯来语发音的文章:
单词末尾的字母ח,ע,ה是在字母之前发出的,而不是在后面。因此,נֹחַ(Noah)发音为/ˈno.ax/。这只发生在单词的末尾,只有patach和ח,ע,以及הּ(即带有点(mappiq)的ה)。这有时被称为帕塔加努夫,或“偷”拍打(更正式,“秘密拍打”),因为声音“偷”一个虚构的辅音,使额外的音节。
然而:
问:我如何改变CFStringTransform的行为来解释这三种情况?
从CFMutableString中,我们看到CFStringTransform接受作为transform:参数
标识要应用的转换的CFString对象。有关有效值的列表,请参见CFStringTransform的转换标识符。在OSXv10.4及更高版本上,您还可以使用ICU转换用户指南中定义的任何有效的ICU转换ID。
在文献资料中,听起来好像ICU转换的规则足够灵活,可以定制。甚至还有一个可以从规则编辑器访问的他们的游乐场,但是,虽然我已经找到了处理与RTL语言类似的东西的堆栈溢出问题,但我无法找到一种对RTL语言进行访问的明确的文档化的方法。
发布于 2017-02-19 17:34:09
据我所知,通过在中文和日文中使用它,CFStringTransform逐个标记地工作,而不是将单词作为一个整体(可能是多个标记长)来考虑。因此,当需要考虑多个标记时,音译将是有限的/不正确的。我希望我的假设是正确的,这也是希伯来语问题的根源(请告知)。
在这种情况下,我发现音译要准确得多,方法是使用CFStringTokenizer对文本进行令牌化,然后使用CFStringTokenizerCopyCurrentTokenAttribute()方法依次获得每个令牌的拉丁文音译。这方面的一个例子--我认为在目标C中,虽然这里的语法与Swift非常相似--给出了这里。
https://stackoverflow.com/questions/37685877
复制相似问题