过去，JRuby 的字符串问题是一直是个难题。对于字符串，Ruby 使用字节数组表现；而 Java 则全面支持 Unicode 字符串，在内部表现为 UTF-16。由于这种差别，运行在 Ruby 上的代码如果要运行在 JRuby 上就可能会出现问题，正如 Charles O. Nutter 解释的那样：
但是 API 不符合 Ruby 应用程序的预期，经常将个别字符返回为 16bit 的值，并报告不正确的字符串字节长度，且无法将该字符串编码为全部由 8bit 的字符组成的字符串。只要 Ruby 代码涉及到这样的字符，就会出问题。
他继续描述了 JRuby1.0 中的解决方案： > 1. Ruby 字符串是 byte[] 类型且符合 Ruby 字符串语义。
- 传入 Ruby 代码的 Java 字符串将被编码为 UTF-8，这暗示了你应该在接收参数的代码中用 UTF-8 byte[] 来工作。
- Ruby 字符串传出到 Java 时也被假定为 UTF-8，Java 端调用的返回结果应该符合该假定。
调整字符串编码只是众多工作中的一个，为了达到与 Ruby 的完美兼容，还需要做许多单调乏味的工作。 一个相关的话题是在 JRuby 上支持 Ruby 正则表达式。简单的解决方案是直接用 java.util.regex——Java 中自带的正则表达式类库，来处理 Ruby 正则表达式。这个方案已经用了很长一段时间。可是，不断有不同的 Bug 报告进来，同时出于其他一些方面的考虑，我们觉得需要一个更好的解决方案。java.util.regex 的性能问题是众所周知的，而且在 JRuby 内部使用字节数组表示 Ruby 字符串会使性能问题更甚（java.util.regex 工作时不直接使用字节数组，因此需要先将 Ruby 字符串进行转换）。 因此，JRuby 的核心组成员 Ola Bini 决定直面困难，重新选择一个解决方案。他先选择了 JRegex 作为临时的替代解决方案，目前他正在致力于 REJ 方面的工作，这是他的描述： > REJ 是一个我已经启动的项目，它将成为 MRI 1.8.6 正则表达式引擎的直接端口。这一点很重要，因为这样 JRuby 的语义将与 MRI 紧密匹配。我们将能够匹配 UTF-8、SJIS 和 EUC 正则表达式等，并且我们将具有像 MRI 一样的特别功能，即使人们并不一定依赖于这样的特别功能。
到 2007 年 5 月，所有这些工作将确保 JRuby 1.0 尽可能地接近 Ruby。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论