问题标签 [ruby-1.9]

我有一些要转换为 Ruby 1.9 的 ruby​​ 代码。我得到的一个警告是Hash#index is deprecated; use Hash#key

但是 Hash#key 没有在 Ruby 1.8 中定义，所以我不能直接使用它。有人有好的选择吗？

我有几个选项（我将把它们作为答案发布，以便你投票），但我希望有更好的选择。

大约半年前，当我开始学习 Ruby 和 Rails 时，我首先尝试了 Ruby 1.9，但我很快就放弃了，因为当时没有什么开箱即用的方法，几乎​​所有帮助博客或教程都是为 Ruby 1.8 设计的。

现在呢？（2009 年 12 月）是否可以让 Ruby 和 Rails 初学者运行现有的 Rails 应用程序而不会遇到只能由绝对的 Ruby 和 Rails 专业人士解决的问题？

嗨:) 我手动设置了 Ruby 1.9.1。我已经通过安装它

生成的 Makefile 中不存在目标“卸载”...
如何正确卸载？

PS：我也认为有必要移除所有的宝石。
为此，我使用

在 Ubuntu 9.04 上，有没有办法将 Ruby 1.8 安装为ruby1.8（或完全摆脱它）并让 Ruby 1.9 成为默认值ruby？

我正在使用 UTF-8 字符串。我需要使用基于字节的索引而不是基于字符的索引来获取切片。

我在网上找到了对 的引用String#subseq，它应该类似于String#[]，但用于字节。唉，它似乎没有达到 1.9.1。

现在，我为什么要这样做？如果我在一个多字节字符的中间切片，我最终可能会得到一个无效的字符串。这听起来是个可怕的主意。

好吧，我正在使用StringScanner，事实证明它的内部指针是基于字节的。我在这里接受其他选择。

这是我现在正在使用的内容，但它相当冗长：

两者ix和pos来自StringScanner，因此都是基于字节的。

在我看来，ruby 1.9 附带的 YAML 库是编码聋的。

这意味着在生成 YAML 时，它将采用任何字节字符串，并转义任何不输出干净 ASCII 的字节序列。这很蹩脚，但可以接受。

我的问题是相反的。从所述 YAML 转储加载内容时。

在下面的示例中，我创建了一个 UTF-8 字符串，将其转储，它的转储类型为!binary. 当我重新加载它时，它的编码为 ASCII-8BIT。在示例的最后，我尝试将原始字符串和重新加载的字符串与另一个 UTF-8 字符串连接起来。后者将失败并显示Encoding::CompatibilityError.

我认为很清楚，当您处理一些包含嵌套散列和带有叶字符串的数组的 YAML 源时，这将如何迅速导致麻烦。

目前我有一些代码遍历所有哈希和数组并调用force_encoding每个字符串。至少可以说，这是难看的。

我现在正在寻找的是一种方法来告诉YAML::load任何传入的字符串都应该被视为，因此将其编码设置为 UTF-8。

理想情况下，ruby 的 YAML 应该只用正确的编码注释它转储的字符串。有一个 Ya2YAML 项目试图转储 UTF-8 安全 YAML。我不确定它有多远。如果有人玩过它，我欢迎任何想法。

无论如何，我仍然有这些转储，没有任何编码信息要处理。虽然我知道它们都是 UTF-8。

I want to match all individual words in given string, provided that String is UTF-8 encoded, and then I spellcheck each word. Everything works with my code provided it's english-only text, but if there are some, say, German characters, my words are split in two on these characters. How can I match single words from text, that contain latin and not-latin characters?

What I do now is:

but this, for text containing "oooäuuu" will end up with "replacementäreplacement", i.e: German characters are not being treated as part of word.

升级到 ruby​​ 1.9 后，我们开始注意到当用户使用非 ASCII 字符时，页面无法从 rails 模板渲染器渲染。特别是“é”。我能够在我们的一台登台服务器上解决此问题，但我无法在我们的生产服务器上重现该修复程序。

第一次似乎有效的修复：

1. 使用此处提供的 convert_charset 工具将数据库从 latin1 转换为 utf8：http ://www.mysqlperformanceblog.com/2009/03/17/converting-character-sets/ 。（包括default_character_set=utf8在 my.cnf 中设置和运行SET GLOBAL character_set_server=utf8

2. 切换到 sam-mysql-ruby 适配器（而不是标准 mysql 适配器： http: //gemcutter.org/gems/sam-mysql-ruby）

3. 重新启动的轨道

错误是： "invalid byte sequence in US-ASCII" 奇怪的是，按照上述步骤操作后，我们的生产服务器上的错误并没有改变。在 database.yml 中的设置encoding: utf8也不会改变错误。

以下代码行引发的错误： <%= link_to h(question.title), question_path(question) %>

该博客似乎建议修复，但它提到这在 1.9 中应该不是问题：http ://www.igvita.com/2007/04/11/secure-utf-8-input-in-rails/ （并且已经超过 2 岁）。

我想随着越来越多的 Rails 开发人员转向 1.9，这个问题可能很快会影响到很多人。

这听起来可能微不足道，但它一直让我发疯。自从上周五在 Ruby 1.9 上将应用程序发布到生产环境以来，我遇到了很多与字符编码相关的小异常。几乎所有这些都是以下方面的一些变化：

我们有一个国际用户群，所以很多名字都包含变音符号等。如果我修复模板以在很多地方使用force_encoding，它会在 flash 消息帮助程序中弹出。等等。

目前看来，我已经确定了我所知道的所有内容，方法是在一个地方修补 ActiveSupport 的字符串连接，然后# encoding: utf-8在我的每个源文件的顶部进行设置。但是，从现在开始，为了避免字符串分配问题，我可能必须记住对我曾经做过的每个 Ruby 项目的每个文件都这样做，永远，这种感觉在我的胃​​里并不好。我阅读了有关-Ku开关的信息，但似乎一切都在警告它是为了向后兼容并且可能随时消失。

所以我对 1.9 有经验的人的问题是：#encoding在我的每个文件中进行设置真的有必要吗？有没有一种合理的方法可以在全球范围内做到这一点？或者，更好的方法是在绕过内部/外部默认值的字符串的非文字值上设置默认编码？

在此先感谢您的任何建议。