9

私は現在、Unicodeを完全にサポートするWindowsとLinuxの両方で動作するはずの趣味のプロジェクト（C / C ++）に取り組んでいます。悲しいことに、WindowsとLinuxは異なるエンコーディングを使用しているため、私たちの生活はより困難になっています。

私のコードでは、データを可能な限り普遍的に使用して、WindowsとLinuxの両方で簡単に使用できるようにしています。Windowsでは、wchar_tはデフォルトでUTF-16としてエンコードされ、LinuxではUCS-4としてエンコードされます（間違っている場合は修正してください）。

私のソフトウェアが開き（{_wfopen、UTF-16、Windows}、{fopen、UTF-8、Linux}）、UTF-8のファイルにデータを書き込みます。これまでのところ、それはすべて実行可能です。SQLiteを使用することを決定するまで。

SQLiteのC/C ++インターフェイスでは、1バイトまたは2バイトのエンコードされた文字列を使用できます（クリック）。もちろん、Linuxのwchar_tはデフォルトで4バイトであるため、これはLinuxのwchar_tでは機能しません。したがって、sqliteからの書き込みと読み取りには、Linux用の変換が必要です。

現在、Windows / Linuxの例外を除いて、コードが乱雑になっています。私はwchar_tにデータを保存するという標準的な考え方に固執することを望んでいました。

  • Windowsのwchar_t：問題のないファイルパス、問題のないsqliteへの読み取り/書き込み。とにかく、ファイルへのデータの書き込みはUTF-8で行う必要があります。
  • Linuxのwchar_t：UTF-8エンコーディングによるファイルパスの例外、sqlite（wchar_t）への読み取り/書き込み前の変換、およびファイルにデータを書き込むときのWindowsの場合と同じです。

（ここで）読んだ後、私はWindowsでwchar_tに固執する必要があると確信しました。しかし、それをすべて機能させた後、問題はLinuxへの移植から始まりました。

UTF-8を実現するには、Windowsのすべての文字列を「WideCharToMultiByte」する必要があることを念頭に置いて、WindowsとLinuxの両方で機能するため、現在、すべてをやり直して単純なchar（UTF-8）を使用することを考えています。単純なchar*ベースの文字列を使用すると、Linux/Windowsの例外の数が大幅に減少します。

クロスプラットフォーム用のUnicodeの経験はありますか？wchar_tを使用する代わりに、単にデータをUTF-8に格納するという考えについて何か考えはありますか？

4

2 に答える 2

7

すべてのプラットフォームでUTF-8を使用し、Windows用のUTF-16にジャストインタイムで変換することは、クロスプラットフォームUnicodeの一般的な戦術です。

于 2012-06-28T00:21:37.643 に答える
2

私たちのソフトウェアもクロスプラットフォームであり、同様の問題に直面しました。私たちの目標は、コンバージョンの量をできるだけ少なくすることであると判断しました。これは、wchar_tWindowsとcharUnix/Macで使用することを意味します。

これを行うには、Unixでandなどをサポートし、との間で簡単に変換できるジェネリック関数を使用_Tします。また、ほとんどの場合に使用するジェネリック（ ）もあります。LPCTSTRstd::stringstd::wstringstd::basic_string<TCHAR>tstring

これまでのところ、これは非常にうまく機能します。基本的に、ほとんどの関数はatstringまたはaLPCTSTRを取り、そうでない関数はパラメーターをから変換しますtstring。つまり、ほとんどの場合、文字列を変換せず、ほとんどのパラメーターを渡します。

于 2012-06-28T00:41:46.067 に答える