.netがstringにUTF16エンコーディングを使用するのに、ファイルを保存するためにデフォルトとしてutf8を使用するのはなぜですか？
基本的に、文字列はUTF-16文字エンコード形式を使用します
ただし、vs StreamWriter を保存する場合：
このコンストラクターは、バイトオーダーマーク（BOM）なしのUTF-8エンコーディングでStreamWriterを作成します。
私はこのサンプルを見ました（壊れたリンクは削除されました）：
また、一部の文字列ではutf8が小さく、一部の文字列ではutf-16が小さいように見えます。
- では、なぜ.netは
utf16を文字列のデフォルトエンコーディングとして使用し、utf8を使用してファイルを保存するのですか？
ありがとうございました。
p.s。すでに読んだ 有名な記事
Ifサロゲートペア（または同様に、アプリがBasic Multilingual Plane以外の文字を必要とする可能性）を無視しても問題ありません。UTF-16には、基本的にコードごとに常に2バイトが必要なニースプロパティがあります単一のコード単位ですべてのBMP文字を表します。
プリミティブ型charを考えてください。インメモリ表現としてUTF-8を使用し、all Unicode文字に対応したい場合、それはどれくらいの大きさですか？最大4バイトになる可能性があります。つまり、常に4バイトを割り当てる必要があります。その時点で、UTF-32を使用することもできます。
もちろん、UTF-32をchar表現として使用できますが、UTF-8はstring表現で使用し、変換します。
UTF-16の2つの欠点は次のとおりです。
- Unicode文字ごとのコード単位の数は可変です。これは、BMPのすべての文字areではないためです。絵文字が普及するまで、これは日常的に使用する多くのアプリには影響しませんでした。昨今、確かにメッセージングアプリなどの場合、UTF-16を使用する開発者は本当にサロゲートペアについて知る必要があります。
- プレーンASCII（少なくとも西部では多くのテキスト）は、同等のUTF-8エンコードテキストの2倍のスペースを必要とします。
（補足として、WindowsはUnicodeデータにUTF-16を使用していると信じています。NETが相互運用性の理由でこれに従うことは理にかなっています。
サロゲートペアの問題を考えると、言語/プラットフォームが相互運用要件なしでゼロから設計されている（ただし、Unicodeでのテキスト処理に基づいている）場合、UTF-16は最良の選択ではないでしょう。 UTF-8（メモリ効率が必要で、n番目の文字に到達するという点で処理の複雑さを気にしない場合）またはUTF-32（逆の場合）のいずれかがより良い選択です。 （n番目の文字に到達する場合でも、異なる正規化形式のようなものが原因で「問題」が発生します。テキストは難しい...）
多くの「なぜこれが選ばれた」の質問と同様に、これは歴史によって決定されました。 Windowsは、1993年にそのコアでUnicodeオペレーティングシステムになりました。当時、Unicodeにはまだ65535コードポイントのコードスペースしかなく、最近はUCSと呼ばれていました。ユニコードが補助プレーンを取得して、コーディングスペースを100万コードポイントに拡張するまでは、1996年まででした。また、サロゲートペアを16ビットエンコードに適合させることにより、utf-16標準を設定します。
.NET文字列はutf-16です。これは、オペレーティングシステムのエンコードに最適であり、変換が必要ないためです。
Utf-8の歴史はより暗いです。間違いなくWindows NTの過去、RFC-3629は1993年11月にさかのぼります。足掛かりが得られるまでに時間がかかり、インターネットは役立っていました。
UTF-8は、ほとんどの言語で比較的コンパクトな形式であるため、テキストの保存および転送のデフォルトです（UTF-8よりもUTF-16の方がコンパクトな言語もあります）。特定の各言語には、より効率的なエンコードがあります。
UTF-16はメモリ内の文字列に使用されます。これは、文字ごとに解析し、Unicode文字クラスや他のテーブルに直接マッピングする方が高速だからです。 Windowsのすべての文字列関数はUTF-16を使用し、長年使用しています。