我必须在我的部门维护一个小型C ++ / VS2015项目，该项目仅检查已安装的机器的.NET Framework，并提示用户是否未安装当前版本。这个小应用程序由一个名为Language.rc的文件进行本地化，该文件包含一些带有相应文本的STRINGTABLES。 如果在我的机器上编译程序，所有这一切都可以正常工作，但是如果在我们的构建机器上编译相同的代码，那么特殊字符就像德国ÄÖÜ一样。 不幸的是，我不是一个c ++人，我不知道出了什么问题。我已经在网上搜索过但无法找到可能出现问题的提示。
有没有人知道构建机器与导致不同字符的机器有什么不同？
更新：
因此，在我的TFS专家分析了构建机器上的问题之后，我们能够识别出罪魁祸首：
正如我之前所说的导致问题的应用程序只是一个小工具。我们的自动构建包含更多解决方案和项目。自动构建的一部分是一个脚本，它将所有类型文件的版本号设置为相同的值。这显然也适用于所谓的RC文件。据我所知，C ++（以及Delpi）中存在不同种类的RC文件，它们实际上包含版本号。在我的情况下，RC文件只有文本和翻译，但即使它没有版本号，也会打开并保存。 不幸的是，这个操作还明确地将文件的编码设置为一些旧的IBMxyz编码（可能用于Delphi RC文件？）。这是特殊字符丢失的实际操作...所以我的问题的解决方案不在文件的原始编码范围内，而是在构建过程中的某个位置。 作为临时修复，我们将.rc文件更改为.rc2文件 - 这样项目仍然可以编译，但构建不再修改它。
今天我有足够的乐趣......
答案 0 :(得分：0)
Windows有两种处理文本的方法。这些被称为“Unicode”（真正的UTF-16）和“ANSI”（与ANSI标准组织无关，并描述任何 8位ASCII超集）。
您的问题显然是“ANSI”病例。 ASCII不包含“Ä”，一些ASCII的超集，但不是所有的超集。使用不同超集的不同机器会产生不同的结果。
“简单”修复是将L加到.rc文件中的字符串前缀：L"zum Beispiel"，然后将此.rc文件保存为Unicode（UTF-16）。虽然较新版本的Windows包含更多UTF-16字符，但这不会影响现有字符，并且Ä已成为每个Unicode版本的一部分。 （甚至每个地方都可以使用 - 我认为这是在Windows 2000中添加的）