これは私に興味をそそられるので、私は尋ねるつもりです-wchar_tなぜそれがWindowsのようにLinux / Linuxのようなシステムでそれほど広く使われていないのですか？具体的には、Windows APIはwchar_t内部的に使用しますが、Linuxは使用しないと思います。これは、char型を使用する多くのオープンソースパッケージに反映されています。
私の理解ではc、それを表すために複数のバイトを必要とする文字が与えられた場合、char[]フォームcはのいくつかの部分に分割されますがchar*、では単一のユニットを形成しwchar_t[]ます。wchar_tでは、いつも使うのは簡単ではないでしょうか。この違いを否定する技術的な理由を見逃したことがありますか？それとも、それは単なる養子縁組の問題ですか？
wchar_tプラットフォームで定義された幅のワイド文字ですが、あまり役に立ちません。
UTF-8文字は、1文字あたり1〜4バイトに及びます。1文字あたり正確に2バイトに及ぶUCS-2は廃止され、完全なUnicode文字セットを表すことができなくなりました。
UnicodeをサポートするLinuxアプリケーションは、バイト単位のストレージレイヤーより上で適切にサポートする傾向があります。Windowsアプリケーションは、2バイトだけで十分であるというこのばかげた仮定をする傾向があります。
wchar_tのウィキペディアの記事はこれについて簡単に触れています。
UnixベースのプラットフォームでUTF-8を最初に使用した人は次のように説明しています。
Unicode標準[当時のバージョン1.1]は、適切な文字セットを定義していますが、不合理な表現[UCS-2]です。これは、すべての文字が16ビット幅であり[もはや真ではない]、通信され、16ビット単位で格納されることを示しています。また、送信されたテキストのバイト順序を検出するために1組の文字（16進数のFFFEとFEFF）を予約し、バイトストリームの状態を要求します。（Unicodeコンソーシアムはパイプではなくファイルを考えていました。）このエンコーディングを採用するには、プラン9に出入りするすべてのテキストをASCIIとUnicodeの間で変換する必要がありましたが、これはできません。単一のプログラム内で、そのすべての入力と出力のコマンドで、文字を16ビット量として定義することができます。さまざまなメーカー[イタリック鉱山]によるさまざまなマシン上の数百のアプリケーションを備えたネットワークシステムのコンテキストでは、それは不可能です。
イタリック体の部分は、モノリシックアプリケーション（Microsoft Office）、非多様なマシン（すべてがx86であり、したがってリトルエンディアン）、および単一のOSベンダーを優先するWindowsシステムにはあまり関係がありません。
そして、小さな単一目的のプログラムを持つというUnixの哲学は、深刻な文字操作を行う必要のあるプログラムが少ないことを意味します。
ツールとアプリケーションのソースはすでにLatin-1で動作するように変換されているため、「8ビットセーフ」でしたが、UnicodeStandardとUTF[-8]への変換はより複雑です。一部のプログラムはまったく変更する必要がありませんでし
catた。たとえば、UTF [-8]で配信される引数文字列を、システムコールに解釈されずに渡すファイル名として解釈し、open入力から出力にバイトをコピーするだけです。バイトの値に基づいて決定を下すことはありません...ただし、ほとんどのプログラムでは、適度な変更が必要でした。...実際にルーン[ユニコードコードポイント]を内部で操作する必要のあるツールはほとんどありません。より一般的には、ファイル名の最後のスラッシュと同様の簡単なタスクを探すだけで済みます。170のCソースプログラムのうち...23だけが単語を含んでいます
Rune。ルーンを内部に格納するプログラムは、ほとんどの場合、その存在理由が文字操作
sedであるプログラムです。sam（テキストエディタ）、、、、、、（ ウィンドウシステムおよびターミナルエミュレータ）などです。ルーン文字とUTFエンコードのバイト文字列のどちらを使用して計算するかを決定するには、読み取りと書き込みの際のデータ変換のコストと、関連するテキストをオンデマンドで変換するコストのバランスをとる必要があります。比較的一定のデータセットで長時間実行されるエディターなどのプログラムの場合、ルーンがより適切な選択です...sorttrtroff8½
コードポイントに直接アクセスできるUTF-32は、カテゴリや大文字小文字のマッピングなどの文字プロパティが必要な場合に、実際に便利です。
しかし、ワイドチャーは、UTF-8がWindowsで使用するのが難しいのと同じ理由で、Linuxで使用するのは厄介です。GNUlibcには_wfopenまたは_wstat機能がありません。
UTF-8はASCIIと互換性があるため、Unicodeをある程度無視することができます。
多くの場合、文字列を終了できる\ 0がない限り、プログラムは入力が何であるかを気にしません（実際には気にする必要はありません）。見る：
char buf[whatever];
printf("Your favorite pizza topping is which?\n");
fgets(buf, sizeof(buf), stdin); /* Jalapeños */
printf("%s it shall be.\n", buf);
Unicodeのサポートが必要であることがわかったのは、マルチバイト文字を1つの単位（wchar_t）として持つ必要がある場合だけです。たとえば、バイトではなく文字列の文字数をカウントする必要がある場合。utf-8からwchar_tへのiconvはすぐにそれを行います。ゼロ幅スペースや発音区別符号の組み合わせなどのより大きな問題の場合、icuのようなより重いものが必要ですが、とにかくそれをどのくらいの頻度で行いますか？
wchar_tすべてのプラットフォームで同じサイズではありません。Windowsでは、2バイトを使用するUTF-16コードユニットです。他のプラットフォームでは、通常4バイトを使用します（UCS-4 / UTF-32の場合）。したがってwchar_t、多くのスペースを浪費するため、これらのプラットフォームがの使用を標準化する可能性は低くなります。