-1

我们遇到了这样一种情况，即通过 ODK Aggregate 收集到 MySQL 数据库中的几个月的数据无法读取。

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

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

我可以做一个 SELECT HEX(column) FROM table

并获得十六进制输出，但看起来是这样的：

3F3F3F3F203F3F3F3F3F3F3F3F203F3F3F3F3F3F3F3F3F
3F3F3F3F3F3F3F
E18397E18391E18398E1839AE18398E183A1E18398

如您所见，最后一行看起来正确，但其他行不正确。当我使用 latin1 创建一个测试表并尝试插入格鲁吉亚字符时，我收到警告：#1366 Incorrect string value: '\xE1\x83\x93\xE1\x83\x93...' for column 'georgian_text' at row 1

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

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

4

3 回答 3

0

问号可能来自于此：

  • 客户端具有有效的字符（良好），并且
  • SET NAMES同意客户端的编码（好），但是
  • 目标列CHARACTER SET不包含预期的字符（错误）。

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

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

于 2015-08-28T04:56:04.577 回答
0

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

character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'
于 2016-08-05T13:34:24.127 回答
0

3F 是字符 '?'

看起来这对我来说是有损数据；您将无法将此数据转换回可读的内容。

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

于 2015-08-11T16:16:24.507 回答