Windows安装PostgreSQL后JDBC连接异常：错误信息乱码问题

前言：Windows环境部署PostgreSQL并通过JDBC连接时，常出现诡异问题——数据库连接失败后，即便异常是简单英文提示（如FATAL: database “XXX” does not exist），控制台输出仍为乱码。

一、问题发生现场

• 环境： Windows 10/11 中文简体、PostgreSQL 14/15、Java+JDBC（驱动42.5.4），数据库SERVER_ENCODING、CLIENT_ENCODING均为UTF8。
• 问题现象： 通过JDBC连接错误数据库名（ps.刚开始我也未发现是因为自己在url中将数据库名称写错，如果看到此处您也可以检查一下自己是否写错了）时，控制台输出异常乱码，即使实际为英文字符错误提示。
• 排查过程： 排除JDBC驱动、服务器/客户端编码问题后，发现LC_COLLATE、LC_CTYPE为系统默认Chinese.936（GBK），推测为乱码根源。

二、问题发生的根本原因

• 核心误区： 仅设置SERVER_ENCODING和CLIENT_ENCODING为UTF8，无法完全避免乱码，LC_COLLATE和LC_CTYPE对错误信息输出至关重要。

关键参数核心作用：

1. SERVER_ENCODING：数据库存储数据的编码，初始化时指定；
2. CLIENT_ENCODING：客户端与服务器通信编码，JDBC可通过characterEncoding指定；
3. LC_COLLATE：控制字符串排序，影响order by等操作；
4. LC_CTYPE：控制字符分类，决定PostgreSQL错误信息的编码格式。

• 乱码核心逻辑： Windows默认Locale为GBK（Chinese.936），PostgreSQL未指定LC参数时会继承该编码；错误信息按LC_CTYPE（GBK）编码后，被JDBC客户端（UTF8）解码，因GBK与UTF8不兼容，导致乱码。即使是英文错误，也会按LC_CTYPE编码，这是英文乱码的关键原因。
• 注意： LC_COLLATE和LC_CTYPE创建数据库后无法直接修改，需重新初始化集群。

三、解决方法

将LC_COLLATE和LC_CTYPE设置为与UTF8兼容的格式（推荐C或zh_CN.UTF-8）。

方案一：修改现有数据库的LC参数（需备份数据）

操作流程： 停止服务→备份数据→删除集群→重新初始化→重启服务→恢复数据→验证配置。

步骤如下：

1. 停止PostgreSQL服务：服务中停止“postgresql-x64-15”，或管理员CMD执行“net stop postgresql-x64-15”。
2. 备份数据：进入PostgreSQL的bin目录，执行备份命令（替换占位符）：:: 备份指定数据库 pg_dump -U postgres -d 数据库名 -f 备份路径.sql :: 备份所有数据库 pg_dumpall -U postgres -f
   备份路径.sql
3. 删除数据库集群：删除默认路径（C:\Program Files\PostgreSQL\15\data）下所有文件（建议先备份该目录）。
4. 重新初始化集群：bin目录执行命令（替换路径），指定编码和LC参数：
   initdb -D “C:\Program Files\PostgreSQL\15\data” -E UTF8 --lc-collate=C --lc-ctype=C -U postgres -W
5. 重启服务：服务中启动，或CMD执行“net start postgresql-x64-15”。
6. 恢复数据：bin目录执行恢复命令（替换占位符）：
   psql -U postgres -d 新数据库名 -f 备份路径.sql
7. 验证配置：执行SQL查询参数，确认均为兼容格式：
   SELECT name, setting FROM pg_settings WHERE name IN (‘server_encoding’, ‘client_encoding’, ‘lc_collate’, ‘lc_ctype’);

方案二：安装时主动指定LC参数

安装流程中，进入Locale设置界面，不选默认“Default locale”，直接选择“C”（或zh_CN.UTF-8，需Windows安装对应区域包），后续按提示完成安装即可。安装后验证参数，正常配置JDBC连接即可避免乱码。

四、Linux服务器无此问题的原因

Linux服务器默认无乱码，核心是系统Locale与PostgreSQL编码兼容性更好。多数Linux发行版（CentOS、Ubuntu）默认Locale为UTF8编码（如en_US.UTF-8、zh_CN.UTF-8），PostgreSQL未指定LC参数时，会自动继承该UTF8类Locale。此时LC参数与SERVER_ENCODING（默认或手动设为UTF8）完全兼容，错误信息编码与客户端UTF8编码一致，无需额外配置即可避免乱码。而Windows默认Locale为GBK，才会出现兼容性问题。

五、总结

本次乱码本质是LC_CTYPE（GBK）与CLIENT_ENCODING（UTF8）不兼容导致的字符转换失败，与SERVER_ENCODING、JDBC驱动无关。
核心解决方案： 数据库初始化（安装或重新初始化）时，主动指定LC_COLLATE和LC_CTYPE为与UTF8兼容的格式，从根源避免乱码。
忽略Locale设置是常见误区，希望本文能帮开发者快速定位、解决问题。如有疑问，欢迎评论区留言讨论。