问题根源拆解 #

你的情况是典型的编码转换链路错误导致的"假正常真乱码"，具体逻辑是这样的：

1. VB6时代的编码错位：VB6默认依赖系统本地代码页（阿拉伯语系统对应Windows-1256），虽然你把ODBC和MySQL都设成了UTF8，但旧版ODBC 3.51驱动对UTF8的支持有严重缺陷——它并没有把VB6的Unicode字符串正确转成UTF8字节写入数据库，反而直接把Windows-1256编码的字节当成UTF8存了进去。
2. VB6能正常显示的原因：读取数据时，ODBC驱动又把这些错误的UTF8字节按Windows-1256解析回字符串，相当于反向抵消了之前的错误，所以看起来显示正常，但数据库里的内容本质是不符合UTF8规范的乱码字节。
3. 工具显示差异：旧版SQLyog大概率默认用了Windows-1256编码连接数据库，读取时自动做了反向转换，所以显示正常；而MySQL Query Browser严格按UTF8解析这些错误字节，自然就显示成乱码了。
4. .NET的问题：.NET默认用UTF8/Unicode处理数据库交互，读取时直接按UTF8解析这些错误存储的字节，所以就出现了你看到的乱码。

分步解决方法 #

1. 先确认数据库编码状态

登录MySQL执行以下命令，确认编码配置：

-- 查看全局及数据库编码
SHOW VARIABLES LIKE 'character_set%';
-- 查看目标表的编码
SHOW CREATE TABLE chairs;

确保character_set_database、character_set_table都是utf8（注意MySQL 5.0的utf8实际是utf8mb3，不影响本次修复）。

2. 修复已存储的乱码数据

数据库里的字节是Windows-1256被错误当成UTF8存储的，需要做反向转换修复：

-- 备份表后执行！
UPDATE chairs 
SET Nam = CONVERT(BINARY CONVERT(Nam USING utf8) USING cp1256);

逻辑解释：先把乱码字节按UTF8解析成错误字符串，再转成对应字节，最后按Windows-1256（MySQL里叫cp1256）解析回正确的阿拉伯语，MySQL会自动按UTF8重新存储这个正确字符串。

执行后用MySQL Query Browser验证，应该能正常显示阿拉伯语了。

3. 配置.NET应用的连接字符串

用官方MySQL Connector/NET驱动的话，连接字符串必须显式指定编码，避免再次出错：

// 示例连接字符串
"Server=你的服务器地址;Database=你的库名;Uid=用户名;Pwd=密码;CharSet=utf8;"

不要依赖系统默认编码，必须明确写CharSet=utf8，确保驱动和数据库的编码转换完全一致。

4. 验证.NET的字符串处理

.NET字符串本身是Unicode，只要驱动正确把UTF8转成Unicode，UI控件（只要字体支持阿拉伯语，现代控件都满足）就能正常显示，无需额外设置。

额外注意事项 #

• 旧ODBC 3.51驱动的UTF8支持确实拉胯，如果还要维护VB6应用，修复数据后可能需要把VB6的ODBC编码改成Windows-1256，但这样会和.NET的UTF8连接冲突，最好的方案是统一用UTF8连接，给VB6升级到ODBC 5.x及以上版本的驱动来适配UTF8。
• 重要：执行UPDATE修复前，一定要备份chairs表，避免操作失误丢数据！

内容的提问来源于stack exchange，提问作者Youssef El-Masri