MySQL CHAR USING 怎样指定字节序列的解码字符集

MySQL 可以用 CHAR(整数列表 USING 字符集名) 构造指定字符集的字符串。USING 描述的是结果字节应采用的字符集，不能把 CHAR 的每个整数都当成 Unicode 码点。比如 UTF-8 的 é 对应字节 C3 A9，应使用十进制 195、169 构造，而不是直接把 U+00E9 的十进制 233 填进去。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/string-functions.html

先区分字节值与 Unicode 码点

导入任务收到“195,169”这类数值列表时，先确认上游提供的是字节还是码点。同样看起来像整数，约定不同，SQL 的写法就不同。本文以 MySQL 8.4、已确认的 UTF-8 字节列表为例，只演示表达式，不创建或修改业务表。

不要将 CHAR() 函数与 CHAR 列类型混为一谈：这里讨论函数如何生成字符串，不讨论定长字段。若源数据其实是十六进制文本，也应先明确它是否已转换成字节，而不是把字符“C3A9”直接作为字符内容处理。

用 USING 为构造结果指定字符集

先看最小写法，再把不带 USING 的结果并排观察。下面语句供目标 MySQL 环境使用，文中没有执行数据库或展示实测回执。

-- 用两个已确认的 UTF-8 字节构造字符，预期文本为 é
SELECT CHAR(195, 169 USING utf8mb4) AS decoded_text;
-- 对照相同内容的十六进制值和字符集属性
SELECT
    HEX(CHAR(195, 169)) AS raw_hex,
    CHARSET(CHAR(195, 169)) AS raw_charset,
    HEX(CHAR(195, 169 USING utf8mb4)) AS text_hex,
    CHARSET(CHAR(195, 169 USING utf8mb4)) AS text_charset;

两种构造的字节预期都是 C3A9；不带 USING 的默认结果属于 binary，显式指定后结果使用 utf8mb4。这里改变的重点是结果的字符集解释，不能据此推断函数已经把任意来源编码转换成 UTF-8。

同时观察字节、长度和结果属性

排查乱码时，显示出来的“é”或“0xC3A9”只是一层现象。客户端可能以十六进制展示二进制值，因此最好同时保留 HEX、LENGTH、CHAR_LENGTH 和 CHARSET 四个观察角度。

-- 在同一个表达式结果上比较字节数、字符数与字符集
SELECT
    HEX(sample.value) AS bytes_hex,
    LENGTH(sample.value) AS byte_count,
    CHAR_LENGTH(sample.value) AS character_count,
    CHARSET(sample.value) AS result_charset
FROM (
    SELECT CHAR(195, 169 USING utf8mb4) AS value
) AS sample;
-- 非法序列示例：单独的 E9 不是完整 UTF-8 字节序列
SELECT CHAR(233 USING utf8mb4) AS invalid_utf8;
-- 紧跟上一条语句读取诊断，不在中间插入其他业务查询
SHOW WARNINGS;

合法样例预期为字节数 2、字符数 1。非法序列会产生诊断，在严格 SQL 模式下结果可为 NULL；不要把它悄悄替换成空串然后宣称导入成功。实际处理应结合连接的 SQL 模式和诊断信息，而不是依赖某个客户端恰好显示了什么。

把解码约定固定在数据入口

数据入口应记录来源编码、输入表示形式和目标字符集。收到字节列表时按确认的字节解释处理；收到已经具有正确字符集的文本时，不应绕回整数再重建。把“修复显示”与“修复源数据”分开，才不会在下一轮导出时重复损坏内容。

字符集名应由应用维护的明确选项选择，不能把任意用户字符串拼进 USING。批量导入还应让异常行可追溯，保留原始值及失败原因；转换不成功时，暂缓该行比覆盖掉原值更便于纠错。

如果表达式之后要写入表，还要考虑目标列和连接的字符集约定。本文的 SELECT 只能说明表达式结果，不证明整条导入链路已经正确；正式接入时应由项目针对真实样本确认保存和读回语义。

CHAR(233 USING utf8mb4) 为什么不是 é？

233 对应单个字节 E9，而 é 的 UTF-8 字节是 C3 A9。把码点数值误当成该编码的字节，是这里的核心混淆。

字符数为 1 就表示内容一定正确吗？

不表示。错误编码也可能形成可解码的字符。还需要对照来源约定与期望文本。

看到十六进制结果是否说明乱码？

不一定。二进制结果的展示策略会影响外观，应先查看字节与结果字符集，再判断显示层问题。

这类问题的关键不是反复换 USING 参数，而是先确认整数代表什么，再按相同的输入约定解释输出。