私は（どうやら）ansi（またはascii ??）dllライブラリを使用しています。これは、libで提供されるヘッダーファイルがchar *とLPSTRおよびLPCSTRを使用する関数と、char配列を使用する構造体を示しているためだと思います。
このdllは、機能をラップしてc＃に公開するcpp/cliクラスライブラリから::LoadLibraryを介してロードされます。C＃コンソールアプリやその他のさまざまなクラスライブラリは、このCLIライブラリを使用して操作を実行します。
cliアセンブリをマルチバイトまたはUnicode（言語サポートに関しては同じであると私が理解している限り）にすることができ、c＃アプリは常にUnicodeです。
このネイティブdllは、基本的に適切なバックエンドサーバーのブローカーであり、サーバーとの間で情報をやり取りします。
私が遭遇している問題は、OSロケールがUnicodeアプリなしで、その実行がその特定の言語に設定されている場合にのみ、ネイティブdlllibが特定の言語で正しく動作することです。つまり、アプリを漢字で正しく動作させるには、そのロケールを設定する必要があります。私が理解するのが難しいのは、なぜブローカーにとってロケールが重要なのかということです。サーバーがansiアプリである場合、ユーザーがUnicode中国語を何も保存したくない場合は、サーバーにロケールを設定することは意味がありますが、クライアントでは意味がありますが、物事を渡すだけの仲介者では意味がありません。さらに、全体が非常に混乱しています。
UnicodeをC++のchar配列のようなものに渡す方法はありますか？このシナリオでも機能するでしょうか？
これが私が考えているシナリオです：
- C＃アプリはURLエンコードされた文字列を取得します
- c＃アプリは文字列をデコードし、CLIに渡します
- cliはどういうわけかString^（またはこの時点でbyte []である必要があります）をchar []に変換し、それをネイティブライブラリに渡します
これは本当に可能でしょうか？メモリレイアウトに関しては、charは単なるバイト番号ではないということですか？
私はこれに正しい方法でアプローチしていますか？クロスランゲージサポートを実現するためのより良い方法はありますか？ベンダーは、APIで言語を混合する方法はないと言っていることを記録していますが、それは私が探しているものではありません。サポートしたい言語ごとに別々のOSでソフトウェアのインスタンスを実行する必要はありません。