Windows 版 R 4.2 将支持 UTF-8 作为本机编码，这将是对编码支持的一项重大改进，允许 Windows R 用户处理国际文本和数据。
此新功能至少需要在桌面系统上安装 Windows 10（版本 1903），在长期支持服务器系统上安装 Windows Server 2022 或在半年频道中安装 Windows Server 1903。较旧的 Windows 系统将能够运行 R，但编码支持的限制与 R 4.1 及更早版本相同。
作为此项更改的一部分，R 将需要 UCRT 作为 Windows 的新 C 运行时。这意味着在早于 Windows 10 的桌面系统和早于 Windows Server 2016 的服务器系统上，在安装 R 之前必须安装 UCRT。较旧的 C 运行时 MSVCRT 将不再受支持。R 4.2 还将放弃对 Windows 上 32 位版本的构建支持。
新的编译器工具链 Rtools42 将用于从源代码构建 R 和 R 软件包的 Windows 二进制文件。所有代码都必须使用新工具链重新构建。
R 4.1.x 没有任何变化，即使是即将到来的次要修订版也没有变化。它们仍将使用当前的编码支持，并使用 Rtools4 在 32 位和 64 位版本中为 MSVCRT 构建。
在 R 4.2 之前，最终 R 用户没有任何变化，他们现在不必做任何特殊的事情。只有 Windows 上的 R-devel 用户会在发布之前受到影响。
然而，此项更改需要一些软件包作者的合作。大多数作者不必做任何事情，因为需要关注的 CRAN 软件包数量不到 1%，但使用本机（C、C++ 或 Fortran）代码的软件包的作者应该阅读以下内容。其中一些作者必须更新他们的软件包，但在大多数情况下，他们可以使用 Tomas Kalibera 创建的补丁和/或从 Tomas Kalibera 或 Uwe Ligges 那里获得更多建议。我们感谢已经与我们合作进行更改的软件包作者。
当前状态
到目前为止，CRAN 上的 Rtools4（GCC 8）已构建 R-devel 快照二进制版本和 R 包二进制版本，并使用 MSVCRT 作为 C 运行时。感谢 Jeroen Ooms 汇总并维护 Rtools4 和 R 的二进制版本。MSVCRT 不允许使用 UTF-8 作为本机编码。
Tomas Kalibera 创建并维护了一个单独的设置（“ucrt3”），其中包含一个新的工具链 Rtools42（GCC 10），带修补程序的 R-devel 快照二进制版本、带修补程序的 CRAN 包二进制版本、带修补程序的 Bioconductor 包二进制版本（仅 CRAN 所需的版本）以及 JAGS 和 Tcl/Tk 捆绑包的兼容版本。自 2021 年 3 月 起，已提供自动 R-devel 二进制版本和 CRAN 包检查，结果链接自 CRAN。更多信息请参阅 操作方法：在 Windows 上将 UTF-8 作为 R 中的本机编码。为了帮助包作者测试和修复其包，“ucrt3” R-devel 版本会在安装时自动应用 Tomas Kalibera 创建的一些包的修补程序（已创建超过 100 个 CRAN 包和几个 Bioconductor 包的修补程序）。自 2021 年 3 月起，已邀请作者采用这些修补程序，并且 操作方法：在 Windows 上将 UTF-8 作为 R 中的本机编码 中描述了一些功能，允许包在仍支持当前 R 版本的同时执行此操作。
切换到 UCRT
“ucrt3”系统已准备好合并到 CRAN 系统和 R-devel 源代码中。此过程计划按如下方式进行，可能需要一些时间 - 这比以前的工具链升级更具挑战性。
Uwe Ligges 扩展的 CRAN 系统也几乎准备就绪：二进制包已构建并用于 CRAN 包检查（结果已在 CRAN 页面上提供）以及通过 Win-builder 服务 进行检查。
12 月 13 日星期一，CRAN 将把 Windows 上的传入检查切换到现在的“ucrt3”。同时，R-devel 源代码将使用“ucrt3”修补程序进行修补。从那时起，它将假定 64 位 UCRT，不再支持 MSVCRT 或 32 位目标，CRAN 将开始使用 Rtools42 构建 R-devel 快照二进制版本。此切换应花费数小时到最多数天的时间。在此短暂的期间内，可能很难从源代码构建 R-devel，在 R-devel 中安装二进制包或将包提交到 CRAN。
对于在 Windows 上使用 R-devel 的包作者和用户来说，最好的做法是卸载 R-devel，卸载旧的 Rtools，删除旧的包库，并从头开始安装新版本。从源代码构建 R-devel 的人必须运行 distclean。
切换后，R-devel 将在安装时自动安装 CRAN 和所需的 Bioconductor 包的修补程序，就像“ucrt3”现在所做的那样。此功能将暂时使用，以便为包作者提供更多时间来修复其包。最终，在安装时修补包可能会变成一个警告，并且修补程序可能会被移除。
该切换正在与 Bioconductor 团队协调，在 R-devel 和 CRAN 切换后，他们最终将再次为 Bioconductor 软件包提供全面支持，但预计可能需要几天时间才能使所有内容同步。
为切换做准备
未通过 UCRT 检查的软件包的作者和具有 安装时间补丁 的软件包的作者受邀开始调整他们的软件包。自 3 月以来，检查结果已在每个软件包的 CRAN 结果页面上提供（例如 Matrix），现在相应的检查类型为 r-devel-windows-x86_64-new-TK 和 r-devel-windows-x86_64-new-UL。两者之间的差异主要是由系统的不同设置引起的，软件包作者主要应该关注 Uwe Ligges 运行的后者，因为这是切换后将使用的设置。
软件包作者现在可以通过 Uwe Ligges 运行的 Win-builder 服务使用此设置来检查他们的软件包。大约一个月前，Gabor Csardi 也在 R-hub 上安装了“ucrt3”系统，可以在其中用于构建和检查软件包。它还可以与 github 操作一起使用，请参阅 Github ucrt3 版本和操作。这可以与 Simon Urbanek 提供的 github 操作一起使用，以在不同平台上检查软件包。
在本地安装“ucrt3”之前，最安全的方法是卸载 Rtools 和 R-devel 的任何先前安装，并删除 R-devel 软件包库。安装程序可用于“ucrt3” R-devel 和 Rtools42。有关详细的安装说明和软件包作者的建议，请参阅 方法：在 Windows 上将 UTF-8 作为 R 中的本机编码。
所需的大多数软件包更改都是由于在安装时下载了不兼容的预编译库。Rtools42 包含几乎所有 CRAN 软件包的库，可以而且应该使用这些库。使用来自工具链的库可确保以兼容的方式构建它们，使源软件包更透明，消除下载问题（对于个人用户来说可能很少见，但在 CRAN 操作中并非如此）并使工具链的更大更改（如此更改）变得更容易。
展望工具链的进一步发展
目前，编译器工具链和库在 Linux 上交叉编译（使用 MXE）。我们最终可以在 Linux 上支持 R 的完整安装程序构建，因为 R 的大部分内容已经可以交叉编译，如果我们最终也可以交叉编译大部分或所有 R 包，那就太好了。这可以使某些操作更快、更容易实现自动化，并且更容易复制某些用途。也许并不奇怪，在主要为 Unix 开发的软件中使用的某些构建系统（绝大多数软件 R 包使用）在 Linux 上运行得更快。例如，Julia 和 Octave 使用交叉编译（后者甚至使用 MXE）。即使必须了解那里的好处有多大，交叉编译甚至可以在 Windows 中的 WSL 中运行。
以单个块（或两个，“base”和“full”版本）分发包的库是一个持续争论的话题，意见不一。如果需要以更小的块（库集，甚至单个库）进行分发，则应使用 R 包外部的包管理器，并将其与工具链捆绑包/Rtools 集成，从而允许与编译器工具链一起自动重新构建和更改。MXE 本身允许构建各个库的 .deb 包，因此这将是一种选择。
最近的更改
这是 2020 年 5 月、2020 年 7 月、2021 年 3 月 的早期博客文章中介绍的正在进行的工作的结果。
自 2021 年 3 月 以来，“ucrt3” 的进展包括
Rtools42
该捆绑包包括 Msys2，用于构建工具（例如 make）和新的编译器工具链（用于 UCRT）和库。安装程序几乎与 Rtools4 中的相同，并重新使用了其代码。
区别如下。Rtools42 包含几乎所有 CRAN 包的库，这允许在包安装时摆脱下载预构建的库。Rtools42 的安装步骤更简单：不必将编译器放在 PATH 中。Rtools42 不再有 tar 的特殊实现。Rtools42 仅具有 64 位编译器工具链。
Github 操作
“ucrt3” 也可在 github 上获取，可用于 github 操作。可以使用提供的操作从 github 下载 R 构建和工具链，并使用它检查软件包。
出于 github 操作的目的，还有一种新的工具链“基本”发行版，它仅包含编译器工具链和构建基本 R 所需的库，但它已足以构建许多 R 软件包，并且它比“完整”发行版更小。
自动构建链接顺序
现在，软件包作者可以使用脚本自动查找/建议链接到其软件包的库以及链接顺序。Deepayan Sarkar 提供了帮助。更多信息，请参见 操作方法：在 Windows 上将 UTF-8 作为 R 的本机编码。
改进的自动化
自动软件包检查和构建在 docker 容器内运行（在 Windows 和 Linux 上）。这可以测试所有外部软件的安装是否真正自动化，从而以记录的方式完成。它还表明，所有 CRAN R 软件包都可以在 Windows docker 容器中真正检查，因此无需使用某些 Windows GUI API 和 GUI 本身，而这在开始时根本不清晰，并且这是一个值得保留的特性。用于“ucrt3”的脚本可 在此处获取。
改进的覆盖范围
尽管这是一个不断变化的目标，但检查结果已经可以与其他平台上的 CRAN 检查相媲美，包括现有的 Windows 检查。工具链已升级到较新的 GCC、MinGW-w64，并且许多库（地理空间和其他）也已升级。不可避免地，一些软件包检查问题是由于检查系统之间不同的设置，从而唤醒了以前未发现的软件包中的问题。
减小的大小
通过删除不必要的可执行文件，工具链的大小已减少约 1G，这些文件是 MXE 默认构建的，但 CRAN 软件包不使用。由于静态链接使可执行文件变大，因此这是一个重大的改进。此外，通过使用更好的压缩工具和在压缩前重新排序文件以增加压缩算法找到公共部分的机会，压缩大小已减小。现在，编译器工具链和库的“基本”tar 包压缩后约为 100M，解压缩后约为 1000M，“完整”tar 包压缩后约为 360M，解压缩后约为 2.7G，而 Rtools42 的安装程序压缩后约为 360M（带有内部压缩的 EXE 文件），安装后约为 3G。