ICU的优点和缺点是什么？

Question

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

Answer 1

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

IMBO（有偏见）： 优点：

• 广告宣传，全面。
• 成熟：现在已超过10年，有着良好的稳定政策和非常积极的发展。
• 使用最新的Unicode + CLDR + BCP47 +其他标准。
• 基本上到处编译。 C / C ++ / J并由/ implements python，perl，php，...
调用
• 开源，贡献者的多样性越来越多。
• 附带上述所有必需的数据（见下文，缺点），但可自定义。 （可以添加自定义数据）

<强>缺点：

• 需要更好的文档（我们尝试 - 任何人都想帮助？）。
• 很多API-“它太大了＃1”很难知道使用哪一个，即使它能达到你想要的效果。
• 许多类型的程序使用，从嵌入式设备，智能手机到主要桌面应用程序，再到数据库和操作系统以及企业应用程序：因此，可能有多种方法可以做某事。
• 为上述内容提供所有必需的数据！ “它太大了＃2”（见上文，专业版），但可定制。 （可以缩小尺寸）

Answer 2

ICU非常糟糕：尽可能避免。

• 尽管年龄很大，但其中的基本内容却被打破了，例如在这个问题中：Fixing regex to work around ICU/RegexKitLite bug

• 由于时间不详，时间处理被打破：在许多API中，您无法以可靠的方式区分DST与非DST时间。

• 这太棒了。

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

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

• 支持对问题没有反应。

• 根据我的经验，直到你通过一个项目的大部分时间，你才开始发现需要花费90％时间的潜在缺陷。

对于很多人来说，别无选择，所以你会坚持下去。