Keil中文乱码不是显示问题，是工程链路的编码失配
你有没有遇到过这样的场景：
在main.c里写了一行清晰的中文注释// 初始化LED驱动模块，保存后编辑器看着正常；
编译时却突然冒出警告：warning: multi-character character constant [-Wmultichar]；
调试时想在“Watch”窗口监视一个叫系统状态标志的全局变量，结果只看到一串问号??；
更诡异的是，断点打在void 中文函数名(void)上，运行时根本不停——仿佛这个函数不存在。
这不是Keil“抽风”，也不是字体没装好。这是整个工具链在悄悄地、一致地误解你的中文。从你按下 Ctrl+S 的那一刻起，到调试器在内存里查找变量符号的那微秒之间，至少有五个关键环节可能把“中”字（0xE4 0xB8 0xAD）错读成三个独立的非法字节。而一旦出错，它不会报错，只会静默地生成错误的符号表、错误的调试信息、错误的Flash映像——直到你在产线现场花三小时才定位到，原来是因为头文件路径名里有个“配置”二字。
这个问题在 uVision4 和 uVision5 上表现截然不同，但根源高度一致：Keil 不做编码协商，只做单向解析；它不猜你写了什么，只信它“以为”你写了什么。
编码不是设置项，是贯穿全链路的契约
很多工程师第一反应是：“去设置里调个字体/改个编码选项就行”。但真相是：Keil IDE 本身并不解析 C 语言，它只是个“管道工”——把文件交给编译器，把符号交给调试器，把二进制交给烧录器。真正决定中文能否存活的，是这三层协同是否达成统一编码契约：
编辑器层：你看到的“中文”，其实是 Windows API（如
MultiByteToWideChar(CP_ACP, ...)）按当前系统代码页（通常是 CP936/GBK）转出来的。uVision4 默认吃这套，所以新建文件就是 GBK；uVision5 却绕过了系统API，直接用 UTF-8 解释字节流——于是同一个中文.h文件，在两个IDE里打开，一个显示正常，一个满屏乱码。项目配置层：
.uvprojx是 XML 文件，而 XML 标准强制要求声明编码。uVision5 严格遵守：如果文件开头没有< ?xml version="1.0" encoding="UTF-8"?>或者实际不是 UTF-8 编码，它就拒绝加载中文路径、中文宏定义，甚至直接报错Invalid project file。uVision4 则宽容得多，能硬着头皮把 GBK 字节当 XML 解析——结果是工程能开，但某些中文字段莫名丢失。工具链层：这才是最致命的一环。ARM Compiler 5（AC5）默认以系统代码页读源码，对 GBK 天然友好；ARM Compiler 6（AC6）和 ARMCLANG 却彻底转向现代标准：不带
--utf-8参数？直接编译失败（Error C3095E）；带了但文件不是 UTF-8？给你一行醒目的#warning "source file is not UTF-8 encoded"——而这个 warning，很容易被淹没在上百条其他提示里。
更关键的是：调试信息（DWARF/STABS）里的函数名、变量名，直接拷贝源文件中的原始字节。编译器怎么读的，调试器就怎么存、怎么查。如果你用 GBK 写了int 温度值;，AC6 却按
