Ubuntu下adodb-php连接SQL Server数据显示格式错误如何解决

算力阿峰

2026-8-28

问题产生原因

根源是历史遗留的双重编码存储错误：原Windows环境下程序写入数据时就发生了编码错误——正确的UTF-8编码越南语字符串Trương Thị Ánh Tuyết，被错误按Windows默认代码页CP1252（Latin1系编码）解读后，二次转码为UTF-8存入NVARCHAR字段，数据库中实际存储的字节本身就是乱码TrÆ°Æ¡ng Thá»‹ Ãnh Tuyáº¿t，从始至终数据都没有被正确存储。
Windows环境显示正常属于巧合：Windows平台旧版SQL Server驱动默认会对查询返回的字符做自动转码，将拿到的内容按CP1252编码反向转换为UTF-8，刚好抵消了之前双重编码的错误，属于驱动默认行为碰巧掩盖了存储问题，不是数据本身正确。
Ubuntu环境显示乱码是驱动逻辑差异导致：Linux平台的SQL Server驱动默认使用UTF-8字符集，不会自动执行那层CP1252反向转码，直接把数据库里存储的原始乱码字节原样返回，因此输出了乱码内容。

修复方案

可根据实际运维需求二选一：

方案一：彻底修复（推荐，无长期维护隐患）

注意：执行数据修复前必须全量备份数据库，先通过SELECT语句验证转码结果完全正确，再执行更新操作，避免数据不可逆损坏。

把存量错误数据全部修正为正确的UTF-8字符，之后统一规范数据库连接、程序读写的字符集为UTF-8，彻底消除不同环境的编码兼容问题。
数据修复核心逻辑：将字段内存储的双重编码内容转为二进制流，再按CP1252编码重新解析为字符，即可得到正确原文，单表示例修复代码：

-- 第一步：查询验证转码结果是否正确
SELECT 
  name AS old_wrong_name,
  CAST(CAST(name AS VARBINARY(MAX)) AS VARCHAR(MAX)) COLLATE SQL_Latin1_General_CP1_CI_AS AS correct_name
FROM users;

-- 第二步：确认结果无误后执行更新
UPDATE users 
SET name = CAST(CAST(name AS VARBINARY(MAX)) AS VARCHAR(MAX)) COLLATE SQL_Latin1_General_CP1_CI_AS;

存量数据修复完成后，在PHP代码中强制指定数据库连接字符集为UTF-8，避免后续新增数据再出现编码问题：

<?php
ini_set('display_errors', 1);
include 'vendor/adodb/adodb-php/adodb.inc.php';
include 'vendor/adodb/adodb-php/adodb-errorhandler.inc.php';

$db = ADONewConnection('mssqlnative');
$db->setConnectionParameter('CharacterSet', 'UTF-8');
$db->connect('localhost,1433','sql','sql@12345','test');
$db->Execute("SET NAMES utf8");

方案二：临时兼容（快速恢复业务，不修改存量数据）
如果暂时无法调整存量数据，可以在PHP代码中手动模拟Windows驱动的转码逻辑，将查询返回的乱码反向转换为正确内容，快速恢复显示：
```
<?php
$sql = "select top 1 name from users";
$array = $db->getAll($sql);
// 手动执行编码反向转换
$correct_name = mb_convert_encoding($array[0][0], 'UTF-8', 'ISO-8859-1');
print_r($correct_name);exit;
```
该方案仅为临时适配，后续新增数据如果继续沿用旧的错误存储逻辑，会持续累积技术债务，长期维护成本极高，业务稳定后建议切换为方案一彻底修复。

内容的提问来源于stack exchange，提问作者Harry