2012-09-10 112 views
1

我有一些数据已导入到Postgres中,用于Rails应用程序。然而不知何故外国口音已经变得奇怪编码:奇怪的字符编码问题

  • ä出现â§
  • á显示为â°
  • é显示为â©
  • ó显示为ââ¥

我很确定问题是与inte数据的可靠性,而不是Rails的任何问题。这似乎并不符合任何编码我尝试:

# Replace "cp1252" with any other encoding, to no effect 
"Trollâ§ttan".encode("cp1252").force_encoding("UTF-8") #-> junk 

如果有人能够识别什么样的编码查询股价,我患的,那将是巨大的。

作为最后的手段,我可​​能不得不手动替换每个损坏的重音字符,但如果任何人都可以建议一个编程解决方案(或者甚至是解决此问题的起点 - 我发现它很难调试),我会很感激。

+0

你能检查数据库使用什么编码吗?另外,数据是如何导入的? – PinnyM

+0

编码是'UTF8'(整理'en_US.UTF-8')。数据经历了一个非常复杂的导入过程(最初是CSV,然后通过Google Refine,然后进行了更多转换)。重新导入数据并不容易,所以就地修复将是理想的。 –

+0

和原始的CSV文件 - 那是什么编码?一个'复杂的导入过程'增加了很多变量,并且它可能会导致编码的错误解释多于一个......此外,如果您可以在每个过程的时间间隔验证编码,这可能有助于锁定源因为腐败问题相当多。 – PinnyM

回答

2

最近的PostgreSQL版本在UTF8数据库中使用无效的UTF8几乎是不可能的。尽管如此,还有其他合理的可能性可能导致产出。

é表现为©的典型情况下,无论是:

  1. 数据库的内容是有效的,但是一些客户端层解释从数据库中的字节就好像它们是异拉丁文的东西,而他们是UTF8。

  2. 内容有效且SQL客户端层有效,但您正在查看的终端/软件/网页配置为iso-latin1或类似的单字节编码(win1252,异latin9 ...)。

  3. 数据库的内容由具有有效UTF8编码的错误字符组成。如果你使用ISO拉丁字节的字节,将它们转换为UTF8表示,然后将结果字节流视为如果仍在iso-latin中,并再次将其重新转换为UTF8,然后插入进入数据库。

注意的是,虽然©顺序UTF8与ISO-LATIN混乱是典型的,在你的所有样本串附加â的存在是少见。这可能是另一个主要错误解释的结果。如果您遇到#3情况,这可能意味着基于搜索替换的自动修复比正常情况更困难。