SQL查询varchar字段西里尔字符返回问号乱码问题咨询

• 「插入无异常」是假象：普通varchar类型的字符集和字段/表的排序规则强绑定，如果字段用了latin1、gbk这类不支持西里尔字符的编码，数据库写入时不会主动抛错，会直接把识别不了的西里尔字符静默替换成占位符存进去，等到查询读取时，这些占位符就会直接显示为??????。
• 连接层编码不匹配：如果库表字段本身用了cp1251、utf8mb4这类支持西里尔的编码，问题基本出在客户端和数据库的连接配置上——服务端按西里尔兼容编码返回结果，但你的程序连接串、可视化客户端配置了不支持西里尔的编码解码结果，无法识别的字符就会被渲染成问号。
• 极小概率是展示层问题：查看查询结果的终端、编辑器所选字体不包含西里尔字符集，无法正常渲染字符。

1. 先确认存储层的内容是否正确，不要被插入时的无报错误导
   执行SQL查询对应字段的十六进制值，以常见西里尔词Привет为例，utf8mb4编码下正确的十六进制值为D09FD180D0B8D0B2D0B5D182，如果查询结果全为3F（即问号?的ASCII编码），说明写入环节就已经存成乱码：

   -- 替换表名、字段名、查询条件为实际业务值
   SELECT HEX(target_cyrillic_col) FROM target_table WHERE id = 1;
   

   这类情况的修复方式：
   • 统一调整数据库、表、字段三级的字符集为utf8mb4，排序规则可按需选择通用的utf8mb4_general_ci或西里尔专用的utf8mb4_cyrillic_ci，不要继续混用不支持西里尔的编码；如果业务后续有多语言存储需求，建议直接换用nvarchar类型避免后续编码问题。
   • 调整完编码后重新写入正确的西里尔内容，写入前保证连接层编码和库表编码一致。
2. 如果十六进制查询结果和正确编码值匹配，说明存储本身没问题，故障点在连接读取层
   • 程序侧连接数据库时，强制在连接串中指定和库表一致的字符集，比如JDBC连接需附加characterEncoding=utf8参数，MySQL原生连接可在连接建立后执行SET NAMES utf8mb4，确保连接传输、结果返回、元数据校验三个环节的编码完全统一。
   • 如果用Navicat、DBeaver等可视化客户端查询，打开连接配置页，手动将连接编码设置为和库表一致的西里尔兼容编码，不要使用默认的自动检测或latin1编码。
3. 最后排查展示层：确认查看结果所用的终端、编辑器选择的字体覆盖西里尔字符集，不要使用仅支持中英文的窄字符集字体。

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