一、引言
你好！恩迪沃！莫尔韦尼！Салам!在世界各地，人们正在使用智能手机、智能手表和其他小型、低资源设备上网。技术行业需要为这些环境提供一个国际化解决方案，可以扩展到数十种编程语言和数千种人类语言。
输入ICU4X。顾名思义，ICU4X是Unicode联盟发布的行业标准i18n库的一个分支，ICU（Unicode国际组件）嵌入到每个主要设备和操作系统中。
本周，经过谷歌、Mozilla、亚马逊和社区合作伙伴两年半的努力，Unicode Consortium发布了第一个稳定版本ICU4X 1.0。从头到尾建造轻量级,便携式的、和保护ICU4X借鉴了数十年的经验，将本地化的日期格式、数字格式、排序、文本分割等功能引入到迄今为止还没有合适解决方案的设备中。
轻量级：ICU4X是Unicode第一个支持静态数据切片和动态数据加载的库。使用ICU4X，客户端可以检查已编译的代码，轻松构建小型优化的区域设置数据包，然后动态加载这些数据包，使应用程序能够扩展到比以往任何时候都更多的语言。即使平台i18n可用，ICU4X也适合作为一个polyfill来添加其他功能或语言。它可以做到这一点，同时只使用很少的RAM和CPU，有助于延长设备的电池寿命。
便携式：ICU4X支持多种现成的编程语言。ICU4X可以在Rust编程语言中本地使用，通过外部函数接口（FFI）在C++中使用官方包装器，通过WebAssembly使用JavaScript。可以通过编写插件添加更多编程语言，而无需接触核心i18n逻辑。ICU4X还允许独立于代码更新数据文件，从而更容易推出Unicode更新。
安全：Rust的类型系统和所有权模型保证了内存安全和线程安全，防止了大量错误和漏洞。
ICU4X是如何实现这些目标的，为什么团队选择在众多备选方案中编写ICU4X？
二、。为什么选择ICU4X？
您可能仍在想，是什么导致Unicode联盟选择新的基于Rust的库来解决这些问题？
二、。为什么要建一个新图书馆？
Unicode联盟还发布了为C/C++和Java编写的ICU4C和ICU4J i18n库。为什么从头开始编写新库？这不会增加日常维护负担吗？为什么我们不把重点放在改善ICU4C和/或ICU4J上呢？
ICU4X为不同类型的客户解决了不同的问题ICU4X不寻求替代ICU4C或ICU4J；相反，它试图取代大量非Unicode、通常未维护、通常不完整的i18n库，这些库是为了将i18n引入新的编程语言和资源受限的环境而编写的。ICU4X是Unicode产品组合中长期缺失的产品。
早期，该团队评估了通过重构ICU4C或ICU4J是否可以实现ICU4X的目标。我们发现：
ICU4C已经经历了一段时间的树木摇晃和数据大小优化。尽管做出了这些努力，我们仍然有利益相关者表示，ICU4C对于其资源受限的环境来说太大了。ICU4C的进一步改进将相当于重写ICU4C的大部分代码库，这需要以保持向后兼容性的方式进行。这将是一项巨大的工程工作，最终结果不确定。此外，编写一个新库允许我们为现代UTF-8本机环境进行额外优化。
除了通过j2cl使用JavaScript之外，Java不是一种适合于移植到低资源环境（如可穿戴设备）的源语言。此外，ICU4J有许多相互依赖的部分这需要付出大量努力，才能使其成为一个可行的j2cl源。
我们的一些利益相关者（Firefox和Fuchsia）被Rust的内存安全所吸引。像大多数复杂的C++项目一样，ICU4C已经其在CVE中的份额，主要与记忆安全有关。尽管C++诊断工具正在改进，但Rust具有其他软件堆栈中不可能的强大保证。
基于所有这些原因，我们认为基于Rust的图书馆是最佳的长期选择。
二、。B.当平台中有i18n时，为什么要使用ICU4X？
许多在ICU4X上工作的人也通过API（例如ECMAScript Intl对象,android.icu和其他智能手机本机库。重症监护病房4X补语基于平台的解决方案是理想的polyfill：
一些平台i18n功能需要5年或更长时间才能获得足够广泛的可用性，以便在客户端应用程序中使用。ICU4X可以弥补这一差距。
ICU4X可以让客户端添加比平台中可用的更多区域设置。
一些客户端喜欢在多个设备上使用相同的应用程序行为。ICU4X可以为他们提供这种程度的一致性。
最后，我们希望ICU4X支持ECMAScript和其他地方的平台实现，在ICU4X也用作聚合填充时提供最大程度的一致性。
二、。为什么要插入数据？
ICU4X与ICU4C和ICU4J最明显的差异之一是大多数构造函数上的显式数据提供程序参数。ICU4X数据提供程序支持以下用例：
旧版本和新版本代码都可读的数据文件；有关如何工作的更多详细信息，请参阅ICU4X数据版本化设计
可以在运行时交换的数据文件，便于升级Unicode、CLDR或时区数据库版本。可以在运行时交换新数据，而无需重新启动应用程序或清除内部缓存。
多个数据源。例如，一些数据可能会被烘焙到应用程序中，一些可能来自操作系统，而一些可能来自HTTP服务。
可自定义的数据缓存。我们认识到，缓存不存在“一刀切”的方法，因此我们允许客户端使用适当类型的缓存配置其数据管道。
完全可配置的数据回退和覆盖。可以在运行时选择性地覆盖ICU4X数据的各个字段。
III、 我们如何实现ICU4X轻量化
有三个因素结合在一起使代码轻量级：较小的二进制文件大小、较低的内存使用量和有意的性能优化。对于这三个方面，我们都有在GitHub Actions持续集成（CI）上持续测量的指标。
三、 A.二进制小
国际化涉及大量相互依赖的组件。为了解决这个问题，ICU4X通过以下方式优化了“树抖动”（死代码消除）：
最小化每个单独组件的依赖项数量。
使用静态类型的方式是将函数范围限定为所需的数据块。
将拉入的数据超过所需数量的函数和类拆分为多个更小的部分。
开发人员可以静态链接ICU4X并运行树抖动工具，如LLVM链接时间优化（LTO），以生成非常少量的编译代码，然后可以运行我们的静态分析工具，为其构建一个最佳的小数据文件。
除了静态分析之外，ICU4X还支持开箱即用的动态数据加载。这是支持数百种语言的最终解决方案，因为只有在需要时才能动态下载新的区域设置数据，类似于UI字符串的消息包。
三、 B.内存使用率低
国际化的核心是使用特定于本地的数据将输入转换为人类可读的输出。ICU4X为涉及零内存分配的数据的运行时加载引入了新策略：
支架明信片-为所有体系结构中动态加载的零拷贝反序列化数据格式化资源文件。
支持所需数据的编译时链接，而无需通过反序列化开销数据烘焙.
数据模式的设计使单个组件可以直接使用不可变的语言环境数据，只需进行最少的后处理，从而大大减少了对内部缓存的需要。
为每个需要数据的函数显式提供“数据提供程序”参数，使其在需要数据时非常清晰。
ICU4X团队成员Manish Goregaokar写道博客帖子系列详细介绍了零拷贝反序列化在幕后是如何工作的。
三、 C.慎重的性能优化
减少CPU使用量可以提高延迟和电池寿命，这对大多数客户端都很重要。ICU4X通过以下方式实现低CPU使用率：
用Rust（一种高性能语言）写作。
利用零拷贝反序列化。
根据绩效基准衡量每一个变化。
ICU4X团队使用基准驱动的方法来获得极具竞争力的绩效数据：新添加的组件应具有基准，并且这些组件的未来更改应避免回归这些基准。
虽然我们总是寻求提高绩效，但我们是故意这样做的。通常会在空间/时间上进行权衡，团队会采取平衡的方法。例如，如果提高性能需要增加或复制数据需求，我们倾向于选择较小的数据，就像我们在normalizer和collator组件中所做的那样。在分段器组件中，我们提供了两种模式：数据量较小但CPU使用量较大的机器学习LSTM分段器，以及数据量较大但速度较快的基于词典的分段器。（正在进行工作，以使LSTM分段器需要更少的CPU资源。）
四、 我们如何使ICU4X便携式
软件生态系统随着新的编程语言不断发展。ICU4X中的“X”是对第二个主要设计目标的认可：可移植到许多不同的环境。
ICU4X是Unicode的第一个国际化库官方的多个目标语言中的包装器。我们使用一个我们设计的工具来实现这一点外交官，它生成许多编程语言中的惯用绑定，以鼓励i18n最佳实践。多亏了外交官，这些绑定很容易维护，并且可以添加新的编程语言，而无需i18n专业知识。
在幕后，ICU4X是用no_std Rust（无系统依赖项）编写的，它包装在一个稳定的ABI中，外交官绑定可以跨外部函数接口（FFI）或WebAssembly（WASM）调用该ABI。我们有一些使用ICU4X的基本教程，来自C++和JavaScript/TypeScript脚本.
V.下一步是什么？
ICU4X代表着将国际化软件引入更多设备、用例和编程语言的激动人心的新步骤。Unicode工作组正致力于随着时间的推移扩展ICU4X的功能集，使其变得更加有用和高效；我们渴望了解新的用例，并让更多的人为项目做出贡献。
有问题吗？您可以通过联系我们ICU4X论坛!
想试试吗？请参见我们的教程，尤其是我们的简介教程!
有兴趣参与吗？查看我们的贡献指南.
想继续关注未来的ICU4X更新吗？注册我们的低流量公告列表，icu4x-annouse@unicode.org!
超过144000个字符可用于采用帮助Unicode联盟在数字弱势语言方面的工作
![[徽章]](https://www.unicode.org/announcements/ynh-infinity.png)
