我在考虑使用ICU或Boost Locale。
它们各有利弊，您需要权衡一下。
我了解这两个库都使用ICU，但是ICU被Boost Locale隐藏起来了。根据Boost Locale的理念页面：“...整个ICU API都被封装在不透明指针后面，用户无法访问它。”
请在比较这些库时考虑C++11中的新Unicode功能。
3个回答
16
ICU是一款非常好的库，但它存在一些缺点：
- 在现代C++设计方面API糟糕不堪，并且与标准C++库不兼容。
- 它是面向UTF-16的。
- 其消息翻译工具远非完美，这就是为什么Boost.Locale使用Gettext模型的原因。
参见：http://www.boost.org/doc/libs/1_49_0/libs/locale/doc/html/rationale.html#why_icu
Boost.Locale以C++方式进行本地化，还允许使用除ICU以外的其他后端（当然，ICU更好），因此在许多情况下，Boost.Locale提供了更好的本地化替代方案，因为它更简单，设计用于现代C++，并且通常更易于使用。
当然，如果您需要非常复杂的算法而Boost.Locale不支持，或者您的应用程序所做的全部都是Unicode处理，则ICU可能更好，除此之外Boost.Locale更适合本地化C++应用程序。
- Artyom
1
我喜欢Boost Locale接口，但需要访问其他ICU函数，比如u_isalpha()或u_isalnum()。我认为这些函数在Boost Locale中不可访问，除非我忽略了什么。如果没有的话，您是否计划将这些函数包装到Boost Locale中？ - Caroline Beltran
2
ICU是由国际化专家设计的，而boost是由C++程序员设计的。
尽管C++的boost强大而优雅，但其国际化方面存在很多问题。 现在，boost是一个庞大的库集合，有些做得比其他的好。 但ICU从头到尾都非常扎实，并且除了微软之外，几乎每个人都将其用作基础。
因此，如果您想要可靠的国际化，请选择ICU。 如果您想要前沿的C++（但国际化方面可能不太稳定），请选择boost。
- Mihai Nita
8
18OP希望对比ICU和Boost.locale。说一些像“boost在国际化方面做错了很多... boost是一个大型的库集合，有些表现比其他更好”之类的话完全离题了。Boost.locale是一个包装ICU和GNU Gettext的库，问题是它的表现如何？直接使用ICU会更好吗？ - Arzar
4答案有点暗示：直接使用 ICU。因为 Boost.locale 只是一个包装器，所以它的表现只能和 ICU 一样好或更差。它可能看起来比 ICU 更好的 C++，但也可能会引入额外的 Bugs（我知道在 Mac OS X API 包装 ICU 的情况下引入了不在 ICU 中的 Bug）。此外，Boost.locale 全程使用 UTF-8。由于 ICU 使用 UTF-16，这意味着所有调用都必须进行 UTF-8 到 UTF-16 的转换，反之亦然，映射字符串偏移量等。这会影响性能，并且容易出错。 - Mihai Nita
1看起来在C++11中，您可以使用std::u16string和UTF-16与Boost.locale一起使用。但是，根据C++0x char16_t/char32_t支持的状态页面，“对C++0x char16_t和char32_t的支持是实验性的。” - user1237077
6听起来你在传播一些老掉牙的恐惧、不确定性和疑虑 (FUD)。当然，库可能会包含漏洞，但是社区更有可能找到并修复这些漏洞，而不是在用户代码中发现的漏洞。使用精心设计和现代化的库如Boost.Locale的好处是，与直接使用ICU相比，用户代码中的漏洞可能会更少。 - dalle
5以下是对 Boost.Locale 的严厉批评，例如“大多数 boost 子库根本不考虑国际化。它们从设计上就有缺陷。” 对于这样强烈的说法，需要一个例子来说明。Boost.Locale 的哪些设计缺陷使其“从设计上就有缺陷”？目前情况是，我要进行第一次国际化迁移，并希望在选择使用 Boost.Locale 还是直接使用 ICU 方面获得建议。很遗憾，您的批评对我来说不是有用的，因为您没有提供证据。也许您可以补充说明一下？ - Dan Nissenbaum
显示剩余3条评论
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接