0

これこのスレッドから、Windows では wchar_t が 16 ビットであり、Linux では wchar_t が 32 ビットであることを理解しています。

私のサーバーは Windows ベースで、クライアントは Linux です。

サーバーには、クライアントからホスト名を取得するための API があります。クライアントが Windows ベースの場合、GetComputerNameW を実行して Wide-String を返すことができます。ただし、クライアントが Linux ベースの場合、事態は複雑になります。

最初の単純なアプローチとして、Windows サーバー側に wchar_t* を返すことを期待して mbstowcs() を使用しました。ただし、この LPWSTR (Linux clinet 側に typedef wchar_t* LPWSTR があります) は、wchar_t が 16 ビットであると想定されるため、Windows では認識できません。

では、Linux で gethostname() の出力を変換する - これは char* で unsigned short (16 ビット) に私の唯一のオプションですか?

前もって感謝します!

4

2 に答える 2

6

有線でデータを転送する方法については、実際のプロトコルを決定する必要があります。ここでのいくつかのオプションは、おそらくUTF-8が通常最も賢明なものですが、これは、Linuxでは基本的にデータをそのまま使用できることを意味します(wchar_tを最初に使用する理由はありませんが、明らかにデータを何にでも変換できます)欲しいです)。

Windowsでは、UTF-8をUTF-16に変換する必要があります(正確にはそうではありませんが、まあまあ)。データを送信する場合は、UTF-8に変換する必要があります。幸いなことに、Windowsはまさにこれらの目的のためにこの機能をそれぞれ提供します。

もちろん、必ずしもUTF-8でなくてもよいエンコーディングを決定できます。プロセスは同じです。データを受信するときは、OSのネイティブ形式に変換し、送信するときは、オンワイヤエンコーディングに変換します。utf-8を使用しない場合、iconvはLinuxで動作します。

于 2012-11-27T20:48:01.797 に答える
2

パイプを介して送信するデータに標準の文字エンコーディングを選択し、すべてのマシンがそのエンコーディングを使用してデータを送信するように要求するのが最善です。

Windows は UTF-16LE を使用するため、パイプ経由で UTF-16LE を使用することを選択すると、Windows マシンは UTF-16LE でエンコードされた文字列をそのまま送信できますが、Linux マシンは必要に応じて UTF-16LE との間で変換する必要があります。

または、代わりに UTF-8 を選択することもできます。これにより、ネットワーク帯域幅が減少しますが、必要に応じて Windows と Linux マシンの両方で UTF-8 との間で変換する必要があります。ネットワーク通信の場合は、UTF-8 の方が適しています。

MultiByteToWideChar()Windows では、コードページで andWideCharToMultiByte()を使用できますCP_UTF8

Linux では、iconv()API を使用して、エンコード/デコードに UTF-8 文字セットを指定できるようにします。

于 2012-11-27T20:53:46.187 に答える