【＞D:\10\Debug\RCa00828(34): fatal error RC1022: expected ‘#endif‘】

1>D:\10\Debug\RCa00828(34): fatal error RC1022: expected ‘#endif’

The error message you’re seeing, fatal error RC1022: expected ‘#endif’, indicates that the resource compiler encountered an issue when processing a resource script file (typically with the .rc extension). This file is used to define various resources within a Windows application, such as icons, menus, dialog boxes, etc.

The specific problem is that the compiler was expecting to find a #endif directive to match an #if, #ifdef, or #ifndef directive earlier in the file, but it did not find one. This is likely due to a mismatch in the conditional compilation directives in the resource script.

Here’s how you might go about resolving this error:

Open the resource script file that’s causing the error. It should be located at the path D:\10\Debug\RCa00828.

Look for conditional compilation directives (#if, #ifdef, or #ifndef) and ensure that each one is properly paired with an #endif. It’s possible that you have a missing #endif, or there may be one too many.

Check for any nested conditional directives and make sure that they are also correctly paired and nested.

If your resource script includes other files, check those files as well for proper #endif directives.

Once you’ve found and corrected the mismatch, save the file and attempt to recompile.

If you’re still encountering issues, consider looking for more detailed error messages or warnings that might give further insight into where the issue lies.

If your resource script is very long or complex, you might benefit from using a text editor with syntax highlighting and matching for preprocessor directives to help visually identify where the issue might be.

Remember to always keep a backup of the file before making changes, so you can revert to the previous state if something goes wrong during your troubleshooting process.

解决方案

这个错误信息 fatal error RC1022: expected ‘#endif’ 表明资源编译器在处理一个资源脚本文件（通常拥有 .rc 扩展名）时遇到了问题。这种文件用于定义Windows应用程序中的各种资源，如图标、菜单、对话框等。

具体的问题是编译器期望找到一个与之前的 #if、#ifdef 或 #ifndef 指令相匹配的 #endif 指令，但是它没有找到。这通常是因为资源脚本中的条件编译指令不匹配。

下面是解决这个错误的步骤：

打开引起错误的资源脚本文件，它应该位于 D:\10\Debug\RCa00828 路径。

查找条件编译指令（#if、#ifdef 或 #ifndef），确保每个指令都正确地与一个 #endif 配对。可能是你缺少了一个 #endif，或者有一个多余的。

检查任何嵌套的条件指令，确保它们也正确地配对和嵌套。

如果你的资源脚本包含了其他文件，请同时检查这些文件中 #endif 指令是否正确。

找到并更正不匹配之后，保存文件并尝试重新编译。

如果你仍然遇到问题，考虑寻找更详细的错误信息或警告，这些可能会提供进一步洞悉问题所在。

如果你的资源脚本非常长或复杂，使用具有语法高亮和预处理器指令匹配功能的文本编辑器可能会帮助你直观地识别问题所在。

在开始排错过程前，请记得备份文件，以便在操作出错时能够恢复到之前的状态。

“D:\10\multiVersionArxDbg.vcxproj”(rebuild 目标) (1) ->
(Link 目标) ->
LINK : fatal error LNK1123: 转换到 COFF 期间失败: 文件无效或损坏 [D:\10\multiVersionArxDbg.vcxproj]

错误信息 LINK : fatal error LNK1123: 转换到 COFF 期间失败: 文件无效或损坏 通常表示在从.obj文件转换到 COFF(Common Object File Format)格式文件时出现了问题。这个问题可能是由于多种原因导致的，以下是一些解决方案：

升级Visual Studio或.NET Framework：这个问题在某些版本的Visual Studio中更为常见，特别是在使用Visual Studio 2010时。如果可能，尝试更新到最新的Visual Studio或.NET Framework版本。

安装Visual C++更新：如果你正在使用较旧的Visual Studio版本，确保你已安装了最新的Visual C++服务包和更新。

禁用增量链接：增量链接有时会导致这个问题。你可以尝试禁用它：

打开项目属性。
导航到链接器设置。
在链接器的常规设置中，找到“启用增量链接”并将其设置为“否”。
清理并重建项目：

清理项目（在Visual Studio中通常可以在“构建”菜单中找到“清理解决方案”）。
重新构建项目。
检查损坏的文件：错误提示中提到的“文件无效或损坏”，检查你的.obj文件或者其他编译产生的中间文件是否完好。删除这些文件后重新编译可能有助于解决问题。

检查磁盘空间：确保你的磁盘空间足够。在磁盘空间不足的情况下，文件可能会被错误地写入，导致损坏。

以管理员权限运行Visual Studio：有时候，权限问题可能会导致文件写入失败。确保你以管理员权限运行Visual Studio。

关闭杀毒软件：某些情况下，杀毒软件可能会干扰文件的生成。尝试临时禁用杀毒软件，然后重新构建项目。

如果上述方法都不能解决问题，你可能需要详细检查项目设置，或者在Visual Studio的输出窗口中查找更多错误信息，以获得进一步的线索。同时，确保你的所有项目文件和工具链都是最新的，这有助于防止兼容性问题。

(ResourceCompile 目标) ->
D:\10\Release\RCa03940(34): fatal error RC1022: expected ‘#endif’
在win10系统没有问题，在win’7出问题

错误信息 fatal error RC1022: expected ‘#endif’ 指示资源编译器在处理资源文件时预期要找到一个 #endif 预处理器指令，但没有找到。这通常是代码中预处理器指令使用不当的问题。

如果这个问题在 Windows 10 系统上没有出现，但在 Windows 7 上出现，可能有几个原因：

不同的资源编译器版本：Windows 10 和 Windows 7 可能使用的资源编译器版本不同。Windows 10 上可能有较新的编译器，它可能更宽松地处理文件中的预处理器错误，或者具有不同的预处理器行为。

环境差异：可能两个系统中的编译环境有所差异，包括预处理器定义、包含的头文件路径等。

文件编码问题：有时候，不同操作系统间文本文件的编码方式或换行符（LF vs CRLF）可能会不一样，这可能会影响资源编译器的行为。

条件编译指令差异：代码中可能有特定条件编译指令，它们依赖于特定于操作系统版本的宏，导致在不同的操作系统上行为不一致。

为了解决这个问题，你可以尝试以下步骤：

查看预处理器差异：检查两个系统上是否有不同的预处理器定义，这可能会导致代码在预处理时表现不同。
检查编译器版本和设置：确保两个系统上使用的编译器版本相同，以及所有相关的设置都是一致的。
核对代码的条件编译指令：检查代码中是否有依赖于操作系统版本的条件编译指令，并确保它们正确地用于不同的平台。
文件编码：确保资源文件在两个操作系统上使用相同的文本编码和换行符风格。
完整清理和重建：在 Windows 7 系统上完全清理项目（删除所有生成的中间文件和输出），然后尝试重新编译。
如果以上方法仍然不能解决问题，考虑创建一个最小可重现问题的示例，并在两个系统上进行测试，以确定是环境差异还是代码问题。此外，也可以在网络上搜索是否有其他开发者遇到类似的跨操作系统编译问题，并查看他们是如何解决的。

如果你在两个不同的操作系统上使用相同版本的Visual Studio（VS2005）遇到了这个问题，可以尝试以下步骤来定位问题：

完整清理项目：

使用Visual Studio的清理功能或手动删除所有生成的临时文件（如.obj、.pch、.res等）。
确保删除了所有的输出文件（如.exe、.dll、.lib等）。
检查预处理器的一致性：

仔细检查项目设置，确保预处理器定义在两个系统上是一致的。
注意是否有基于操作系统版本的条件编译指令。
检查包含的路径和依赖项：

确认所有的包含路径在两个系统上都是正确的。
确保所有的依赖项都存在且版本一致。
重新编译资源文件：

单独编译资源文件，看是否可以复现问题。
检查系统区域设置：

不同的系统区域设置可能会导致资源编译器的行为不同。例如，字符编码问题可能会在一个系统上导致编译错误而在另一个系统上不会。
手动检查资源文件：

打开有问题的资源文件，检查#if、#ifdef、#ifndef和#endif是否匹配正确。
检查是否有隐藏的字符或者在文件中插入了某些不可见的特殊字符。
更新VS2005：

即使两个系统上都安装了VS2005，也可能存在更新的差异。确保两个系统上的VS2005都安装了相同的更新和修补程序。
比较编译器详细日志：

在两个系统上使用相同的详细级别编译项目，并比较生成的日志文件，看看是否有任何线索。
系统差异：

虽然都是VS2005，但Windows 7和Windows 10的底层系统可能有所不同，这可能会影响工具链的运行。例如，VS2005可能不完全兼容Windows 7的某些特性。
管理员权限：

尝试以管理员权限运行Visual Studio，以避免权限问题导致的文件写入错误。
如果所有这些步骤都不能解决问题，你可能需要在遇到问题的系统上进行更深入的调试，或者考虑在虚拟机上重新设置一个干净的开发环境，以排除系统差异的干扰。

根本没有RCa03940

如果资源编译器报告了一个不存在的文件 RCa03940，这可能是一个编译器的bug或者是项目配置上的问题导致的。以下是一些可能的解决方案：

检查项目文件：打开你的 .vcproj 文件，这是VS2005的项目文件，查找任何提及 RCa03940 的地方。如果这个文件被误引用了，从项目中移除或更正文件名。

检查资源文件列表：在Visual Studio资源视图中检查是否所有列出的资源文件都是存在的，有时候即使文件在资源视图中不存在，它仍然可能被引用在项目文件中。

检查自定义构建步骤：如果你有任何自定义构建步骤或预构建/后构建事件，检查它们是否可能在引用不存在的文件。

全局搜索：在整个解决方案中进行全局搜索RCa03940，以检查是否在代码、注释或配置文件中不正确地引用了这个文件。

清理解决方案：尝试清理解决方案并重新构建，以确保不是由于旧的编译状态导致的问题。

手动清理：关闭Visual Studio，然后手动删除所有的生成目录（例如 Debug/ 和 Release/），以及所有 .suo 和 .ncb 文件，然后重新打开解决方案并尝试再次编译。

检查系统文件和路径：确认你的文件系统和路径名没有超过Windows的限制，例如全路径名通常不应超过260个字符。

VS2005与Windows 7的兼容性问题：虽然VS2005在Windows 7上可能可以运行，但它在发布时并不是为Windows 7设计的，可能存在一些兼容性问题。尝试以兼容模式运行VS2005，如以Windows XP兼容模式运行。

查看详细构建输出：在Visual Studio中，你可以调整构建输出的详细程度。增加详细程度可能会揭示更多关于问题的线索。

考虑环境问题：如果这个问题只在一个特定的机器或系统上发生，考虑是否可能是系统环境或安装的其他软件干扰了VS2005。

如果以上步骤都不能解决问题，你可能需要更详细地分析构建过程，或者考虑升级到一个新版本的Visual Studio，新版的Visual Studio提供了更好的诊断工具和更强大的兼容性。

正在编译...
         ArxDbgXdata.cpp
         EntMakeTest.cpp
         MapTest.cpp
         SdStrList.cpp
         SdStrObjId.cpp
         SdSysVar.cpp
         TblMakeTest.cpp
         UiUtils.cpp
         XformTest.cpp
         Registry.cpp
         KeyHelper.cpp
         MenuBarXP.cpp
         MenuXP.cpp
     1>Controls\MenuXP.cpp(93): warning C4018: “>”: 有符号/无符号不匹配 [D:\10\multiVersionArxDbg.vcxproj]
     1>Controls\MenuXP.cpp(639): warning C4018: “<”: 有符号/无符号不匹配 [D:\10\multiVersionArxDbg.vcxproj]
         ToolBarEx.cpp
         ToolBarXP.cpp
       ResourceCompile:
         E:\vs\VCPLAT~1\VC8\bin\rc.exe /l"0x0409" /fo"Release\ArxDbg.res" ArxDbg.rc 
     1>D:\10\Release\RCa03940(34): fatal error RC1022: expected '#endif' [D:\10\multiVersionArxDbg.vcxproj]
         
     1>已完成生成项目“D:\10\multiVersionArxDbg.vcxproj”(rebuild 个目标)的操作 - 失败。

根据您提供的编译输出，问题似乎在于资源编译器在处理资源文件 ArxDbg.rc 时出现了预处理器指令错误。具体来说，资源编译器期待在某个位置有一个 #endif 来结束一个条件编译块，但却没有找到。这个问题出现在 D:\10\Release\RCa03940(34)，这里的 (34) 指的是文件中的第34行。

因为这个错误在Windows 10系统上没有出现而在Windows 7上出现，可能的原因和解决方法如下：

资源文件中的预处理器指令：打开 ArxDbg.rc 文件，跳转到第34行，检查所有的条件编译指令（#if、#ifdef、#ifndef），确保每个都有一个相应的 #endif。如果有嵌套的条件编译指令，请特别注意内层和外层是否都正确闭合。

编译器差异：虽然您使用的是VS2005，但不同的Windows版本可能附带的编译器版本有微小差异，或者更新和修补程序不同，这可能会影响编译器的行为。尝试在Windows 7机器上更新VS2005到最新的服务包和补丁。

编码或换行符：检查 ArxDbg.rc 文件的编码是否为ASCII或UTF-8无BOM，以确保Windows 7上的资源编译器能正确解析文件。另外，确保文件使用的换行符是Windows风格的CRLF。

清理构建环境：在Windows 7上彻底清理解决方案，并重新构建。这可以通过Visual Studio的“清理解决方案”选项来完成，或者手动删除所有生成的中间文件和输出文件。

检查VS2005设置：确保Windows 7上的VS2005设置与Windows 10上的相同，特别是关于编译和资源编译的设置。

管理员权限：以管理员权限运行Visual Studio，这有时候可以解决权限问题导致的编译错误。

如果上述步骤都未能解决问题，可以尝试以下高级步骤：

生成详细日志：增加Visual Studio的输出详细程度，以便能够获得更多关于错误的信息。
手动编译资源文件：在命令行中手动运行 rc.exe 来编译资源文件，这样可能会得到更多的诊断信息。
创建一个新的资源文件：如果 ArxDbg.rc 文件非常复杂，可以尝试创建一个新的、简化的资源文件，并逐步迁移资源，以确定问题所在。
最后，如果问题持续存在，可以考虑在社区论坛寻求帮助，或者作为最后手段，升级到一个新版本的Visual Studio，因为VS2005可能在现代操作系统上遇到兼容性问题。

这是之前34行的代码/
// English (U.S.) resources

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif //_WIN32

根据您提供的信息，您的资源文件中的预处理器指令看起来是匹配的。但是，编译器错误 fatal error RC1022: expected ‘#endif’ 表明编译器在处理时预期遇到一个 #endif 但没有找到。

这里有一些您可以按照的步骤来诊断和解决问题：

检查未匹配的指令：确保每个 #if、#ifdef 或 #ifndef 都有对应的 #endif。您可能在资源文件的其他地方有未匹配的对。

核实行号：有时错误消息中的行号可能会误导人，特别是如果涉及到多个包含文件或其他预处理指令。检查指定行号前后的代码，看是否有遗漏的 #endif。

预处理器输出：为了诊断与预处理器相关的问题，您可以生成资源文件的预处理输出。这可以通过使用资源编译器 (rc.exe) 的 /P 选项来完成。这将准确显示预处理器如何解释您的指令。

简化文件：暂时注释掉资源文件中的部分内容以缩小问题可能所在的范围。逐步重新引入各部分内容直到错误再次出现。

检查隐藏字符：使用能够显示所有字符（包括空白字符）的文本编辑器检查是否有任何隐藏字符可能导致问题。

重新创建该段：如果上述方法都不奏效，您可以尝试从头开始重写有问题的部分，确保所有指令清晰匹配。

在不同机器上编译：有时候，问题可能特定于某个特定的设置。如果可能的话，尝试在另一台Windows 7机器上编译项目，看问题是否依旧存在。

如果经过这些步骤问题仍未解决，可能存在更隐蔽的问题，这些问题可能在提供的代码片段中不立即可见。您可能需要更仔细地检查整个资源文件，或者寻求他人的帮助，让他们能够在其上下文中审查整个文件。

#pragma code_page(65001)这个代码在vs2005的32位当中，如果是#pragma code_page(1252)可以通过，但是65001不行

#pragma code_page(65001) 指定资源编译器使用 UTF-8 代码页来读取资源文件。在 Visual Studio 2005 中，可能会遇到一些与此指令相关的问题，尤其是在早期的 Service Packs 或者没有安装更新的情况下。相比之下，#pragma code_page(1252) 是指定使用西欧语言代码页，这通常会有更好的兼容性。

如果在 VS2005 的 32 位版本中使用 #pragma code_page(65001) 出现问题，这可能是由于以下原因：

编译器的 BUG 或限制：早期的 Visual Studio 版本可能并不完全支持 UTF-8 编码的资源文件。VS2005 可能有这个限制。

系统的代码页设置：Windows 系统可能没有正确配置为支持 UTF-8 代码页。

缺少支持：某些系统或工具链可能没有必要的更新来支持 UTF-8 编码。

为了解决这个问题，您可以采取以下措施：

更新 Visual Studio：安装所有可用的服务包和更新，确保您的 VS2005 环境是最新的。

改变代码页：如果不是必须使用 UTF-8 编码，您可以将 #pragma code_page(65001) 更改为 #pragma code_page(1252) 或其他兼容的代码页。

手动转换资源文件：将资源文件手动转换为 ANSI 或其他 Visual Studio 2005 支持的代码页，而不依赖于 #pragma code_page 指令。

更换开发环境：如果可行，您可以考虑升级到更高版本的 Visual Studio，因为新版本提供了更好的 Unicode 支持。

保存资源文件的格式：确保资源文件保存为没有字节顺序标记（BOM）的 UTF-8 格式，因为某些版本的资源编译器在处理带有 BOM 的 UTF-8 文件时可能会出现问题。

最后，如果这些解决方案都不适用，您可能需要调整项目设置，以避免使用不被支持的功能，或者在资源文件中使用更通用的字符编码。

遗憾的是，在 Visual Studio 2005 中，您可能会遇到无法使用 #pragma code_page(65001) 指令的问题。Visual Studio 2005 的资源编译器可能不支持或不完全支持 UTF-8 代码页（65001）。如果您尝试在资源文件中使用这个指令，可能会导致编译错误。

以下是您可以尝试的一些解决方法：

不使用 #pragma code_page(65001):
直接移除这行指令。如果您的资源文件不包含需要 UTF-8 来编码的文本（例如，所有文本都是 ASCII），这可能是一个可行的解决方案。

改用 ANSI 代码页:
如果您的资源文件包含本地化文本，您可能需要将其保存在一个与目标语言相对应的 ANSI 代码页中。例如，许多西欧语言可以使用代码页 1252。

手动转换文本:
如果资源文件中有少量的 Unicode 文本，您可以尝试将其转换为 \uXXXX 形式的转义序列，这种格式不依赖于文件的编码。

升级 Visual Studio:
考虑升级到更高版本的 Visual Studio，因为后续版本对 UTF-8 的支持要好得多。

使用外部资源编译器:
如果您有访问到更新版本的 Visual Studio，您可以尝试使用那里的资源编译器来编译资源文件。

编写自定义构建步骤:
如果您仍希望在资源文件中使用 UTF-8 编码，可以编写一个自定义构建步骤，该步骤在调用 Visual Studio 2005 的资源编译器之前，使用外部工具（例如 iconv）将 UTF-8 编码的文本转换为支持的编码。

寻求社区支持:
有时候，社区中可能有人遇到并解决了类似的问题。尝试在相关论坛、Stack Overflow 或者 MSDN 社区寻找解决方案。

在尝试上述解决方案时，请记住，资源文件编码和代码页设置是为了确保程序在运行时能正确显示文本。如果您选择不使用 UTF-8，必须确保在所有用户界面元素中使用的字符串能够在所选择的代码页中正确表示。

要将包含 Unicode 字符的文本手动转换为 \uXXXX 形式的转义序列，您需要将每个 Unicode 字符替换为它的对应 \uXXXX 表示，其中 XXXX 是该字符的 Unicode 码点的十六进制表示。

例如，如果您有一个中文字符 “道”，其 Unicode 码点是 9053（在十六进制中是 0x9053），那么您可以在资源文件中将其表示为 \u9053。

在您提供的资源文件片段中，如果 “ 公众号” 和 “微信小程序” 等文本中包含非 ASCII 字符，你需要替换这些字符。对于 ASCII 字符（即码点在 0 - 127 之间的字符），可以保持原样。

以下是一个将包含中文字符的字符串转换为 \uXXXX 格式的例子：

原始字符串：

复制
“浙江省杭州市”
转换后的字符串（举例，您需要用实际的 Unicode 码点替换 XXXX）：

复制
“\u6d59”
对于您提供的资源定义，如果要替换里面的字符串，您需要找到每个非 ASCII 字符的 Unicode 码点，并替换为 \uXXXX 格式。使用文本编辑器或某种编程语言可以帮助您完成这一转换。

例如，下面的资源定义：

rc
复制
CONTROL “▲ 公众号”, -1, STATIC, SS_CENTER | WS_CHILD | WS_VISIBLE | WS_GROUP, 17, 123, 57, 8
如果 “▲” 字符的 Unicode 码点是 9650（十六进制 25B2），则替换后应该是：

rc
复制
CONTROL “\u25B2 ssL\u516c\u4f17\u53f7”, -1, STATIC, SS_CENTER | WS_CHILD | WS_VISIBLE | WS_GROUP, 17, 123, 57, 8
请注意，手动替换文本可能会很繁琐，尤其是当涉及到许多非 ASCII 字符时。在某些情况下，可能更方便使用脚本或程序来自动执行此转换。此外，对于 Visual Studio 2005，确保在资源编辑器中查看转换后的文本，以确保它正确显示并符合预期。

非 ASCII 字符Unicode 码点转换

非 ASCII 字符转换为 Unicode 码点的 \uXXXX 格式涉及将每个字符的 Unicode 码点以十六进制的形式表示出来。您可以手动完成这个转换，或者使用编程语言或工具来帮助您。下面是几种不同方法的例子：

手动转换
查找每个非 ASCII 字符的 Unicode 码点。可以在 Unicode 字符表中查找，或者使用在线工具。
将码点转换为十六进制数值（如果您使用的是在线工具，它通常会为您做这个转换）。
把十六进制数值放到 \u 后面形成 \uXXXX 的格式。
使用 Python 脚本自动转换
以下是一个简单的 Python 脚本，可以用来将字符串转换为 \uXXXX 格式：

python
复制
def to_unicode_escape(s):
return ‘’.join(‘\u{:04x}’.format(ord©) for c in s)

示例字符串

text = “浙江省杭州市”

转换并打印结果

escaped_text = to_unicode_escape(text)
print(escaped_text)
运行这个脚本会输出转换后的字符串，您可以将其复制并粘贴到您的资源文件中。

使用在线工具
您还可以找到许多在线工具来帮助您完成这个转换，例如 “Unicode 字符转义” 工具。您只需将字符串粘贴到工具中，它就会生成对应的 \uXXXX 格式字符串。

注意事项
在 Visual Studio 2005 的资源文件中使用 \uXXXX 格式可能仍然需要您的项目设置为正确的字符编码，以便资源编译器理解 Unicode 转义序列。
由于 \uXXXX 仅适用于 BMP (Basic Multilingual Plane) 范围内的字符（即 Unicode 码点 U+0000 至 U+FFFF），对于超出这个范围的字符，需要使用 \UXXXXXXXX 格式（注意是大写的 ‘U’ 和八个十六进制数字）。
请确保在替换字符之后测试您的程序，以验证显示和功能是否符合预期。

▲ ddfg公众号

▲ 微信小程序

浙江省杭州市

PT  Ver 由20231221betaA

\u25b2 ddfg\u516c\u4f17\u53f7%0a%0a
\u25b2 \u5fae\u4fe1\u5c0f\u7a0b\u5e8f%0a%0a
\u6d59\u6c5f\u7701\u676d\u5dde\u5e02%0a%0a
pt  ver \u753120231221betaa

VS 与 UTF-8 编码
与编码有关的几个地方#
源文件编码。
工程设置中的字符集选项。
编译选项/source-charset和/execution-charset。
编译指令#pragma execution_character_set(“utf-8”)，已过时。
实际上字符集设置只是决定双引号字符要不要加上L前缀，比如指定为Unicode字符集时，“Hello"将变为L"Hello”。

结论#
经过一番试验后得出：

源文件编码不影响可执行文件编码，编译器默认使用本机编码识别源文件，或者UTF-8 BOM也可以。其他编码则需要通过编译选项/source-charset告知编译器，比如UTF-8则需要添加选项/source-charset:utf-8。
宽字符总是UTF-16编码，不受任何选项影响。
窄字符采用/execution-charset选项指定的编码，未指定时则采用本机编码。
/utf-8选项等于同时设置/source-charset:utf-8和/execution-charset:utf-8。
在Visual Studio 2013及以下版本中，使用#pragma execution_character_set(“utf-8”)指令设置窄字符的编码方式，仅支持UTF-8。
使用 UTF-8 版 Win32 API#
当可执行文件字符编码为UTF-8时，与 Win32 API 交互就会出现乱码

::MessageBoxA(m_hWnd, “123456你好”, “”, 64);

因为历史原因，Windows 不支持UTF-8字符集，不过在较新的Windows 10 1903上已经开始支持了，但需要程序显示指明编码方式。
为程序添加一个特别的清单文件，这会告知 Windows 系统，程序使用了UTF-8字符集。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity type="win32" name="..." version="6.0.0.0"/>
  <application>
    <windowsSettings>
      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
    </windowsSettings>
  </application>
</assembly>

注意，它仅在Windows 10 1903以上的系统上有效。

建议#
不需要跨平台时，将源文件保存为UTF-8 BOM编码。
不需要跨平台时，尽量使用宽字符，因为有少数 Win32 API 仅有宽字符的版本，而且 COM 接口都是宽字符。在需要与UTF-8交互的地方用 WideCharToMultiByte 转换。
需要跨平台时，将源文件保存为UTF-8编码，并添加/utf-8选项，在与 Win32 API 交互的地方用 MultiByteToWideChar 转换。
在未来某年 Windows 7 彻底消失后，就可以为程序添加 UTF-8 清单文件，将程序全面转换到 UTF-8。

最终是不用win7，用win10或许可以解决问题