Ruby 在 Mac OS X 和 Linux 上与文件路径和文件名中的 Unicode 字符配合得很好，但为什么要让它在 Windows 上工作，花了 2 年多的时间？
我只是在看 Google Code Jam。人们在几个小时内解决了重要的问题。在工作中，我可以想象解决具有 unicode 字符的文件名或路径问题，即使我们需要将其写入标准库以在一两天、几天或 1 或 2 周内解决？但是2年？
可能是什么原因？我认为 Mac OS X 和 Linux 可能会按原样工作，因为它们使用的是 UTF-8，并且许多 ASCII 程序代码无需任何修改就可以很好地使用 UTF-8。
Windows 可能会返回 UTF-16 格式的文件名或路径，所以它更复杂，但是有一些函数可以将 UTF-16 转换为 UTF-8，反之亦然，所以这不是一个可以解决的问题吗？
这确实是一个可以解决的问题，但我认为核心团队中没有人使用 Windows 进行开发。对于此类主题，OSX/Linux/BSD/... 解决方案很快就可用，因为在大多数情况下，它只是所有这些平台的一种解决方案，而且这些平台主要由核心开发人员使用并且人们关闭核心（即愿意提出解决方案并提供支持）。此外，请记住 Ruby 的主要用例是用于 Web 应用程序，而且，至少在 Ruby 领域，使用 Windows 进行部署是相当少见的。
如我所见，为了帮助桌面/控制台应用程序，Ruby 仅在 OSX 上流行。在 Linux 上，Python 在这方面相当占主导地位，而在 Windows 上则没有这样的东西（尽管可能是 VBScript），因为您通常没有小型应用程序相互交互（控制台程序、管道、KISS 原理、UNIX 原理等）在 Windows 上不是很常见，你必须为任何东西编写服务等等）。但我无法真正判断这一点，因为我已经很多年没有使用过 Windows。因此，只有少数人真正遇到了这个问题。如果这些人中没有一个愿意解决这个问题，则需要两年时间。
因为你需要在操作系统和你的程序之间有一个巨大的层来完成每一个微不足道的操作。
甚至fopen()不适用于 Windows 上的 UTF-8。换句话说，原因是，Windows Unicode API 是……废话（对不起所有 Windows 开发者）
所以在 Windows 上支持 Unicode 是非常困难的，而所有其他操作系统都可以愉快地使用 UTF-8。