Question

我将应用程序从rails 2.3升级到rails 5.我们遇到的一个问题是db上的编码，我们使用的是mysql。

在rails 2.3应用程序中，如果您在我们的字段中查询数据库，则会获得有效符号，例如：

€

如果直接查看db：

â‚¬

检查十六进制表示

select HEX(txt) from table;
+----------------+
| HEX(txt)       |
+----------------+
| C3A2E2809AC2AC |
+----------------+
1 row in set (0.00 sec)

如果我在应用程序的rails 5版本上保存完全相同的char，则在直接查询db时我在db上获得了正确的值。

对于十六进制的长度，我认为它是utf-16而不是：

SELECT CHAR(0xC3A2E2809AC2AC USING utf16);
+-----------------------------------+
| CHAR(0xC3A2E2809AC2AC USING utf16) |
+-----------------------------------+
| 肚슬                              |
+-----------------------------------+
1 row in set (0.00 sec)

现在，如果我知道0xC3A2E2809AC2AC代表一个€，它可以知道什么字符集表示准确吗？

我认为mysql适配器mysql（2.8.1）正在进行一些转换，但是我无法找到任何关于此的文档。

字段排序规则为utf8_general_ci，db字符集为utf8。

Answer 1

不，这不是Euro Sign的正确编码，至少不是直接编码。

作为utf8处理，â‚¬（已添加间距）为€。但撤消“双重编码”（即通过latin1两次转换），你得到CONVERT(BINARY(CONVERT(CONVERT(UNHEX('C3A2E2809AC2AC') USING utf8mb4) USING latin1)) USING utf8mb4) --> '€'：

{{1}}

（在这种情况下，utf8和utf8mb4将产生相同的结果。）

有关更多讨论，请搜索“double” Trouble...和 Here。两者都为系统和数据提供了可能的修复。

原始问题

表面上看，你的编码是utf8。但是，由于“双重编码”，这一结论具有误导性。请参阅上面第二个链接中的“诊断CHARSET问题”部分。

Answer 2

要将其转换为utf 8，请导出并导入表格，如此

mysqldump -u db_user -p --opt --default-character-set=latin1 --skip-set-charset db_name db_table > some_file.sql

观察--skip-set-charset选项，强制它不要在转储中放置任何字符集。

然后我用

导入它

mysql -u db_user -p --default-character-set=utf8 db_name < some_file.sql

我如何知道给定十六进制使用的编码？

2 个答案: