数组在 Visual C 中奇怪地存储从 GetVolumeInformation 检索到的名称？
我想使用 GetVolumeInformation 调用来检索可移动设备的名称。我可以很好地检索名称并将其存储到 TCHAR 数组变量 szVolNameBuff 中。这是我的代码：
// Get Volume Information to check for NTFS or FAT
TCHAR szFileSys[256];
TCHAR szVolNameBuff[256];
DWORD dwSerial = 0;
DWORD dwMFL = 0;
DWORD dwSysFlags = 0;
bool bSuccess;
char fileType[255];
int bSuccessdebug = 0;
//LPCTSTR temp = _T("E:\\"); For debugging only
bSuccess = GetVolumeInformation(drivePath,
szVolNameBuff,
sizeof(szVolNameBuff),
&dwSerial,
&dwMFL,
&dwSysFlags,
szFileSys,
sizeof(szFileSys));
当我尝试使用以下行打印变量的内容时：
printf("szVolNameBuff holds: %s \n", &szVolNameBuff);
我得到的输出是“T”，而不是名称“Transcend”（驱动器的名称）。我用 Visual Studio 2008 调试它，发现 TCHAR 数组将名称存储为： [0] 'T' [1] 0 [2] 'R' [3] 0 [4] 'A' [5] 0 [6] 'N' [7] 0
等等。这是为什么？我希望数组将单词存储为：
[0] 'T' [1] 'R' [2] 'A' [3] 'N' [4] 'S'
稍后将其用于字符串连接。有办法解决这个问题吗？
I would like to use the GetVolumeInformation call to retrieve the name of a removable device. I can retrieve the name just fine and store into a TCHAR array variable szVolNameBuff. Here is my code for that:
// Get Volume Information to check for NTFS or FAT
TCHAR szFileSys[256];
TCHAR szVolNameBuff[256];
DWORD dwSerial = 0;
DWORD dwMFL = 0;
DWORD dwSysFlags = 0;
bool bSuccess;
char fileType[255];
int bSuccessdebug = 0;
//LPCTSTR temp = _T("E:\\"); For debugging only
bSuccess = GetVolumeInformation(drivePath,
szVolNameBuff,
sizeof(szVolNameBuff),
&dwSerial,
&dwMFL,
&dwSysFlags,
szFileSys,
sizeof(szFileSys));
When i try to print the contents of the variable with the line:
printf("szVolNameBuff holds: %s \n", &szVolNameBuff);
I get an output of "T" instead of the name "Transcend" which is the name of the drive. I debugged it with Visual Studio 2008 and found out that the TCHAR array stores the name as:
[0] 'T'
[1] 0
[2] 'R'
[3] 0
[4] 'A'
[5] 0
[6] 'N'
[7] 0
and so on and so forth. Why is that? I want the array to store the word as just:
[0] 'T'
[1] 'R'
[2] 'A'
[3] 'N'
[4] 'S'
to later use it for string concatenation. Is there a way to fix this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看来您正在使用 unicode Win32 API。您应该使用 _tprintf，以便根据字符类型使用适当的函数（printf 或 wprintf）。
如果您不了解 unicode - 这里有一个快速概述。发生这种情况的原因是常规 ascii 字符的 unicode 是一个空字节，后跟 ascii 字符。这就是为什么您看到字符串用空值填充的原因。
请注意，使用 TCHAR 时，还应该将所有字符串包装在 _T() 宏中，以便它们也被声明为正确的类型。如果您始终遵循这一点，从 unicode 转换为 ansi 只需更改预处理器指令即可。
It looks like you are using the unicode Win32 APIs. You should use _tprintf so that the appropriate function (printf or wprintf) is used according to the character type.
If you don't know unicode - here's a quick overview. The reason this is happening is that the unicode for the regular ascii characters is a null byte followed by the ascii character. That's why you are seeing the string padded with nulls.
Note that when using TCHAR, you should also wrap all strings in the _T() macro, so that they are also declared of the correct type. If you follow this consistently, converting from unicode to ansi is just a matter of changing a preprocessor directive.
原因是您使用的是 Win32 API 的 Unicode 版本。
还有 2 个修复。第一种是使用 API 的标准版本，如果您使用的是 Visual Studio，可以通过在“项目”->“项目”中将项目的字符集更改为“未设置”来完成。属性->配置属性->一般->字符集，或者如果您不使用 VS，则在包含 windows.h 之前确保 UNICODE 不是 #define。
第二个修复，正如 mdma 所说，是使用 Unicode 文本操作函数 wprintf 或使用标准库中的 %S。这是首选的修复方法，因为您的程序将变得国际化友好，并且可以使用文件名使用的任何字符集。然而，这意味着所有下游函数也需要使用 Unicode，这可能意味着大量工作，具体取决于项目的大小。
The why is that you're using the Unicode versions of the Win32 APIs.
And there are 2 fixes. The first is to use the standard versions of the API which if you are using Visual Studio can be done by changing your project's Character Set to 'Not set' in Projects-> Properties-> Configuration Properties-> General-> Character Set, or by making sure UNICODE is not #defined before including windows.h if you aren't using VS.
The second fix, as mdma said, is to use the Unicode text manipulation function wprintf or use %S in the standard library. This is the preferred fix as your program would then become internationalisation friendly and work whatever character set the file names were using. However it would mean that all down stream functions would need to use Unicode too, which might mean a lot of work, depending on the size of the project.