Java 程序向数据库存储数据时出现乱码，是开发中常见且令人头疼的问题，乱码的本质是字符编码不一致导致的解码错误——数据在 Java 应用层以某种编码生成，经过 JDBC 传输、数据库存储等环节时，若任一环节的编码设置与应用层不匹配，就会出现“张冠李戴”的解码情况，最终导致显示为乱码，要解决这一问题，需从 Java 应用层、JDBC 连接层、数据库存储层三个核心环节逐一排查编码配置，确保各环节编码一致。
Java 应用层编码问题：数据生成的“第一道关口”
Java 应用层是数据产生的源头，若此处编码处理不当，后续环节无论如何配置都难以纠正乱码，常见问题包括：
字符串编码隐式转换
Java 中 String 类型采用 UTF-16 编码，但与外部交互（如读取文件、接收 HTTP 请求）时，若未明确指定编码，会使用系统默认编码（如 Windows 常为 GBK，Linux 常为 UTF-8），导致编码错乱，从文件中读取数据时，若使用 Files.readAllLines() 未指定编码，会依赖系统默认编码解码文件，而文件实际可能是 UTF-8 编码，从而生成乱码字符串。
解决方案：所有涉及外部数据读取、写入的操作，均需显式指定 UTF-8 编码。
- 读取文件：
Files.readAllLines(Paths.get("file.txt"), StandardCharsets.UTF_8)； - 接收 HTTP 请求：在 Spring Boot 中配置
server.servlet.encoding.enabled=true和server.servlet.encoding.charset=UTF-8； - 字符串转字节数组：
string.getBytes(StandardCharsets.UTF_8)（避免使用无参getBytes()，它会使用系统默认编码）。
JDBC 连接层编码问题：数据传输的“必经之路”
JDBC 连接是 Java 应用与数据库之间的“桥梁”，连接参数中的编码配置直接影响数据传输过程中的编码转换，若 JDBC 连接编码与数据库存储编码不一致，数据在传输过程中会被错误解码，导致存入数据库后乱码。
JDBC URL 缺少编码参数
以 MySQL 为例，JDBC URL 若未明确指定 useUnicode 和 characterEncoding 参数，驱动会使用数据库默认编码（如 latin1），导致 UTF-8 数据被强制转换为 latin1，存入后变成乱码，错误的 URL：jdbc:mysql://localhost:3306/test?useSSL=false，正确的应为：jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8。
驱动版本与编码兼容性
部分旧版本 JDBC 驱动对 UTF-8 编码支持不完善，尤其是 MySQL 5.7 之前的驱动，可能存在 characterEncoding 参数失效的问题，建议升级到最新稳定版驱动，如 MySQL Connector/J 8.0+，其对 UTF-8 和 utf8mb4 编码支持更完善。
解决方案：
- JDBC URL 中必须添加
useUnicode=true&characterEncoding=UTF-8（或 utf8mb4，见后文）； - 定期更新 JDBC 驱动版本，确保编码兼容性；
- 避免在连接池配置中覆盖编码参数（如 Druid 连接池的
url属性需完整包含编码参数）。
数据库存储层编码问题：数据持久化的“最后一公里”
数据库存储层的字符集设置是乱码问题的“最后一道防线”，若此处编码与 JDBC 传输编码不一致，数据即使正确传输到数据库，也会被以错误编码存储，导致读取时乱码。
数据库服务器级字符集
数据库服务器的默认字符集（如 MySQL 的 character-set-server）会影响新建数据库的默认字符集，若 character-set-server 设置为 latin1，新建数据库的默认字符集可能也是 latin1，导致即使 JDBC 传输 UTF-8 数据，数据库也会尝试用 latin1 解码，最终存储乱码。
数据库与表级字符集
单个数据库或表的字符集可独立配置,若数据库字符集为 utf8，但表的字符集为 latin1，存入该表的数据仍会乱码，MySQL 的 utf8 编码仅支持 3 字节的字符（如 Emoji 表情、某些生僻字），若数据包含此类字符，存入 utf8 表会导致截断或乱码，需使用 utf8mb4（4 字节 UTF-8）。
字符集校对规则（Collation）
字符集校对规则（如 utf8_general_ci）影响字符比较，但不会直接导致乱码，不过若校对规则与字符集不匹配（如将 utf8mb4 字段的校对规则设为 latin1_general_ci），可能引发隐式编码转换，间接导致乱码。
解决方案：
- 修改数据库服务器字符集：
ALTER DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci； - 修改表字符集：
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci； - 新建数据库/表时，显式指定字符集为
utf8mb4（推荐，兼容性更好）； - 查看当前字符集：
SHOW VARIABLES LIKE 'character_set_%'（服务器级）、SHOW TABLE STATUS LIKE 'table_name'（表级）。
综合解决方案与最佳实践
乱码问题的根源是“编码不一致”，解决的核心是“统一编码”，以下是完整的排查与解决流程：
- 统一编码标准：全链路（Java 应用、JDBC 连接、数据库存储）统一使用
utf8mb4（推荐）或UTF-8，避免混用； - 应用层检查：确保所有外部数据交互（文件、HTTP、网络请求）均显式指定 UTF-8 编码；
- JDBC 连接检查：URL 中添加
useUnicode=true&characterEncoding=utf8mb4，驱动升级至最新版； - 数据库层检查：服务器、数据库、表、字段字符集均设置为
utf8mb4，校对规则使用utf8mb4_unicode_ci； - 测试验证：插入包含中文、Emoji、特殊字符的数据，查询验证是否正常显示，避免“局部乱码”（如部分字符正常，部分乱码）。
Java 存储数据库乱码问题，本质是编码链路中任一环节的“断裂”，需从 Java 应用层的数据生成、JDBC 连接层的数据传输、数据库存储层的数据持久化三个层面逐一排查，确保各环节编码一致（推荐全链路 utf8mb4），通过显式指定编码、更新驱动、正确配置数据库字符集，并严格测试验证，可有效避免乱码问题，保障数据的完整性和一致性。
