Question

我们遇到的情况是，通过ODK Aggregate收集到MySQL数据库的几个月的数据是不可读的。

数据是格鲁吉亚字符，但是已发送到具有latin1字符集/排序规则的数据库。

数据管理员直到几天才发现这个问题，我从未意识到他们正在使用这些字符的调查......所以现在问题显然是 1）我们可以恢复现有数据吗？和 2）如何确保未来的数据可读？

我可以做一个 SELECT HEX（列）FROM表

并获取十六进制输出，但这看起来像：

3F3F3F3F203F3F3F3F3F3F3F3F203F3F3F3F3F3F3F3F3F
3F3F3F3F3F3F3F
E18397E18391E18398E1839AE18398E183A1E18398

正如您所看到的那样，最后一行看起来正确，但其他行则不然。当我用latin1创建一个测试表并尝试插入格鲁吉亚字符时，我得到了警告：＃1366字符串值不正确：＆＃39; \ xE1 \ x83 \ x93 \ xE1 \ x83 \ x93 ...＆＃39;对于专栏＆＃39; georgian_text＆＃39;在第1行

我在Tomcat日志中看不到任何内容，但我假设每次提交记录时Aggregate都会收到相同的错误。

我的问题是：第一行中的十六进制可以转换为有用的吗？

Answer 1

3F是char＆＃39;？＆＃39;

看起来这对我来说是有损数据;你无法将这些数据转换回可读的东西。

为避免这种情况，您需要在应用程序的所有层中使用相同的字符集。 UTF-8是一种流行的选择。

Answer 2

问题标记可能来自于此：

客户端有一个有效字符（好）和
SET NAMES同意客户端的编码（好），但
目标列的CHARACTER SET不包含预期的字符（错误）。

转换为'？'的字符无法从表中恢复。

更改表定义中的CHARACTER SET。（并重新加载你的文字）

Answer 3

我无法恢复丢失的内容，但为了记录起见，答案是从一开始就在/etc/my.cnf中始终有以下内容，因此这些问题首先不会发生。

character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'

转换＆＃34; ????＆＃34;在mysql中可读的东西？

3 个答案: