我正在使用（似乎是）一个ansi（或ascii ??）dll库。我认为是这样的，因为lib提供的头文件显示了使用char *和LPSTR和LPCSTR的函数以及使用char数组的结构。
此dll通过:: LoadLibrary从cpp / cli类库加载，该类包装其功能并将其公开给c＃。 c＃控制台应用程序和各种其他类库使用此cli lib来执行操作。
我可以将cli程序集设为ether mutibyte或Unicode（据我所知，语言支持方面相同），c＃apps始终是Unicode。
这个本机dll本质上是一个专有的后端服务器的代理，它将信息传回服务器并传送到服务器。
我遇到的问题是，如果os语言环境（对于没有Unicode的应用程序，其运行的）设置为该特定语言，则本机dll lib将仅针对特定语言正常运行。 即如果我希望应用程序正确使用中文字符，则需要设置该区域设置。我发现很难理解为什么语言环境对经纪人很重要。我明白，如果服务器是ansi应用程序，如果用户想要在其上不存储任何Unicode中文，那么设置服务器上的语言环境就会有意义，所以它会在客户端中，但不会在中间人那里传递信息。此外，整件事情变得非常混乱。
是否可以将Unicode传递给c ++中的char数组？甚至在这种情况下工作？
这是我正在考虑的一个场景：
这真的可能吗？在内存布局方面，它应该是，我的意思是char只是一个字节没有？
我是以正确的方式接近这个吗？有没有更好的方法来完成跨语言支持。请注意，供应商有记录表示没有办法在api中混合语言，但这不是我想要的。我只是不想在我想要支持的每种语言的单独操作系统上运行该软件的实例。
答案 0 :(得分：1)
在这种情况下令人困惑的是，DLL的接口已损坏。在以下意义上断开：它不支持所有Unicode代码点。这与参数类型无关：char数组为perfectly good，用于支持所有unicode。
我们怎么知道这个？这是因为，根据您的说法，它的作用取决于系统区域设置。
那么，该怎么办？如果DLL源代码不在您的控制之下，您就不会拥有它。但是，您可以通过设置区域设置来解决一个ANSI代码页的问题。它不适用于某些语言。
最好是敦促DLL供应商支持unicode。当然，最佳编码是UTF-8 - 这样它就不会破坏现有代码，因为LPCSTR类型保持不变。
答案 1 :(得分：0)