【问题标题】:Displaying japanese characters from SQLException.getMessage()从 SQLException.getMessage() 显示日文字符
【发布时间】:2014-07-01 05:40:48
【问题描述】:

我有一个简单的类,它显示数据库中包含日文字符的记录。 类文件的字符编码为 UTF-8。我还更改了数据库以使用字符集 UTF-8。

在控制台上显示包含日文字符的记录没有问题。硬编码也没问题。

但是当我尝试输入与旧记录之一具有相同用户 ID(表中的主键)的记录时。它抛出显示重复条目错误消息的 SQLException。但它显示垃圾字符。喜欢:

Duplicate entry 'ラケシュ12345' for key 1

那么究竟是什么问题。为什么记录显示正确但SQLException.getMessage();

【问题讨论】:

  • 感谢您提供有关能够在控制台上显示有效记录和硬编码消息中的字符的部分 - 这节省了一些探索途径。
  • 错误抛出并显示在哪里?系统控制台、IDE控制台、日志文件等?
  • 错误被抛出到 Eclipse IDE 控制台和 JSP 页面。 (结果相同)
  • 嘿,错误信息是从 MySQL 文件中复制过来的(如果他们在文件中存储了错误信息,可能不是 UTF-8)????因为Exception类和MySQL工具的错误信息是一样的。
  • 从哪里初始化这个错误信息到异常对象?

标签: java mysql


【解决方案1】:
ラケシュ12345

正确吗?

INSERTing 时可能发生了什么

  • 您对数据进行了正确的 utf8 编码,并且
  • SET NAMES latin1 -- 默认或错误设置,并且
  • 存储文本的列(或表)使用CHARACTER SET latin1 声明,可能也是默认情况下。

您可以通过以下方式验证数据是否正确存储

SELECT col, HEX(col) ...

如果您获取该字符串,则十六进制将为E383A9E382B1E382B7E383A5EFBC91EFBC92EFBC93EFBC94EFBC95。请注意如何有 6 个十六进制的组,在片假名的情况下以 E383 开头,对于“全角数字”,以 EFBC 开头。

假设表仍然显示 latin1,则没有数据丢失,2-step ALTER 将修复它。总结:

ALTER TABLE Tbl MODIFY COLUMN col VARBINARY(...) ...;
ALTER TABLE Tbl MODIFY COLUMN col VARCHAR(...) ... CHARACTER SET utf8 ...;

长度足够大并且其他“...”具有其他任何内容(NOT NULL 等)已经在列上。

(直到最近我才能清楚完整地回答这个问题。)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-04-29
    • 1970-01-01
    • 2015-09-17
    • 2018-06-16
    • 2016-02-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多