Appearance
编码与乱码问题排查
串口发来的数据显示乱码、CSV 文件用 Excel 打开是乱码、日志文件里的中文变成方块——这些问题在 AI 辅助开发中容易被误诊。
最常见的错误做法是：看到乱码就切换 GBK/UTF-8。这可能在特定情况下碰巧有效，但更可能让问题变得更糟。
为什么不能简单切换编码
乱码可能出现在多个环节，每个环节的原因不同。
源代码文件乱码
.cs 文件保存时使用了和项目不一致的编码。IDE 打开时显示正常，其他人打开显示乱码。
串口数据乱码
接收到的字节没有按正确编码解析。设备可能使用自定义编码或非标准字符集。
CSV 文件乱码
写入时用 UTF-8 但没有写 BOM，或者写入用 GBK 但 Excel 默认用 UTF-8 打开。
两个关键认知
- 二进制协议中的数据不能随意用文本编码解码——乱码可能是你错误地把二进制数据当成文本处理了。
- 切换编码方式保存原文件可能造成二次损坏——更改源文件编码不能修复协议解析错误。
五步排查法
按以下顺序排查，不要跳过步骤。
1. 确认乱码位置 — 源代码 / UI 显示 / 串口接收 / 网络接收 / 文件 / 数据库 / 日志 / 控制台2. 确认数据类型 — 纯文本 / 二进制数据帧 / JSON / CSV / 协议字段3. 确认原始编码 — UTF-8 / GBK / GB2312 / Unicode / ASCII / 设备自定义编码4. 定位转换环节 — Encoding.GetString / 文件读写 / 数据库连接串 / 日志组件 / StreamWriter5. 验证原始字节 — 通信数据先保留十六进制原始字节，确认编码假设是否正确
步骤详解
第一步：确认乱码位置。 同一个乱码出现在不同位置，原因可能不同。在源代码中是乱码和在运行界面中是乱码，排查路径完全不同。
第二步：确认数据类型。 串口收上来的数据不一定就是文本。很多设备协议是二进制帧，包含状态位、校验码和数值字段——这些不能用 Encoding.GetString 直接转成字符串。
第三步：确认原始编码。 问三个问题：设备文档说编码是什么？之前正常时是什么编码？协议里有没有编码标识字节？
第四步：定位转换环节。 C# 中最常见的编码转换点：
| 环节 | 相关代码 | 排查方向 |
|---|---|---|
| 字节转字符串 | Encoding.UTF8.GetString(bytes) | 确认设备和代码使用相同编码 |
| 文件写入 | new StreamWriter(path, false, Encoding.UTF8) | 确认写入编码和读取编码一致 |
| 文件读取 | File.ReadAllText(path) | 不带编码参数时默认 UTF-8，可能与文件实际编码不一致 |
| 数据库 | charset=utf8mb4 连接串 | 确认数据库、表和连接串编码一致 |
| 日志组件 | NLog / Serilog / log4net 配置 | 检查日志组件的编码配置 |
第五步：验证原始字节。 在排查阶段，保留通信数据的原始十六进制字节。对照协议文档逐字节分析，而不是凭猜测切换编码。
保留原始字节的方法
- 通信数据先存原始 byte[]，不要立即转字符串。
- 用 BitConverter.ToString(bytes) 输出十六进制日志。
- 对照协议文档逐字节分析帧头、数据区和校验码。
- 确认哪些字节是文本字段，哪些是数值字段。
关键规则
乱码排查红线
- 串口数据不一定是文本——先确认协议类型。
- 二进制协议不能随意解码——数值字段用 Encoding 解码会得到乱码。
- 更改源文件编码不能修复协议错误——这是两个独立的问题。
- 中文字体缺失也可能表现为乱码——UI 显示方块不等于编码错误。
- 编码修改前保留原始文件——用 `git diff` 确认只改了编码，没有改变内容。
- 全项目统一编码标准——在 PROJECT_CONTEXT.md 中明确项目的编码约定。
与案例的关联
本站案例 A 中的「电流状态误判」问题，根因之一就是数据解析时的编码假设错误。详情参考：