Question

我正在使用VS2010项目Unicode，一切正常。当我删除本地文件并从源代码控制（Perforce）下载它的新副本时，resource.h文件读错（中文）。

// {{NO_DEPENDENCIES}}਍⼀⼀䴀碗挀爀漀猀漀昀琀嘀碗猀甀愀氀䌀⬀⬀最攀渀攀爀愀琀攀搀碗渀挀氀甀搀攀昀碗氀攀⸀ഀഀ//由MyDemo.rc使用਍⼀define define ID＃ID ID ID ID ID 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x

为什么VS2010会这样做？我该如何解决？它本质上是一个相同的文件，但在一次实例中它打开，一个新的实例无法找出文件编码。

虽然这是MFC项目，但看起来与此问题无关。

Answer 1

这似乎是Perforce line ending conversion的一个问题，而且无法正确推断出resource.h的UTF16格式。

如果您将来遇到问题，请按照here步骤解决问题：

问题

在Windows上，同步“text”（Perforce文件类型）文件后包含   utf16编码，我工作区中的文件似乎已损坏。

解决方案

由于utf16字符编码是双字节字符编码   和Perforce将“text”文件视为单字节，您可能会遇到   Windows环境中的呈现或损坏问题。 Windows系列   在UTF16字符集中未正确转换结尾   “文本”文件。这会破坏utf16文件内容。

使用utf16内容的文件修订应始终使用   “utf16”文件类型（添加时，Perforce将自动检测utf16   文件，除非用户或类型映射规则覆盖此行为。）

要解决您的问题，请按以下步骤操作：


编辑工作区规范并将LineEnding字段的值更改为“unix”

强制同步文件（不会进行行结束转换）

检查工作区文件现在是否正确呈现

签出文件，将文件类型更改为utf16（从“text”更改为“utf16”）

编辑工作区规范并将LineEnding字段的值更改回“local”

提交文件的新修订


示例：
p4 client bruno_ws
  LineEnd: unix
p4 sync -f myfile.txt
p4 edit -t utf16 myfile.txt
p4 client bruno_ws
  LineEnd: local
p4 submit -d "Fixing unicode file"

Answer 2

我想我之前已经看过这个问题所以我现在要解决这个问题，因为我弄明白了。不知怎的，resource.h编码或格式搞砸了，我不知道为什么。我没有对它进行任何手动更改。相比之下，Perforce无法检测到更改并正确显示它们。但是，如果文件相同，它通常不会提示“文件是相同的”消息。但是，如果我执行“还原未更改的文件”，则会将其回滚而不检测更改。

我使用了十六进制比较工具，两个文件的内部结构不同。我只是选了一个有效的。由于某种原因，文件大小也不同。

正确的文件显示如下

//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by MyDemo.rc
//
#define IDD_ABOUTBOX                    100
....

Answer 3

Resource.h需要采用ANSI格式。有时Visual Studio会将其转换为Unicode并在开头放置一个2字节的BOM。但是，当它在IDE编辑器中加载时，它无法识别它并将其显示为中文。如果您使用十六进制编辑器查看，您将能够阅读文件内容。

解决方案是使用独立的文本编辑器（我使用Notepad ++或Notepad2）并确保文件以ANSI格式编码而不使用BOM。然后检查文件，不再使用Visual Studio打开它。如果您需要进行更改，请始终通过外部编辑器并确保在保存编码后仍然是ANSI。

我不知道为什么会这样。我的假设是OS默认语言环境与VS Project Resource语言环境不同。然后IDE会感到困惑并可能尝试将资源文件转换为Unicode以避免转换问题，但Resource.h不是普通的文本文件。编译器似乎不了解具有BOM的Unicode源。

VS2010并不了解自己文件的字符串编码

3 个答案: