繁体   English   中英

Win32奇怪的Widechar行为

[英]Win32 strange widechar behavior

我以前没用过宽字符。 这是别人的代码:

char moduleFileName[512];
int size = ::GetModuleFileName(NULL,moduleFileName,sizeof(moduleFileName));
char c_drive[256];
char c_dir[256];
_splitpath_s(moduleFileName,c_drive,sizeof(c_drive),c_dir,sizeof(c_dir),NULL,0,NULL,0);
root = c_drive;
root.append(c_dir);

wchar_t moduleFileNameW[512];
int sizeW = ::GetModuleFileNameW(NULL,moduleFileNameW,sizeof(moduleFileNameW));
wchar_t w_drive[256];
wchar_t w_dir[256];
_wsplitpath_s(moduleFileNameW,w_drive,sizeof(w_drive),w_dir,sizeof(w_dir),NULL,0,NULL,0);
wroot = w_drive;
wroot.append(w_dir);

SEVEN_ZIP_EXE = wroot;
SEVEN_ZIP_EXE += L"\\7z.exe";

关键是将变量设置为7z.exe文件所在的位置。 当我在Windows 7 Prof. 64位系统上调试它时,我最终看到的像是wroot的无效字符,例如

﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾ ﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌 쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌 쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌 쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌块引用

将您的sizeof更改为_countof,这将解决您的奇怪数据问题。

您不需要这两组功能。 使用适合该应用程序的任何设置。 如果需要SEVEN_ZIP_EXE作为wstring,则可以消除char内容。

问题是sizeof,如果您真的要使用此sizeof(w_dir)/ sizeof(wchar_t)

我收集了您想要做的事情,就是获取包含可执行文件的目录。 我建议不要使用笨拙的splitpath:

TCHAR   szBuff[FILENAME_MAX];
TCHAR   *ShortName;
GetFullPathName(moduleFileName, FILENAME_MAX, szBuff, &ShortName);
*(ShortName-1) = '\0';  // remove exe from path

szBuff将包含目录,而ShortName指向名称。

上面的代码使用TCHAR和#define UNICODE,但是您可以将函数名称更改为wchar名称。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM