如果在不同的机器上构建，STRINGTABLE中的特殊字符是否无法正确显示？

Question

我必须在我的部门中维护一个小的C++ / VS2015项目，它只检查机器上已安装的.NET框架，如果未安装当前版本，则会提示用户。这个小应用程序由一个名为Language.rc的文件进行本地化，该文件包含一些带有相应文本的STRINGTABLES。如果程序是在我的机器上编译的，那么所有这些都可以很好地工作，但是如果在我们的构建机器上编译相同的代码，那么像德语这样的特殊字符就会丢失。不幸的是，我不是c++用户，我不知道出了什么问题。我已经在网上搜索过了，但找不到可能是什么问题的线索。

有没有人知道，与我的机器相比，在构建机器上有什么不同，导致了不同的字符？

更新：

因此，在我的TFS专家分析了构建机器上的问题后，我们能够找到罪魁祸首：

正如我之前所说的，导致问题的应用程序只是一个小工具。我们的自动构建包含更多的解决方案和项目。自动构建的一个部分是一个脚本，它将所有类型文件的版本号设置为相同的值。这显然也适用于所谓的RC文件。据我所知，在C++ (以及Delpi)中有不同类型的RC文件，它们实际上包含版本号。在我的例子中，RC文件只有文本和翻译，但即使它没有版本号，它也是打开并保存的。不幸的是，该操作还显式地将文件的编码设置为一些旧的IBMxyz编码(可能用于Delphi文件？)。这是特殊字符丢失的实际操作...因此，我的问题的解决方案不是在文件的原始编码中，而是在构建过程中的某个地方。作为临时修复，我们将.rc文件更改为.rc2文件-这样项目仍然可以编译，但构建不再修改它。

我今天玩得够开心了.

Answer 1

Windows有两种处理文本的方法。它们被称为"Unicode“(实际上是UTF-16)和" ANSI”(与ANSI标准组织无关，描述的是ASCII码的任何8位超集)。

你的问题显然是一种"ANSI“病。ASCII不包含“all”，ASCII的一些超集包含，但不是所有的超集都包含。不同的机器使用不同的超集会导致不同的结果。

“简单”的解决方法是在.rc文件中的字符串前面加上一个L前缀：L"zum Beispiel"，然后将这个.rc文件保存为Unicode (UTF-16)。虽然较新版本的Windows包含更多UTF-16字符，但这不会影响现有字符，并且已成为每个Unicode版本的一部分。(即使是欧元也适用于所有地方--我想这是在Windows2000中添加的)