WPF 源码编译报 C4819、C4566：检查 MSVC 字符集

从 .NET VMR 编译 WPF，外层只显示 MSB3073 和退出码 1，往里看却是 DirectWriteForwarder 的 C4819、C2220。若 Windows ANSI 代码页是 936，先检查 MSVC 是否把没有 BOM 的 UTF-8 源文件按 GBK 读取。

具体故障出现在 WPF 的 TtfDelta 原生文件：注释里的长破折号触发编码警告，而构建把警告当成错误。这里讨论的是编译 WPF 源码的贡献者构建，不是已有 WPF 桌面应用在运行时发生了回归。

顺着首个原生编译错误检查

保留 binlog 和最早出现的编译诊断，定位实际调用的 cl.exe、输入文件、编译选项与 Windows 代码页。外层 MSBuild 退出码只是结果，不能据此认定缺少 SDK 或 NuGet 依赖。

已确认的组合是 WPF revision e89a851c5792c8777a7115cc7a797fd0c045fdd4、MSVC 14.51.36231、Windows x64 和代码页 936。首个受影响版本尚未确定，不能把所有 WPF 源码构建失败都归到这项字符集差异。

源字符集和执行字符集一起核对

MSVC 的 /source-charset:utf-8 指定如何读取源字节，/execution-charset:utf-8 决定窄字符与字符串常量的目标编码。只设置前者后，生成的 C++ 版权属性还可能因 © 等字符出现 C4566。

对于已经确认为 UTF-8 的这些原生编译单元，可在对应项目或构建生成入口中增加：

/utf-8

这相当于同时指定上述两个字符集。若使用 Visual Studio 项目属性，在对应配置的 C/C++ 命令行附加选项中设置；构建由 VMR 或生成器驱动时，应修改它真正读取的项目配置入口，并在 binlog 中确认选项进入实际 cl.exe 命令。仅在外层 MSBuild 随意添加一个同名属性，未必会传到编译器。

这会改变相关窄字符串常量的字节表示，应把范围限定到需要 UTF-8 的项目，检查使用这些字节的接口。不要直接把整个源码树转成 GBK、删掉所有非 ASCII 字符，或改系统全局区域设置来迁就一次构建。

确保复查真的重新编译了目标

VMR 可能复用仓库完成标记或既有产物。再次执行构建时，确认日志包含原失败文件的实际编译，而不是仅看到外层流程快速成功。按项目既有方式使受影响目标重新构建，不需要删除所有共享缓存。

对照代码页 936 和常规 UTF-8 环境，检查 C4819、C4566 与 C2220 均消失，同时核对生成的版权文本、原生产物和项目测试。保留原始日志与局部配置差异；若后续源码已经加入等效设置，再验证后撤回重复参数。这一处理依据明确的源文件编码，不适用于尚未确认编码的任意 C++ 输入。