问题:“仅支持Unicode BMP,足以让母语/日语/韩语使用者以母语使用应用程序吗?”
我现在最关心的是日语使用者,但我也对中国人的答案感兴趣。如果某个应用程序仅支持BMP上的字符 - 是否会使该应用程序无法用于中文/日语(即应用程序不允许数据输入/显示补充字符)?
我不是问BMP是否是你需要的任何类型的应用程序(显然不是 - 特别是对于整个世界的所有语言)。我要求CJK发言人,在专业背景下,一个现代的普通应用程序,处理一般的自由文本输入(包括名称,地点等) - BMP一般是否足够?
即使只支持BMP也不正确 - 它会非常接近/“足够好”吗?在应用程序中缺少补充字符只是偶尔的轻微不便;或者,例如,日本发言人会认为该申请完全破裂了吗?特别是考虑到他们总能通过平假名/片假名拼出有问题的单词来解决问题?
如果没有后备选项的中国人怎么说,缺少补充字符会被视为停止显示问题吗?
我在考虑一般的专业背景 - 不是社交或游戏的东西。作为一个例子,在补充平面上有很多表情符号 - 但我个人不会认为不支持Unicode表情字符的英语应用程序被“破坏”,至少对于大多数专业用途而言。
我正在处理的应用程序是用Java编写的,但我认为这个问题更普遍适用。知道答案也有助于我(不管语言)更好地处理我在字体支持方面需要付出多少努力。
修改
澄清:通过“仅支持BMP” - 我打算让应用程序优雅地处理补充字符。
不受支持的字符(包括BMP代理代码块)的处理方式类似于大多数应用程序处理ASCII控制代码和其他不良字符的方式 - 过滤/禁止数据输入和“处理”以便显示(如果有必要)(过滤掉或替换为unicode替换字符。)
答案 0 :(得分:4)
对于那些可能正在寻找实际问题的实际答案的人:提示此问题的应用程序现在正在生产中,只允许来自BMP的字符(实际上是有限的子集)。
在生产中使用韩语的多个国际客户 - 日本即将上线。中国人正在计划中(我怀疑BMP是否足够,但我们会看到)。
没关系 - 没有报告与不支持的字符相关的问题。
但这只是轶事证据,真的。仅仅因为我的客户对它很好 - 这并不意味着你的客户会这么做。对于上下文,该应用程序的客户是国际公司,数百名员工使用该应用程序处理数十万客户。
答案 1 :(得分:2)
大多数CJK代码点在BMP中定义,但CJK表意文字不是。因此,如果您不需要支持表意文字,那么BMP就可以了,否则就不是。
但是,我会考虑任何无法识别和处理UTF-16代理的实现,即使它不能处理它们所代表的Unicode代码点,也会被打破。
答案 2 :(得分:2)
不幸的是,Unicode中的CJK支持被打破了。 BMP不足以正确支持CJK,但更糟糕的是,即使您对所有Unicode页面实施完全支持,它仍然会被破坏。
基本问题是他们试图合并所有三种看起来有点相似但不完全相同的语言的字符。结果是,如果您选择正确的字体来显示它们,它们只会看起来正确。例如,如果您使用中文字体渲染,则特定角色只能看中国人,如果您使用日文字体渲染,则只能看向日本人。
没有通用字体。无法确定字符应该来自哪种语言,因此您必须以某种方式猜测要使用哪种字体。您可以尝试检查系统语言或其他类似的黑客。除非您有其他元数据,否则不能在同一文档中支持两种语言。如果你得到原始的Unicode字符串而没有任何关于它们所用语言的指示,那你就搞砸了。
这是一场灾难。您需要与您的客户交谈以了解他们的需求以及他们如何向他们的系统指示用于破坏Unicode字符的字体。
编辑:还需要提一下,Unicode中缺少人名所需的一些字符。以后的版本更好,但当然你也需要更新的字体来利用它们。
答案 3 :(得分:-1)
除非你是一个喜爱的开发人员或开发操作系统,否则你不应该关心它,让OS层处理它。
只需在您的应用程序中实现正确的Unicode支持,并允许操作系统处理字符的类型和显示方式。
如果您在应用程序中使用自定义字体,可能会遇到麻烦
最后回答你的问题:否,Unicode支持不仅仅是BMP,而且你需要支持Unicode。