为什么需要WCHAR相关代码处理

Question

我看到一个应用程序的代码，并看到对于 "Windows "特定的代码，他们已经转换了命令行参数来做一些额外的WCHAR相关处理（在#ifdef _WIN32之间）。

在下面的代码中，为什么要为Windows添加WCHAR处理相关代码？我试图理解调用WCHAR相关函数背后的原理。最后，代码编写者试图调用的是 myFunc 可以直接使用普通的argC和argV调用。为什么有人觉得需要增加额外的wchar处理？

int main(int argc, char* argv[])
{

#ifdef _WIN32

    int argc_w;
    LPWSTR* argv_w = CommandLineToArgvW(GetCommandLineW(), &argc_w);
    std::vector<char*> argv_vector;
    int result;
    if (ConvertToUtf8(argc_w, argv_w, argv_vector)) {
        result = myFunc(argc_w, argv_vector.data());
    } else {
        result = myFunc(argc, argv);
    }

    // code to free vector
    return result;
#else
    int (*ptrMyFunc)(int, char**, const char*);

    void *dllHandle = dlopen(myDLL.c_str(), RTLD_LAZY);
    *(void **) (&ptrMyFunc) = dlsym(dllHandle, "myFunc");
    return (*ptrMyFunc)(argc, argv);
#endif

}

Answer 1

我认为有几个原因，有些也是错误的。

错的 myFunc 函数(我不评论这个名字选得不好)似乎需要UTF-8参数。现在在MacOS和Linux上你可以期待它，但在Windows上不是。我认为这是一个错误：人们不应该UTF-8，相反，程序应该检查出命令行编码。

但是Windows采用了早期的Unicode，在UTF-8成为一个东西之前（也可能在Unicode发现它不能实现最初的目标：所有字符都在16位）。所以Windows内部使用UCS-2或UTF-16，外部有ANSI等，但不是真正的标准（这取决于Windows语言）。Windows的功能 CommandLineToArgvW 将命令行解析成Unicode字符串，这是获取命令行的方法，如果你有非ASCII字符（实际上，应该使用 wmain. 我不是Windows API方面的专家，但上面的代码有味道。它似乎是一些复制粘贴来解决一些现有的问题（例如，命令行与非ASCII字符，只有现代MacOSLinux），而不理解问题，并得到一个干净的解决方案。