ICU的优点和缺点是什么？ [关闭]

Question

我的团队的任务是在我们的软件中实现 Unicode，该软件的代码行数远远超过一百万行。我们支持带有 Oracle 或 SQL Server 数据库的 Windows、AIX 或 Solaris 上的 MFC 客户端和服务器。 ICU 看起来是一个非常有用的工具。使用ICU有什么好处和坏处？ ICU 是否像宣传的那样工作，没有重大错误？

Answer 1

数据点：我们的（是的，这是免责声明）用户和错误列表都在我们的project site 上。

IMBO（有偏见）： 优点：

• 像宣传的那样工作，全面。
• 成熟：10 多年了，具有良好的稳定性政策和非常积极的发展。
• 使用最新的 Unicode+CLDR+BCP47+其他标准。
• 基本上到处编译。 C/C++/J 和调用/实现 python,perl,php,...
• 开源，贡献者越来越多样化。
• 带有上述所有需要的数据（见下文，在缺点下），但可定制。 （可以添加自定义数据）

缺点：

• 需要更好的文档（我们尝试 - 有人想帮忙？）。
• 大量 API - “它太大 #1”很难知道该使用哪一个，即使它可以满足您的需求。
• 被多种类型的程序使用，从嵌入式设备、智能手机到主要桌面应用程序、数据库和操作系统以及企业应用程序：因此，可能有多种方法可以做某事。
• 附带上述所有需要的数据！ “它太大了#2”（见上文，在专业人士下），但可定制。 （可以裁剪到合适的尺寸）

Answer 2

ICU 很糟糕：尽可能避免。

• 尽管年代久远，但其中的基本内容已损坏，例如在这个问题中：Fixing regex to work around ICU/RegexKitLite bug

• 由于时间未指定，时间处理被破坏：在许多 API 中，您无法以可靠的方式区分 DST 时间和非 DST 时间。

• 真是大得吓人。

• 文档需要大量工作。较少使用的功能通常无法使用，因为没有办法找出正确的使用方式。我花了几天时间试图让音译按照解释的方式工作，但最终放弃了。

• 它喜欢在 UTF-16 中工作，这是所有可能世界中最糟糕的。

• 支持对问题无响应。

• 根据我的经验，直到您完成一个项目的大部分时间，您才会开始发现需要花费您 90% 时间的潜在缺陷。

对于许多人来说，别无选择，所以你只能坚持下去。