4

私は、内部と顧客の両方で使用されるいくつかのライブラリの作成に取り組んでおり、UnicodeとASCIIの両方をサポートするための最良の方法は何かと考えていました。Microsoft（MFCライブラリ内）はUnicodeクラスとASCIIクラスの両方を書き込み、マクロを使用してヘッダーファイルでこれと同様のことを行うようです。

#ifdef _UNICODE
#define CString CStringW
#else
#define CString CStringA
#endif

私はマクロの大ファンではありませんが、それは仕事をします。STLを使用してライブラリを作成している場合、次のようなものを含むヘッダーを作成することは理にかなっていますか？

#ifdef _UNICODE
#define GetLastErrorString GetLastErrorStringW
#else
#define GetLastErrorString GetLastErrorStringA
#endif

std::string GetLastErrorStringA();
std::wstring GetLastErrorStringW();

または、ASCII用とUnicode用の別々のライブラリをリリースする必要がありますか？

この状況で人々が何をするのが最善だと思うのか疑問に思うだけです。

更新：いくつかのコメントと質問に対処する：

  • これらはC++クラスライブラリになります。
  • アジアの文字セットをサポートしたいので、UTF-16エンコーディングを使用する必要があると思います。
  • Unicodeを実装する理由は2つあります。1）すべての新しいSDKがUnicodeをサポートしており、将来のSDKまたはサードパーティライブラリが将来的に個別のASCIIバージョンをサポートすることを確信していません。2）アプリケーションを完全に国際化するわけではありませんが、ユーザー入力（名前など）とアジア文字を含むパスからのファイルの読み込みを処理できれば便利です。
4

4 に答える 4

4

ライブラリ全体を内部的に Unicode にします。次に、Unicode 実装にサンクする ASCII 用の C++ アダプター クラスのセットが存在します。

于 2009-09-30T18:03:48.197 に答える
1

最初に UTF-8 に変換すると、Unicode 文字列を std::string に格納できます。

Windows API などの UTF-16 呼び出しとやり取りする場合にのみ wstring が必要です。その場合は、必要に応じてローカルで文字列を wstring に変換できます。これは少し面倒かもしれませんが、それほど悪くはありません。

于 2009-09-30T18:12:00.763 に答える
0

質問は少し不正確ですが...

まず、エンコーディングを正確にする必要があります。Unicode は文字 (それぞれがコードポイントに関連付けられている) の単なる表現です。アプリケーションで Unicode を扱う場合、コードポイントの表現方法を選択する必要があります。Utf-8 を使用できる場合は、ワイド文字について心配する必要はありません。データをプレーンな std::string に保存できます:)

次に、問題を正確にする必要があります。

  • Unicode と Ascii のエントリをサポートしますか?
  • それとも出力について話しているのですか？
  • とにかく std::locale を使用して、どのエンコーディングで出力する必要があるかを知ることができますか?

私は国際化されたアプリケーション (Web サイト、c++ バックエンドを使用) に取り組んでおり、内部的に std::string を使用するだけです。Ascii または Utf-8 での出力は変換ファイルに依存しますが、データ表現は iota によって異なりません (文字のカウントを除いて、このトピックに関する私の投稿を参照してください)。

本当に、私は間違いなくマクロのファンではありません.utf-8はAsciiと互換性があることを意図していたので、独自のエンコーディングを選択できれば助かります.

于 2009-09-30T18:08:13.117 に答える
0

ASCII、UTF-8、16、または 32 ビット文字を使用するのではなく、コードの「わかりやすさ」について質問していると思います。

もしそうなら、私はコードのブロックをできるだけ大きくすることを好みます: それは、「ゲート」(_UNICODE シンボリック定数) を使用して、個別のファイルまたは少なくともコードの大きなチャンクを選択することになります。ステートメント内で 1 行おきに場所を変更するコード、または天国が禁じられているコードは、理解するのが困難です。

ゲートを使用して個別のファイルのインクルージョンを選択することはお勧めしません

#ifdef _UNICODE
#include "myUniLib.h"
#else
#include "myASCIILib.h"
#endif

そのため、2 つ、場合によっては 3 つのファイル (Unicode ファイル、646US (ASCII) ファイル、および上記のコードを含む nexus ファイル) が必要になることもあります。これは、何かが失われてビルドが失敗する可能性が 3 倍になります。

代わりに、ファイル内でゲートを使用して大きなコード ブロックを選択します。

#ifdef _UNICODE
   ...lotsa code...
#else
   ...lotsa code...
#endif

では、反対のことをしているとしましょう: char と char (UTF-8) と W と A について考えているとします。どの程度普遍的になりたいですか? あなたが言及したCStringsは、Windowsの世界専用です。Mac と UNIX (OK、Linux) との互換性を維持したい場合は、困難な道のりを歩むことになります。

ところで、ASCII は ... ではありません ... 認識されている標準ではなくなりました。ASCII があり、次に ... ASCII があります。UNIX の昔からの 7 ビットの「標準」を意味する場合、私が見つけた最も近いものは ISO-646US です。Unicode に相当するものは ISO-10646 です。

文字を URL としてエンコードすることに成功した人もいます。ASCII 文字と数字、およびパーセント記号のみです。常にエンコードとデコードを行う必要がありますが、ストレージは実際に予測可能です。はい、少し奇妙ですが、間違いなく革新的です。

いくつかの言語的な落とし穴があります。たとえば、大文字と小文字が双方向であることに依存しないでください (ここでは適切な言葉を知りません)。ドイツ語では、小文字の ß を大文字に変換すると SS になります。ただし、SS を小文字にすると、ß ではなく ss に変換されます。トルコ語にも似たようなものがあります。アプリケーションを設計するときは、大文字と小文字の変換が役立つと想定しないでください。

また、文法上の順序は言語によって異なることに注意してください。「こんにちは、ジム！月曜日はどうですか？」「こんにちは！ 月曜日、うまくいっていますか、ジム?」

最後に、警告: ストリーム IO (std::cin << および std::cout >>) を避けてください。ローカライズが非常に困難になるような方法でメッセージ ジェネレータを埋め込むことに陥ります。

あなたは正しい質問をしています。あなたの前には冒険があります！一番！

于 2009-09-30T18:31:54.500 に答える