私は Windows プログラミングが初めてで、Petzold の本を読んだ後、次のように思います。
TCHAR
型と_T()
関数を使用して文字列を宣言するのは良い習慣ですか、それとも新しいコードで文字列wchar_t
と文字列を使用するだけですか?L""
Windows 2000 以降のみを対象とし、コードは起動時からi18nになります。
短い答え: いいえ。
他のすべての人が既に書いたように、多くのプログラマーは今でも TCHAR とそれに対応する関数を使用しています。私の謙虚な意見では、コンセプト全体が悪い考えでした。UTF-16文字列処理は、単純な ASCII/MBCS 文字列処理とは大きく異なります。両方で同じアルゴリズム/関数を使用すると (これが TCHAR の考え方の基になっています!)、UTF-16 バージョンでは、単純な文字列連結 (解析など)。主な理由はSurrogatesです。
唯一の例外として、 Unicode をサポートしていないシステム用にアプリケーションをコンパイルする必要がある場合を除き、過去のこの荷物を新しいアプリケーションで使用する理由はないと思います。
私はサーシャに同意しなければなりません。TCHAR
/ / などの根底にある前提は_T()
、「ANSI」ベースのアプリケーションを作成し、マクロを定義することで魔法のように Unicode サポートを提供できるということです。しかし、これはいくつかの悪い仮定に基づいています。
ソフトウェアの MBCS バージョンと Unicode バージョンの両方を積極的に構築していること
そうしないとchar*
、多くの場所で通常の文字列を使用することになります。
_T("...") リテラルで非 ASCII バックスラッシュ エスケープを使用しないこと
「ANSI」エンコーディングがたまたま ISO-8859-1 でない限り、結果のchar*
とwchar_t*
リテラルは同じ文字を表しません。
その UTF-16 文字列は「ANSI」文字列と同じように使用されます
そうではありません。Unicode には、ほとんどの従来の文字エンコーディングには存在しないいくつかの概念が導入されています。サロゲート。文字を組み合わせます。正規化。条件付きで言語に依存する大文字と小文字の規則。
そしておそらく最も重要なのは、UTF-16 がディスクに保存されたり、インターネット経由で送信されたりすることはめったにないという事実です。UTF-8 は外部表現に好まれる傾向があります。
アプリケーションがインターネットを使用しないこと
(今、これはあなたのソフトウェアにとって有効な仮定かもしれませんが...)
Web は UTF-8と多数のまれなエンコーディングで実行されます。このTCHAR
概念では、"ANSI" ( UTF-8 にはなりません) と "Unicode" (UTF-16) の 2 つしか認識しません。Windows API 呼び出しを Unicode 対応にするのには役立つかもしれませんが、Web アプリや電子メール アプリを Unicode 対応にするのにはまったく役に立ちません。
Microsoft 以外のライブラリを使用していないこと
他の誰も使用しませんTCHAR
。 Pocoはstd::string
UTF-8 を使用します。 SQLiteには、API の UTF-8 および UTF-16 バージョンがありますが、TCHAR
. TCHAR
標準ライブラリにもないので、std::tcout
自分で定義したい場合を除き、いいえ。
有効な UTF-8 ではないファイルを読み取る必要がある場合を除いて、「ANSI」エンコーディングが存在することを忘れてください。も忘れてくださいTCHAR
。常に Windows API 関数の "W" バージョンを呼び出します。 #define _UNICODE
誤って「A」関数を呼び出さないようにするためです。
文字列には常に UTF エンコーディングを使用します。文字列には UTF-8、char
文字列には UTF-16 (Windows の場合) または UTF-32 (Unix 系のシステムの場合) ですwchar_t
。 typedef
UTF16
プラットフォームの違いを避けるためのUTF32
文字タイプ。
それがまだ実際に行われているかどうか疑問に思っているなら、そうです-それはまだかなり使用されています。TCHARと_T( "")を使用している場合、誰もあなたのコードを面白く見ることはありません。私が現在取り組んでいるプロジェクトは、ANSIからUnicodeに変換することです。そして、ポータブル(TCHAR)ルートを使用します。
でも...
私の投票は、すべてのANSI / UNICODEポータブルマクロ(TCHAR、_T( "")、およびすべての_tXXXXXX呼び出しなど)を忘れて、どこでもユニコードを想定することです。ANSIバージョンが必要になることがないのであれば、ポータブルであるという意味は本当にわかりません。私はすべてのワイド文字関数とタイプを直接使用します。すべての文字列リテラルの前にLを付けます。
今日新しいプロジェクトを行っている場合でも、TCHAR構文を使用します。それとWCHAR構文の使用にはそれほど実用的な違いはなく、文字タイプが何であるかを明示するコードを好みます。ほとんどのAPI関数とヘルパーオブジェクトはTCHAR型(例:CString)を取得/使用するため、それを使用するのは理にかなっています。さらに、ある時点でASCIIアプリでコードを使用することにした場合、またはWindowsがUnicode32に進化した場合などに、柔軟性が得られます。
あなたがWCHARルートに行くことに決めたなら、私はそれについて明白になります。つまり、CStringの代わりにCStringWを使用し、TCHARに変換するときにマクロをキャストします(例:CW2CT)。
とにかく、それは私の意見です。
別のアプローチを提案したいと思います(2つのどちらでもありません)。
要約すると、UTF-8 エンコーディングを想定して char* と std::string を使用し、API 関数をラップする場合にのみ UTF-16 への変換を行います。
Windows プログラムでのこのアプローチの詳細と正当化については、http://www.utf8everywhere.orgを参照してください。
MSDNのWindows プログラミングの概要の記事には、次のように書かれています。
新しいアプリケーションは、常に (API の) Unicode バージョンを呼び出す必要があります。
すべてのアプリケーションで Unicode を使用する必要があるため、今日ではTEXTマクロとTCHARマクロはあまり役に立ちません。
私は と に固執しwchar_t
ますL""
。
そのとおり; 少なくとも_Tマクロについては。ただし、ワイド文字についてはよくわかりません。
その理由は、WinCEまたはその他の非標準のWindowsプラットフォームをより適切にサポートするためです。コードがNTに残ることが100%確実な場合は、通常のC文字列宣言を使用できます。ただし、ライブラリを移植する必要がある場合に備えて、数千行のコードを実行してどこにでも追加するよりも、Windows以外のプラットフォームでそのマクロを#defineする方がはるかに簡単なので、より柔軟なアプローチを採用するのが最善です。 WindowsMobileに。
IMHO、コードに TCHAR がある場合は、間違ったレベルの抽象化で作業しています。
テキスト処理を扱うときは、最も便利な文字列型を使用してください。これは、Unicode をサポートするものになることを願っていますが、それはあなた次第です。必要に応じて OS API 境界で変換を行います。
ファイル パスを扱うときは、文字列を使用する代わりに独自のカスタム タイプを作成します。これにより、OS に依存しないパス区切りが可能になり、手動で文字列を連結および分割するよりも簡単にコーディングできるインターフェイスが提供され、さまざまな OS (ansi、ucs-2、utf-8 など) への適応がはるかに容易になります。 .
明示的な WCHAR 以外のものを使用する唯一の理由は、移植性と効率性です。
最終的な実行可能ファイルをできるだけ小さくしたい場合は、char を使用します。
RAM の使用を気にせず、国際化を単純な変換と同じくらい簡単にしたい場合は、WCHAR を使用してください。
コードを柔軟にしたい場合は、TCHAR を使用してください。
ラテン文字のみを使用する予定の場合は、ユーザーがそれほど多くの RAM を必要としないように、ASCII/MBCS 文字列を使用することもできます。
「最初から i18n である」人は、ソース コードのスペースを節約し、すべての Unicode 関数を単純に使用してください。
古い質問に追加するだけです:
VS2010 で新しい CLR C++ プロジェクトを開始します。Microsoft 自身が を使用していますL"Hello World"
」と nuff 氏は述べています。
TCHAR
WCHAR
からに移植するという新しい意味がありますCHAR
。
https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
Windows 10の最近のリリースでは、アプリに UTF-8 サポートを導入する手段として ANSI コード ページと -A API が使用されています。ANSI コード ページが UTF-8 用に構成されている場合、-A API は UTF-8 で動作します。