Unicode ICU的优点和缺点是什么？

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

数据点：我们（是的，这是一个免责声明）的用户和缺陷列表都在我们的网站上

IMBO（有偏见的）： 专业人士：

• 作品如广告所示，全面
• 成熟：10年以上，具有良好的稳定政策和非常积极的发展
• 使用最新的Unicode+CLDR+BCP47+其他标准
• 编译基本上无处不在。C/C++/J，并由/实现python、perl、php等调用
• 开源，贡献者越来越多样化
• 提供了上述所需的所有数据（见下文，cons下），但可自定义。（可以添加自定义数据）

缺点：

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

---

重症监护病房很糟糕：尽可能避免

• 尽管它年代久远，但它的基本元素还是被打破了，例如在这个问题上：

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

• 太大了

• 文档需要大量的工作。使用较少的功能通常无法使用，因为无法找到正确的使用方法。我花了好几天的时间试图让音译像我解释的那样起作用，最终还是放弃了

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

• 支持对问题没有反应

• 根据我的经验，直到你完成了一个项目的大部分工作，你才开始发现潜在的缺陷，这将占用你90%的时间

---

对许多人来说，没有其他选择，所以你只能坚持下去。

基本的东西不是bug。跟随链接和bug。您是否提交了一个bug或发送了关于音译的支持请求？ICU因其功能和数据集而庞大，但可以通过有据可查的方式缩小。您是否在DST/非DST上提交了错误我不确定我是否理解他们的要求。正常情况下，阅读SO不是我们官方支持的一部分；我已经依赖它很多年了。“赞成和反对”是一个意见问题，通常被认为是StackOverflow的界限。