作为项目的一部分，我们需要从 Ubuntu 14.04 迁移到 Ubuntu 16.04。但是，自升级完成后，所有功能都无法正常运行。存储在数据库中时字符的编码是混乱的。相同的 debian 版本的软件会产生不同的结果，这意味着 ISO 问题与不同的库或 Java 行为存在一些差异。升级后的服务器没有遇到任何问题，它只在较新的安装上持续存在，这意味着 ISO 级别存在问题，但没有明显迹象表明哪个库或类似库可能安装失败。添加了日志记录以打印接收到的字节，并且 Java 仍然按预期读取它。但是，当它把它们存储在数据库中时，它们就完全不同了。这是通过之前的 JPA 连接设置完成的。这已经在使用“useUnicode=true&characterEncoding=UTF-8”字段。当 Java 再次读取此数据时，它仍然认为它使用的是正确的字节，但实际上并非如此。同样，如果你直接向数据库中添加一些东西，Java 的调试日志不会显示正确的字节，但是当通过只能通过这里的接口显示时，信息仍然正确显示。这意味着问题在于存储数据而不是处理数据，但是相同版本的 debian 安装会影响两个版本。例如，阿拉伯语中的 شلاؤ 应该被编码为（通过在 mysql/mariadb 中使用十六进制函数），在正确的版本中显示为“D8B4D984D8A7D8A4”，但在不正确的版本中显示为“C398C2B4C399C284C398C2A7C398C2A4”。这可能会提供有关编码无法正常工作的原因的更多信息。Java 读取不正确的字节就好像它们是正确的一样，这更可能是 Java 的问题，但由于系统之间的不一致，混乱仍然存在。
2 回答
噜噜哒
TA贡献1784条经验 获得超7个赞
对于可能遇到类似情况的任何人，结果是 Java 在没有默认为 utf8 的情况下运行。OpenEJB/JPA 配置正确，数据库也是如此，但服务器的一个方面默认为不同的字符集，因此受影响区域的启动参数解决了问题！
aluckdog
TA贡献1847条经验 获得超7个赞
D8B4D984D8A7D8A4是正确的 utf8（或 utf8mb4）编码شلاؤ。 C398C2B4C399C284C398C2A7C398C2A4是“双编码”版本。这意味着某些东西仍然指定“latin1”作为字符集。也许您转储并重新加载了数据，这就是它发生的地方？
有关更多信息，请参阅UTF-8 字符问题；我看到的不是我存储的，也许是http://mysql.rjweb.org/doc.php/charcoll
添加回答
举报
0/150
提交
取消