unicode - Unicode 基本多语言平面是否足以满足 CJK 使用者的需求？

Question

问题:“仅支持 Unicode BMP 是否足以使以中文/日文/韩文为母语的人使用其母语的应用程序？”

我现在最关心的是说日语的人，但我也对中国人的答案感兴趣。如果应用程序仅支持 BMP 上的字符 - 是否会使该应用程序无法用于中文/日语使用者(即应用程序不允许数据输入/显示补充字符)？

我不是在问 BMP 是否是任何类型的应用程序唯一需要的东西(显然不是——尤其是对于全世界的所有语言)。我在专业背景下要求 CJK 演讲者提供一种处理一般自由文本输入(包括名称、地点等)的现代普通应用程序 - BMP 通常足够吗？

即使只支持 BMP 是不正确的——它会非常接近/“足够好”吗？应用程序中缺少补充字符是否只是偶尔的轻微不便？或者说日语的人会认为应用程序完全崩溃了吗？特别是考虑到他们总是能够通过用平假名/片假名拼出有问题的单词来解决问题？

没有后备选项的说中文的人怎么办，缺少补充字符会被认为是一个显示停止的问题吗？

我在这里考虑一般的专业背景——不是社交或游戏的东西。例如，辅助平面上有很多表情符号 - 但我个人不会认为不支持 Unicode 表情符号字符的英文应用程序被“损坏”，至少对于大多数专业用途而言。

我现在正在处理的应用程序是用 Java 编写的，但我认为这个问题更普遍。知道答案也将帮助我(无论使用何种语言)更好地了解在字体支持方面我必须付出多少努力。

编辑

澄清:通过“仅支持 BMP” - 我打算让应用程序优雅地处理补充字符。
不受支持的字符(包括 BMP 代理代码块)的处理方式与大多数应用程序处理 ASCII 控制代码和其他不需要的字符的方式类似 - 过滤/不允许数据输入并在必要时“处理”以显示(过滤掉或替换为 unicode 替换字符)。

Answer 1

对于可能正在寻找实际问题的实际答案的人:提示此问题的应用程序现在正在生产中，仅允许 BMP 中的字符(实际上是有限的子集)。

多个国际客户在生产中使用韩语 - 日语即将上线。中文正在计划中(我怀疑 BMP 是否足够，但我猜我们会看到的)。

很好 - 没有报告与不受支持的字符相关的问题。

但这只是轶事证据，真的。仅仅因为我的客户对此感到满意 - 这并不意味着您的客户会满意。就上下文而言，该应用程序的客户是国际公司，数百名员工使用该应用程序处理数十万客户。