基本的に、文字列はUTF-16文字エンコード形式を使用します
しかし、保存する場合とStreamWriter：
このコンストラクターは、バイト順マーク（BOM）のないUTF-8エンコーディングでStreamWriterを作成します。
私はこのサンプルを見ました（壊れたリンクは削除されました）：
utf8また、一部の文字列では小さいように見えますがutf-16、他の文字列では小さいように見えます。
utf16のデフォルトのエンコーディングとして使用するのでしょうか。utf8ありがとうございました。
ps私はすでに有名な記事を読んだ
サロゲートペア（または同等に、アプリが基本多言語面外の文字を必要とする可能性）を無視することに満足している場合、UTF-16にはいくつかの優れたプロパティがあります。これは、基本的に、コード単位ごとに常に2バイトを必要とし、すべてのBMP文字を表すためです。それぞれ1つのコードユニット。
プリミティブ型を考えてみましょうchar。インメモリ表現としてUTF-8を使用し、すべてのUnicode文字を処理したい場合、それはどのくらいの大きさにする必要がありますか？最大4バイトになる可能性があります...つまり、常に4バイトを割り当てる必要があります。その時点で、UTF-32を使用したほうがよいでしょう。
もちろん、表現としてUTF-32を使用することもできますが、char表現にはUTF-8を使用しstring、変換を進めていきます。
UTF-16の2つの欠点は次のとおりです。
（補足として、WindowsはUnicodeデータにUTF-16を使用していると思います。また、相互運用上の理由から.NETがそれに続くことは理にかなっています。しかし、それは質問を1つのステップに押し上げるだけです。）
サロゲートペアの問題を考えると、言語/プラットフォームが相互運用要件なしでゼロから設計されている場合（ただし、テキスト処理はUnicodeに基づいている場合）、UTF-16は最良の選択ではないでしょう。UTF-8（メモリ効率が必要で、n番目の文字に到達するという点で処理の複雑さを気にしない場合）またはUTF-32（その逆）のいずれかがより適切な選択です。（n番目の文字に到達する場合でも、正規化形式が異なるなどの理由で「問題」があります。テキストは難しいです...）
多くの「なぜこれが選ばれたのか」という質問と同様に、これは歴史によって決定されました。Windowsは、1993年にそのコアでUnicodeオペレーティングシステムになりました。当時、Unicodeにはまだ65535コードポイントのコードスペースしかありませんでした。最近ではUCSと呼ばれています。Unicodeがコーディングスペースを100万コードポイントに拡張するための補助プレーンを取得するまで、1996年になりました。そして、それらを16ビットエンコーディングに適合させるためのサロゲートペアにより、utf-16標準が設定されます。
.NET文字列はutf-16です。これは、オペレーティングシステムのエンコーディングとの適合性が高く、変換が不要なためです。
utf-8の歴史はもっと暗いです。間違いなくWindowsNTを過ぎて、RFC-3629は1993年11月にさかのぼります。足がかりを得るのにしばらく時間がかかりました。インターネットは役に立ちました。
UTF-8は、ほとんどの言語で比較的コンパクトな形式であるため、テキストの保存と転送のデフォルトです（一部の言語は、UTF-8よりもUTF-16の方がコンパクトです）。それぞれの特定の言語には、より効率的なエンコーディングがあります。
UTF-16は、文字ごとの解析が高速で、Unicode文字クラスやその他のテーブルに直接マップされるため、メモリ内の文字列に使用されます。Windowsのすべての文字列関数はUTF-16を使用し、何年も使用しています。