c++ - 无 Unicode 库和 Windows 语言环境

Question

我正在使用(似乎是)ansi(或 ascii？？)dll 库。我认为这是因为随 lib 提供的头文件显示了使用 char* 和 LPSTR 和 LPCSTR 的函数以及带有 char 数组的结构。

此 dll 是通过::LoadLibrary 从 cpp/cli 类库加载的，该类库包装了它的功能并将其公开给 c#。 C# 控制台应用程序和各种其他类库使用此 cli 库执行操作。

我可以使 cli 程序集成为以太多字节或 Unicode(据我所知，这在语言支持方面是相同的)并且 C# 应用程序始终是 Unicode。

这个 native dll 本质上是专有后端服务器的代理，它在服务器之间来回传递信息。

我遇到的问题是，如果操作系统区域设置(对于非 Unicode 应用程序)其运行设置为特定语言，则 native dll 库只能针对特定语言正确运行。IE。如果我想让该应用程序正确使用中文字符，则需要设置该语言环境。我发现难以理解的是为什么区域设置对经纪人很重要。我知道，如果服务器是一个 ansi 应用程序，如果用户不想在其上存储任何 Unicode 中文，则在服务器上设置区域设置是有意义的，因此它会在客户端中发生，而不是在只是传递信息的中间人中发生。此外，整个事情变得非常困惑。

是否可以将 Unicode 传递给 C++ 中的 char 数组之类的东西？在这种情况下甚至可以工作吗？

这是我正在考虑的一个场景:

• c# 应用程序获取 url 编码的字符串
• c# 应用程序解码字符串并将其传递给 cli
• cli 以某种方式转换 String^(或者它应该是 byte[] 在this point) 到 char[] 并传递给原生 lib

这真的可能吗？就内存布局而言，我的意思是 char 只是一个字节，不是吗？

我的处理方式是否正确？有没有更好的方法来完成跨语言支持。请注意，供应商在记录中说没有办法在 api 中混合语言，但这不是我要找的。我只是不想为我想要支持的每种语言在单独的操作系统上运行软件实例。

Answer 1

在这种情况下令人困惑的是 DLL 有一个损坏的接口(interface)。从以下意义上来说是错误的:它不支持所有的 Unicode 代码点。这与参数类型无关:char 数组是 perfectly good支持所有 unicode。

我们怎么知道的？这是因为，根据您的说法，它的作用取决于系统区域设置。

那么，怎么办？如果 DLL 源代码不在您的控制之下，您将不会拥有它。但是，您可以通过设置语言环境来解决一个 ANSI 代码页的问题。它不适用于某些语言。

最好是敦促 DLL 供应商支持 unicode。最好的编码当然是 UTF-8 - 这样它就不会破坏现有代码，因为 LPCSTR 类型保持不变。