4

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

4

2 回答 2

6

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

IMBO（有偏见）： 优点：

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

缺点：

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

ICU很糟糕：尽可能避免。

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

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

  • 实在是太大了

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

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

  • 支持对问题没有反应。

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

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

于 2011-02-15T06:33:00.597 回答