linux informix为何乱码

在 Linux 上使用 Informix 出现乱码，通常不是数据库本身坏了，而是字符集（locale / codeset）不一致导致的。下面按最常见原因 → 排查方法 → 解决办法来说明。

一、最常见原因（90% 的情况）

1️⃣ 客户端与数据库字符集不一致

Informix 乱码，核心只有一个：

写进去的编码 ≠ 读出来的编码

常见组合：

数据库：en_US.819（ISO-8859-1）
客户端：zh_CN.UTF-8
结果：中文全乱码

2️⃣ Linux 环境变量未设置或设置错误

Informix 依赖以下环境变量：

LANG
LC_ALL
DB_LOCALE
CLIENT_LOCALE

如果没设或设错，就会按默认编码解释数据。

3️⃣ 数据库创建时字符集不支持中文

例如：

en_US.8859-1
en_US.819

这些 不支持中文，存中文必乱。

4️⃣ 终端 / SSH 客户端编码不对

比如：

服务器是 UTF-8
你的 SecureCRT / Xshell 是 GBK

看到的就是“假乱码”。

二、如何快速判断问题在哪

✅ 1. 看数据库字符集

dbaccess - -
SELECT dbs_collate FROM sysmaster:sysdbslocale;

或：

onstat -d

常见中文支持字符集：

zh_CN.utf8
zh_CN.gb18030
en_US.utf8

✅ 2. 看当前环境变量

env | grep -E "LANG|LC_|DB_LOCALE|CLIENT_LOCALE"

✅ 3. 看终端编码

echo $LANG

三、正确配置示例（UTF-8 场景）

服务端（数据库是 UTF-8）

export LANG=zh_CN.UTF-8
export DB_LOCALE=zh_CN.utf8

客户端（也是 UTF-8）

export CLIENT_LOCALE=zh_CN.utf8
export LANG=zh_CN.UTF-8

四、GBK / GB18030 场景（老系统）

export DB_LOCALE=zh_CN.gb18030
export CLIENT_LOCALE=zh_CN.gb18030
export LANG=zh_CN.GB18030

五、已经乱码了，能恢复吗？

⚠️ 一般不能自动恢复

如果：

数据按 UTF-8 写
却用 GBK 读（或反过来）

→ 编码已错位，数据本身已损坏

✅ 只能：

重新导入正确编码的数据
或从备份恢复

六、最佳实践（强烈建议）

✅ 全链路统一为 UTF-8
✅ 建库时明确指定 locale
✅ 所有客户端统一设置 CLIENT_LOCALE
✅ 不依赖默认编码

七、如果你愿意，我可以更精准帮你

你可以贴出：

SELECT dbs_collate FROM sysmaster:sysdbslocale;
env | grep -E "LANG|LC_|DB_LOCALE|CLIENT_LOCALE"
乱码示例（复制几行）

我可以直接告诉你是哪一层编码错了，该怎么改。